Hi, I'm rather new to hackintoshing, but I've been a Mac software developer for about 15 years.
I have some understanding of low level things, e.g. I've written a x-platform GUI disk editor to analyse various file systems and fix classic iPods with iPodLinux on them ("iBored"), but I have little to no understand of the OS X boot process so far.
As I am trying to get OSX running on a Asus 1008HA, for which there is no complete solution yet, I like to ask a few questions that may help me understand and debug a few things:
First, where exactly is defined where the boot loader looks for the Extras folder? Does it always look automatically for an EFI partition and looks inside for a HFS+ partition and the Extras folder therein, and if it doesn't find it there, does it keep looking on all other HFS+ partitions until it finds one?
Or is the locatition hard-coded into the boot loader (probably boot0 and boot1h, right?) at the time it gets copied into MBR or GUID book block?
Furthermore, if the disk uses classic MBR partitioning, where does the boot0 end up? Does it really fit into the ~220 bytes of block 0 on the disk? Or where's the rest of it, exactly? (I like to find it on the disk)
And I assume that this boot0 code then uses the PC BIOS calls to load more code and finally the EFI emulator, is that right? Where is this EFI emulator? Is that in the "boot" file? That would mean that the boot0 code already has to be able to read HFS+, because the boot file is in a HFS+ partition, right?
I like to understand all this because I might want to make a tool that install all this into a vanilla Asus Eee PC 1008HA, which comes with one Windows XP partition (no Linux option so far) and one more large and free partition. It even seems to have an EFI partition at the end, apparently for performing BIOS updates. I like to make it so that the EFI bootload files get installed on the PC and then allow the second, free, partition to be used to install OS X into. Hence I need to know where what goes, and how it might interfere with the present stuff.
Next, after searching many hours, I still have not found an explanation on how the Extra's kexts are actually getting loaded...
Until then, I thought OS X would boot like this:
1. kernel gets loaded. It has already code to read HFS+ built-in
2. kernel sets up its data structures, then finds the Extensions folder and parses the kexts, using some passive and active matching algos to load the kexts and run them to take over parts of the hardware.
3. From there on it's easy.
However, all the talk here suggests that the Chameleon bootloader is loading the kexts itself. How could that work? I mean, doesn't the bootload come before the kernel gets run? How can the bootloader then load kexts into the kernel before the kernel is ready to accept them?
I suspect that the information given here before was not precise.
Other bits I found suggest that at some point in the boot process a "device tree" is created, which reflects the actual installment of hardware during startup.
Is it right that this device tree gets created before the kernel gets loaded and run, and then the kernel reads this device tree information to device which kexts to load?
If that is so, I assume that the device tree also contains the full paths to the kexts, so that the code that creates the tree can specify to load kexts from our Extras folder. Is that correct?
I hope I'm on the right track here.
Now, on a normal Mac, I've learned that some EFI code is run which is probably what creates the device tree and then invokes the kernel.
How does that compare to a Hackintosh with an EFI emulator? Does Apple's EFI code get run there as well? Or is Chameleon the replacement for Apple's EFI code, creating the device tree and launching the kernel? If the latter, I guess that the EFI emulator is only needed to provide the kernel with basic access functions, such as for reading from disk, doing keyboard input, writing to the screen, etc?
Finally, what does the dsdt.aml file do? I get the impression it is a copy of the device tree. So is that what Chameleon prefers to use to tell the kernel about the device tree - and only if this file is not present, Chameleon needs to create the dev tree from scratch, which not only takes longer but may cause wrong guesses, leading to troubles booting the OS?
OK, if that all can be answered well, I think I can write an article on this so that others won't have to inquire this all again. And then get this darn 1008HA boot without "-f -x" eventually, and provide an easy installer for others.
