Re: Is it possible to load 64-bit EFI in Mac Pro
Re: Is it possible to load 64-bit EFI in Mac Pro
- Subject: Re: Is it possible to load 64-bit EFI in Mac Pro
- From: David Elliott <email@hidden>
- Date: Tue, 12 Oct 2010 23:02:06 -0700
Kiran,
On Oct 11, 2010, at 9:28 PM, kiran kumar wrote:
> Hi All,
>
> We have a Mac Pro Dual Core Intel Xeon 2,66Ghz machine (Model Number: MacPro1,1)
> This model cannot boot the 64-bit kernel and the hardware design only allowed use of a 32-bit kernel.
> some Macs with 64-bit processors won’t be able to load the 64-bit kernel because they have a 32-bit EFI.
>
> Is it possible to load 64-bit EFI in my machine , if it's possible can any one explain it .
http://support.apple.com/kb/HT3773
Does holding the 6 and 4 keys from the Apple chime until you see the spinner boot you in to 64-bit mode or does the bootloader simply ignore this? Or perhaps add arch=x86_64 to your NVRAM boot flags?
Although according to Amit Singh, neither of those will work with EFI32:
http://www.osxbook.com/blog/2009/08/31/is-your-machine-good-enough-for-snow-leopard-k64/
If that doesn't work I would suggest you contact Apple DTS to see if they have something official. A two-minute e-mail may (or may not) save you a few hours playing with alternative bootloaders.
From a technical perspective the only trick to booting K64 on EFI32 is to zero out the pointer in the system table to the runtime services table. K64 is coded to accept this as a hack to indicate that runtime services will not be available. The actual kernel and drivers are loaded exactly the same except the bootloader loads the x86-64 executable rather than the x86 executable from the fat binaries.
As Andrew pointed out open source bootloaders are perfectly happy to do this and you can run them on a genuine Apple machine using the "Boot Camp" BIOS.
If you do go that route you can actually make the graphics work with a little hack. You simply need to boot normally and dump the master device-properties key out of the IORegistry and feed that to the bootloader so it will feed it to the kernel. That will make graphics work correctly.
Other than losing EFI runtime services (i.e. the ability to get and set firmware variables) and the gathering of device properties from EFI boot-time drivers there is really no huge difference in the end result. You are still booted to OS X and you'll still be using a genuine Apple computer. You are simply booting it in a very unsupported configuration.
Anyway, you can find source (I don't do binaries) in my public SVN tree:
https://tgwbd.org/svn/Darwin/boot/branches/public/
Scattered around there are a bunch of comments. With a little work you can actually manage all sorts of fun combinations like having GRUB boot it or having it boot GRUB or having it boot NTLDR or BOOTMGR (Microsoft) or having them boot it, and so on and so forth.
If you don't mind making it your primary BIOS bootloader (i.e. it will load before Windows but you will be able to select Windows from it) then I would suggest using gpt0 in the MBR, boot1fat32 as the boot record of the EFI System Partition, and DRWNLDR as the bootloader. There are, however, many many more possibilities depending on how you wish to put things together and how much effort you want to put in.
Finally, I don't default to x86_64 but I did implement the arch=x86_64 command-line flag so you have to type that in at the prompt or put it in your boot plist per Amit's article.
Hope that helps get you started.
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden