Darwin Bootloader

[yahoop]

David Elliott has posted an update on his site with new source code yesterday.

From http://tgwbd.org/darwin/boot.html

 

Project Status

 

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 of gdb expecting a flat32 model.

 

 

 

I've done a few bugfixes to the HFS and HFS+ code. The first was a very nasty memory overwrite bug caused during the decompression of the HFS+ case tables. That bug was extremely annoying as it caused completely unrelated code to fail due to bogus data. In addition to that I discovered a bug in the HFS code. Who cares right? Well, wrong. Although hdiutil makehybrid will generate a hybrid ISO-9660 and HFS+ disk, the open source mkisofs tool generates a hybrid ISO-9660 and HFS disk. Again, this is a particularly nasty bug since the HFS code worked so long as you knew the file you were looking for. In the normal case the booter loads /mach_kernel and then compares the timestamp of /System/Library/Extensions and /System/Library/Extensions.mkext. So long as Extensions.mkext exists and Extensions either does not exist or is exactly 1 second older than Extensions.mkext, the booter will simply read Extensions.mkext. Otherwise it will enumerate the individual .kext bundles from the Extensions directory. The code as shipped by Apple misused strncpy and failed to NUL-terminate the strings. Therefore, enumerating the files in a directly would rarely, if ever, work. It is only because Apple's Darwin ISO's always included a valid Extensions.mkext that this bug was never encountered.

 

 

 

Now what you're probably really wondering is what cool new stuff I added. Well, I added GPT support which is quite useful because OS X will not install to anything other than a GPT disk out of the box. Perhaps not so useful for people dual-booting Darwin with other traditional x86 operating systems but very useful for people booting OS X in a virtualizer. Alex Graf has been using this bootloader with QEMU which he is slowly but surely making capable of running OS X.

 

 

 

I've also finally added FSB detection. This works only for Intel chips which return the multiplier information from a read to MSR 198h. This is exactly what xnu does during its early startup so if you have an Intel system everything works as expected. If you are running Darwin on an AMD machine the booter itself will cause the machine to reboot almost immediately after you attempt to start the kernel. One way to check for this is to use the new ?clocks command which will tell you the speed of the TSC, the multiplier, and the FSB speed that is calculated from those two pieces of information. If executing ?clocks causes the machine to reboot then you will never be able to run an unpatched xnu as it exists today. However, assuming you have built your own patched xnu you can override the check using the new fsbmhz= option. In this case which value you specify depends on what you did to the kernel. It may be that you've patched the kernel such that it ignores whatever the bootloader passes it. In this case you can specify any non-zero value for fsbmhz to keep the booter from trying to determine it.

 

 

 

The booter also checks one additional case which is MSR198h returning 0. This happens in shipping versions of VMware (aside from Fusion 2 betas). In this case it prints a big fat warning reminding you that you had better be using a patched xun. Again, specify any non-zero fsbmhz to bypass this check. In that case your patched kernel should just ignore the value it gets from the bootloader.

 

 

 

I've also made a small change to the way CD-ROM bootup occurs. It no longer defaults to booting the hard drive when it's booting from the CD. I always thought that was stupid. Instead it now boots the CD when you are booting from the CD. If you are for some strange reason using the CD to boot the hard drive then you can simply press 'h'.

 

 

 

The new revision is 122. Yes, that's a huge jump from 28. The reason is that a lot of branching and merging occured in the same svn repository unrelated to the bootloader source. Right now, everything is all rolled into one big patch although I'm working on putting together a changelog. That said, I don't think there's anything I changed that you wouldn't want so you might as well take it all. If for some reason you require the details, let me know. dfe@tgwbd.org

[~pcwiz]

Awesome! That's great news about VMware Fusion 2 and virtualizing OS X

[anibalin]

interesting reading thanks for sharing yahoop.

[netkas]

DFE gone to osx86 side ? strange. While ago he said me he doesn't want to be affilated with illegal osx86.

[macgirl]

Why illegal?

[mrbonkers]

how do i compile the source?