Project Status

2008 June 29

The booter now has the ability to load additional kernel extensions from a ramdisk supplied by a multiboot loader. The ramdisks are supplied in the form of Multiboot modules. The ramdisks must be in flat format with a partition table (APM, GPT, or MBR) and an HFS or HFS+ partition. Inside the partition you should have a /Library/Application Support/DarwinBoot/Extra/Extensions/ directory containing extensions just like /System/Library/Extensions/ does on a real system. You could also theoretically have a single file /Library/Application Support/DarwinBoot/Extra/Extensions.mkext being an archive of any extra kernel extensions you'd like to pass in to the kernel.

Get the ISO-2-USB EFI-Booter for Mac 0.01 beta and a recent version of Ubuntu Desktop Edition 64bit. Format a USB drive to provide a single FAT32 partition featuring MBR. Create the following directories on your USB drive: /efi and /efi/boot. Get the ISO-2-USB EFI-Booter for Mac 0.01 beta and a recent version of Ubuntu Desktop Edition 64bit. Format a USB drive to provide a single FAT32 partition featuring MBR. Create the following directories on your USB drive: /efi and /efi/boot. Copy the bootX64.efi from “ISO-2-USB EFI-Booter for Mac 0.01 beta” into /efi/boot on your USB Drive. Get the ISO-2-USB EFI-Booter for Mac 0.01 beta and a recent version of Ubuntu Desktop Edition 64bit. Format a USB drive to provide a single FAT32 partition featuring MBR. Create the following.

Note that the extensions or the extension archive from the ramdisk is loaded in addition to the extensions or extension archive on the boot volume. For example, you might place ACPIPS2Nub and the ApplePS2Controller extensions on the ramdisk and thus add support for PS/2 devices. You cannot reliably provide modified versions of existing extensions on the boot volume nor can you cause the booter not to load the extensions on the boot volume.

That said because of the way IOKit works it is usually possible to add kernel extensions which match better than other kernel extensions. It is also possible to add kernel extensions which cause existing driver classes in existing kernel extensions to match on more hardware. One example is that of NullCPUPowerManagement which matches on IOResources with the AppleIntelCPUPowerManagement IOMatchCategory and a slightly higher probe score. This ensures that AppleIntelCPUPowerManagement does not load without requiring it to be removed from the system. Another example is LegacyAppleIntelPIIXATA which does not actually contain any binary code. Instead it contains only an Info.plist which matches on legacy PIIX ATA hardware and specifies that the AppleIntelPIIXATARoot class from the com.apple.driver.AppleIntelPIIXATA extension should be used to drive the hardware.

Jan 05, 2019 Copy the bootX64.efi (or a386) from “ISO-2-USB EFI-Booter for Mac 0.01 beta” into /efi/boot on your USB Drive. Copy the Linux image into /efi/boot/ on the USB Drive, too and rename it to “boot.iso”. You should have 2 files on your USB drive now: bootX64.efi and boot.iso – both in /efi/boot. Note: New E2B v2 can now directly Secure UEFI-boot from ISO files - no need for.imgPTN files!from 100's of different UEFI p.

This method can be generally used to add support for a variety of hardware. Unlike the current 'hackintosh' methods, this method does not break when Apple updates the OS.

To use this new support you will need something capable of loading the booter as if it were a Multiboot kernel and loading a flat disk image file as if it were a multiboot module. The Multiboot specification is part of the larger GRUB project so obviously GRUB does a fine job. For CDs you might prefer something slimmer like ISOLINUX. You will need the mboot.c32 program that comes as part of the syslinux distribution and unfortunately you will need to make a small patch to it because the existing code does not pass the booted BIOS device through to the booter. This is critical for El Torito 'no emulation' boot because the BIOS is free to use any number it wishes. In practice it's typically 0x9f but various reports indicate it can be anything.

You will need a recent syslinux (I used 3.63 although I think 3.53 can work as well) and this patch. You will also need to copy com32/lib/syslinux/dsinfo.c from the latest syslinux git into your 3.63 working copy.

Those of you who have been using my booter in Multiboot mode may remember the 2-second delay giving you an opportunity to enter a different BIOS device. I have ripped this out and replaced it with a biosdev=XX option where XX is two hexadecimal digits (e.g. 80 to boot the first hard drive). Furthermore, once you are in the booter at the boot menu pressing the escape key will now drop you to the drive selector instead of booting the default entry. The drive selector is basically the same as before but it's nice that you can enter it as many times as you wish instead of having to reboot the machine.

Obviously this user-interface is still a work in progress. However, when used correctly it is fully capable of booting an unmodified OS X Leopard DVD. To do so you merely need to provide whatever extensions you need to make OS X work in your initrd file. When you run the booter you won't have any choices on the boot menu. Simply press escape to bring up the drive selector. With the drive selector up and waiting for your input eject the CD and insert the OS X DVD into the same drive. Wait about 10 seconds then press enter to restart the menu without changing the device. You should see the booter do the usual press any key to boot from the CD or press F8 to enter startup options. So do as you wish and in a minute or two you should be up and running Leopard. If you see an EBIOS read error, don't be concerned. The booter will retry the read and it usually works the second time. If not then perhaps you didn't wait for the drive to recognize the disk before hitting enter. If so, press escape and then enter and hopefully this time the drive will have spun up the new disc.

There is more to come soon as well. I am planning to merge in some of the changes from Chameleon that support more hardware and I plan to merge in some changes from some other people that support the kernels from Snow Leopard.

2008 May 25

Yes, I'm still alive! Thanks for asking. It's worth the wait for you though because I come bearing a new version of the bootloader including a number of enhancements and bugfixes. Some of this work is general stuff I had been hacking on in my working copies and some of it is work that I did for VMware. Yes, VMware was kind enough to pay me to do some work on this bootloader. Kudos to the folks at VMware, in particular Regis Duchesne (HPReg) who spearheaded the effort. His hard work on the virtualizer makes VMware Fusion 2 Beta 1 capable of running an unpatched Darwin 9 system. Obviously this is with the goal of officially supporting the virtualization of OS X which will be coming at some point in the future. As Regis mentions on his website, VMware is not doing a 'Hackintosh' but a real installation of OS X from a factory-sealed DVD.

The changes I've made are varied. First of all, I've taken some time to make some very low-level changes to the code. As more things are added to the booter it tends to grow in size which becomes problematic because the original code had problems when certain uninitialized static and global variables were located outside of the base 2000h segment. Through a variety of changes to the thunking code I've enabled the booter to grow to exactly 65024 bytes which is the most that the first-stage bootsectors are capable of loading. Furthermore, there will no longer be any guessing as to whether or not the code might or might not work with certain data located above the real-mode segment. So long as all code and initialized data fits within the first segment the bootloader will run correctly. All uninitialized (e.g. zeroed at early starutp) data can be located wholly or partially in the next physical segment without any ill effects.

On the build system side of things I removed the -fomit-frame-pointer option. Without it, that is letting the compiler use the frame pointer, the code generated by the compiler is actually smaller. Beyond that, the frame pointer is required if you want to do any sort of debugging with the code. VMware provides a very nice debug stub that you can attach to with gdb. This makes debugging the code fairly easy although debugging real-mode portions is a bit tricky. At least you can step through instructions and examine registers though you have to do the segment/offset arithmetic yourself to know where in memory the registers are referring to. This is a limitation

Iso-2-usb Efi-booter For Mac