MacBookPro3,1 + Snow Leopard = 32 bits.

Barney-15E wrote:
Can't talk to my Mom. She died several years ago. It's unfortunate you cannot read for comprehension. The statements on Apple's website are very clear. It's really not possible to help you as you continue to blame Apple for your own failings. You bought a product that cannot do what you hoped it could do. Apple never promised you anything, but it is somehow their fault in your mind.

I hope your kindergarten teacher made it =) so talk to him/her about the issues you face on this board....
and about the apple statements here is some of what they say:

64-bit computing used to be the province of scientists and engineers, but now this generational shift in computing gives all users the tools to apply the power of 64-bit to speed up everything from everyday applications to the most demanding scientific computations. Although Mac OS X is already 64-bit capable in many ways, Snow Leopard takes the next big step by rewriting nearly all system applications in 64-bit code¹ and *by enabling the Mac to address massive amounts of memory*. Now Mac OS X is faster, more secure, and completely ready for the future.

So to address those massive amounts of memory you would need an OS running a 64 bit kernel..
And please don't tell me I'd need a 64 bit capable computer to do so, because I know and I own
a such 64 bit capable computer running on another partition a 64 bit OS with a 64 bit kernel...
And it is not any computer in the future that would be able to do so. it's "todays macs" they are
talking about.. and before snow leopard came out apple promised a full 64 bit OS for every 64 bit capable intel CPU which would be every CPU intelCore 2 duo or above... hey.. who cares? right?
I mean I don't actually mind too much about it... seriously.. but it is a principle thing what kind of statements you 2 guys are posting here about why this would be so, from hey there're several hardware issues and stuff.. not true... to: I actually have no idea what the the problem is there... very true! you guys have no plan what so ever.. but somehow you have to defend the company...
a company that would have done better in motorbike business as it seems...

You're answering your own issue...

The last line states:

Now Mac OS X is faster, more secure, and completely ready for the future.

Do you know what the future is? as in not at present?

macwiz1220 wrote:
You're answering your own issue...

The last line states:

Now Mac OS X is faster, more secure, and completely ready for the future.

Do you know what the future is? as in not at present?

He's to busy gazing at his navel to understand what future means.

don't try the lipo on your retail release without having copied and blessed a compatible boot.efi
otherwise your machine won't boot anymore..
once you've done this, the line goes like this:
sudo lipo -remove i386 mach_kernel mach_kernel

in terminal you will have to go to your root direction first, where the mach_kernel is..
make sure by typing ls and enter (you should see all the files listed then)
if your mach_kernel is there you can type the line..
the second mach_kernel in the line is the output file.. you can surely do a different output file
sudo will be needed and will ask you for your password

I haven't tried this on the retail still... had no time till now.. i will try this now... (with a different boot.efi)
be sure to make a timemachine backup before you go on with this!!
cheers =)

dude.. you just don't get it... it is absolutely not the future where 64 bit capable computers are assembled... they are made here and yet... as a matter of fact I am just writing this message from
one of those 64 bit capable machines out there.. and i am not from the future somehow magically... so pls.. don't even try to answer my questions, cause you obviously can't...

Nah, I don't think that work. I'm pretty much sure the boot.efi would look for the i386 kernel, and not finding it the boot would get stuck. I will give it a try anyway (with the modified boot.efi), after all I'll just need to copy back the original kernel if it messes up.

Yeah, as I thought. Missing kernel. The trick is not in the kernel itself (mach_kernel), but in the boot.efi, since it is the boot loader. The best way would be to find how to modify it in order to always load mach_kernel for the x86_64 arch.

I hexedited bootefi and i386 appears only in a couple of locations. Maybe modifying them to x86_64...

Michelasso wrote:
Yeah, as I thought. Missing kernel. The trick is not in the kernel itself (mach_kernel), but in the boot.efi, since it is the boot loader. The best way would be to find how to modify it in order to always load mach_kernel for the x86_64 arch.

I hexedited bootefi and i386 appears only in a couple of locations. Maybe modifying them to x86_64...

yeah... it was an earlier preview of SL where the lipo would work... just tried it on the WWDC..
the idea of this was that if the lipo works than the boot.efi is a different one... i know that the issue is not the kernel itself...
so hex editing is what I try by tomorrow... but you could post it if you had any luck =)

Michelasso wrote:
When I wrote "boot in 64 bit mode" I obviously meant boot and load the 64 bit kernel. Once the kernel is loaded, the EFI should be discarded. The major thing is that with an EFI32 OSX 64 bit shouldn't be able to access the NVRAM so commands like "nvram" (indeed) and the boot disk selection in system preferences probably won't work anymore.

No offense intended, but you may need to study those links you say are nothing new. From them, you should learn that on a Mac, boot disk selection is handled by the BootROM, not by the +kernel environment loader+, which on an Intel Mac is the boot.efi file. (If you think about it, common sense should also tell you this: you can't load something from a disk until a disk is selected to load it from.) It is the BootROM firmware that reads the preset disk selection from NVRAM (if there is one set) & optionally allows a different selection at boot time by querying the option key. Note that this is not handled by anything (including the boot.efi file) that resides on a disk, because of the common sense requirement given above. (This is why you can still get to the Startup Manager, even if no disks are accessible.)

IOW, this part of EFI is in the firmware of Intel Macs. If this is still not clear, refer to the Intel link -- this has nothing to do with "Unix internals" (which refers to an OS) but only with EFI, which is a method of loading an OS. Apple uses Intel’s reference implementation (the Intel Platform Innovation Framework, also just called "the framework"), so everything that applies to it applies to Intel Macs.

Moreover, for Mac OS X, the "kernel environment" is not just the kernel, but a combination of the kernel & all device drivers that are involved in the boot process. The boot.efi file does initiate this process, but you must understand that each OS can handle this differently, which is part of why you can't generalize from what one OS can do to what another OS can do.

IOW, the boot.efi file must specifically be written to support booting the desired OS, taking into account what is provided in the kernel itself & what may be abstracted into other essential parts of the OS. There are various ways to do this. For instance, the kernel might handle loading device drivers, or the boot.efi file might instead. Whatever the method, it is another common sense requirement that all device drivers that are involved in the boot process actually are loaded before the OS can use them & finish booting.

For Mac OS X, this requires that more than the kernel is loaded because in Mac OS X, device drivers are abstracted in the I/O Kit, not in the kernel. (This is why your earlier statement that the kernel manages the I/O devices is too simplistic.) If you study the Dev Center link I provided, you will see that Apple actually provides three different ways to load the OS X kernel environment (including both the kernel & the necessary drivers), & that only after all that loads does the boot loader start the kernel initialization procedure. The kernel will then initialize the I/O Kit, which in turn links the loaded drivers into the kernel. Only after all this occurs can the kernel find the root BSD directory & use its contents to complete booting into OS X.

I understand that this is probably more than you are interested in considering, but you really do have to consider it all to understand what is involved in booting a "fully 64 bit OS" & why you can't achieve it simply by editing a table entry in the boot.efi file to remove the "artificial" restriction Apple made to prevent you from using it. Sure, you can probably hack the file to force the 64-bit kernel to load, but that is only a small part of the boot process, at least if you want a functioning version of OS X to load, initialize, & run.

Where I was mistaken before, is that I didn't think that SL should come with the 64 bit kext for standard VGA adapters. At least that's what the author of the article made me thinking. So even a Mac with Intel GMA 950 should be able to run the 64 bit kernel, obviously after hacking of the boot.efi. Maybe on 640x480 mode, or maybe not. For sure the graphics will be much slower.

It isn't at all obvious to me if the 64-bit kernel could do more than get a GMA 950 (or similar) graphics processor to display a grey screen (or anything else not provided by the EFI firmware) unless there is a 64-bit kernel compatible driver for it already provided on the boot drive. (Likewise for any other device involved in the boot process, which in OS X could cover a lot of hardware.) Snow Leopard definitely did not install a 64-bit extension for the GMA X3100 in my Macbook 4,1 & I would be surprised if it did for MacBooks with the GMA 950.

I'm not sure what you refer to when you mention "that guy" who made a hack that proves a MacBook like mine can boot into a functional version of OS X, especially if the hack just consists of editing an entry in the boot.efi file. The only hacks I've seen are for a limited number of recent Mac models, especially those with NVIDIA GeForce 9000 series graphics systems, & I'm not even certain any mention the suggested hack works with more than a few MBP models, or that the results support what most users would consider a fully functional OS.

If you have a link to whatever it is you refer to, I would appreciate your posting it here. I can't guarantee that I will try it, but I would at least like to see what the hack consists of.

I am not sure that's really needed either, because the original boot.efi is stored in

/usr/standalone/i386/boot.efi

Not to sound like a broken record but if you check the Apple Dev Center link you will see that this isn't that simple, either.

So I believe that if the loader pointed by "bless" is corrupted OSX should be smart enough to use the one above. Not sure, tho. In any case messing with this wouldn't fry a Mac, that's for sure!!!

I agree that the chances are very slim that anybody would fry their Mac just by editing the efi.boot file's table. However, this really isn't about what "bless" does (again, see the Dev Center link) or just editing the table. I do not want to be the first one to discover some obscure bug or critical dependency in (for instance) the 64-bit SMC kext that a hack reveals causes the OS to tell the SMC in my MacBook that everything is (literally!) cool when it is not. The chances of this are extremely slim but I am not interested in taking even that small risk because my MacBook is essential to my work.

Of course, if somebody else wants to be the guinea pig, that is another matter …. 😉

Barney, I have one small bit of advice for you:

Do not feed the trolls.

What don't you understand about the words "ONCE the kernel is loaded"? That's AFTER the bootROM and the boot.efi do their job. Do you want the boot sequence? Here:

- Power ON
- Control passes to BootROM that checks and initialize some HW interfaces: POST (Power-On Self Test)
- The BootROM passes the control to the EFI, which does basic HW initialization and chose the operative system
- In the case of OSX it selects boot.efi for loading (or whatever is blessed for that partition in the EFI)
- boot.efi, that is the boot loader, loads /mach_kernel, which is the OSX kernel and it has both 32 and 64 bits archs.

Once mach_kernel has finished to load, the EFI is practically ignored. Why? Because the kernel will be the only responsible to manage the hardware in place and it will do that by the use of the kext (usually called device drivers). Why do you think they are called kext, i.e. KERNEL EXTENSIONS, if they don't belong to the kernel???

It has been proved in Internet that the only restriction to load the 64 bits kernel in Macs with EFI64 is a black list, artificially made by Apple in the boot.efi, that oblige those Macs to boot in 32 bit mode.

Big news is that the original article that explained the trick was actually wrong. It has been discovered that the black list actually works like this:

- if the value is 0x0 for a specific model, any version of that model can't boot in 64 bit mode
- any number different than 0x0 is the minimum model version required to boot in 64 bits mode.

For example a value of 0x7 for the iMacs, means the iMac 7,1 and above. In the article it was suggested to use OxC (iMac 12,1? I don't know much about iMacs). Here is the proof that the boot.efi Ox7 hacking for iMacs successfully worked:

http://episteme.arstechnica.com/eve/forums?a=tpc&s=50009562&f=8300945231&m=41000 3421041&r=515005361041#515005361041

Check Stratus Fear post with pictures (can't miss it).

What you fail to understand RCR, is that writing hundreds of posts on the subject, thousands words long doesn't make someone automatically right. You said since the beginning that it wasn't possible to run the 64 bits kernel in architecture that were excluded by Apple. The Internet proves that your statement is wrong.

What isn't yet been proved is if a EFI32 Mac with Core 2 Duo CPU can run the 64 bit kernel. I did some blind tries hacking the boot.efi but they were obviously unsuccessful.

regarding your test, I'm pretty much sure that you forgot to do the necessary modifications in the nvram and the com.apple.Boot.plist. This can be done using the "32- or 64-bit Kernel Startup Mode Selector": http://www.macupdate.com/info.php/id/32252

Michelasso wrote:
What don't you understand about the words "ONCE the kernel is loaded"? That's AFTER the bootROM and the boot.efi do their job.

You missed the point completely. Loading the kernel is only a part of it. It still has to be initialized, the I/O Kit has to link device drivers to the kernel, etc.

It is pretty clear that you don't understand much of this. You don't even seem to be able to use more than vague terminology that makes a meaningful discussion impossible or even distinguish between an OS & the boot process very well. I don't think I'm automatically right, but neither am I willing to continue this discussion on the superficial level of your replies.

There is a lot of good technical info out there. If you don't want to take advantage of it, that's your business. But all the bluster in the world won't change it or make it less complex. If you want to understand it, you will have to study it, & that involves much more than the bits & pieces you think a handful of anonymous Internet sources prove.

R C-R wrote:

Michelasso wrote:
What don't you understand about the words "ONCE the kernel is loaded"? That's AFTER the bootROM and the boot.efi do their job.

You missed the point completely. Loading the kernel is only a part of it. It still has to be initialized, the I/O Kit has to link device drivers to the kernel, etc.

The I/O Kit now, right... Here's the Apple definition of I/O Kit:

http://developer.apple.com/mac/library/documentation/DeviceDrivers/Conceptual/IO KitFundamentals/Features/Features.html#//apple_ref/doc/uid/TP0000012-TPXREF101

The I/O Kit is a collection of system frameworks, libraries, tools, and other resources *for creating* device drivers in Mac OS X. It is based on an object-oriented programming model implemented in a restricted form of C++ that omits features unsuitable for use within a multithreaded kernel. By modeling the hardware connected to a Mac OS X system and abstracting common functionality for devices in particular categories, *the I/O Kit streamlines the process of device-driver development*.

The I/O Kit is an SDK! A Software Development Kit. What it has to do with this discussion only the Lord knows. Just out of curiosity, did you ever boot your Mac pressing <command>-v? The verbose mode, you know. It gives a good practical clue of what we are talking about.

The point is that there are plenty of Macs in the Apple "black list" flawlessly running the 64 bit kernel right now. Not to mention the totally UNSUPPORTED hackintosh with a 64 bit SS3 CPU. Actually they boot in 64 bits by default. This proves your assertions are all wrong. The only point where you may have some reason is on running the 64 bit kernel using the EFI 32.

The general idea in the hacker and system administrators community is that it is possible anyway. Actually Netkas claims that one just needs to install Chameleon 2 RCx with his PCEFI boot loader 10.1 into an USB pendrive and boot from it. Personally I'm not able to make it running the 64 bit kernel (there is also a mess installing Chameleon using Snow Leopard. It fails), but it could be just a matter of time.

And do you know why? Because It Can Be Done, like it could for all EFI64 Macs now happily running the 64 bit kernel.

Keep reading. Eventually it may dawn on you that the kernel is not a file, & what that has to do with all this.

R C-R wrote:
Keep reading. Eventually it may dawn on you that the kernel is not a file, & what that has to do with all this.

Actually... Unix people well know that "Everything in Unix is a file". 😀

But yeah, don't worry. The file "mach_kernel" in the root directory is the one containing the core of the kernel. Its name is derived from the Mach microkernel, which in reality is only a part of the OSX kernel (XNU).

Anyway, since you keep arguing that I simplify things too much, I quote for you what Dennis Ritchie, the creator of C language and one of the pioneer of the Unix system:

"Unix is simple. It just takes a genius to understand its simplicity." – Dennis Ritchie

I don't see your need to keep complicating things when not needed.