How to boost the OS X boot process...

[Master Chief]

...

 

I was thinking along the same lines as you so I corrected default MacPro table in smbiospatcher.h to match that for MacPro4,1 (I have x58 chipset), and changed entries at start of fakeefi.c to match. HPET has worked OOB so no changes there. The good news is that it now boots to Desktop but very slowly (about 20 revs cw usual 4-5).

-> SMBIOS (most definitely).

 

Edit: You need to change the following line:

orig_address = (struct SMBEntryPoint *)0xfc430; // getAddressOfSmbiosTable();

in smbios_patcher.c (remove the hard coded address, which was only a test to see how long it takes).

 

Having looked at the Revolution code I'm amazed at all the changes you've made. It's taken me hours, so I guess it must've taken you ages. Good work.

Thanks. It is a slow process yes, but I have done most of it in smaller steps. Sometimes I look at a particular piece of code for a second, or a third time even, and think: What the beep is that. Time for another change.

 

Here's an example: I just changed function initGraphicsMode (in graphics.c) into a one liner. And a next candidate for todays work is function getVESAModeWithProperties in the same file. We don't need it; VESA is a well known standard and most people – if not all – are using the same video mode over and over again. And since my hardware isn't going to drop VESA support any time soon, and I'm also not going to change the video mode... let's pick one our selfs and we are done looking for it every single boot.

[dgsga]

Edit: You need to change the following line:

orig_address = (struct SMBEntryPoint *)0xfc430; // getAddressOfSmbiosTable();

in smbios_patcher.c (remove the hard coded address, which was only a test to see how long it takes).

 

Hi MC

 

Have tried your suggestion on a single-drive setup and it does indeed work. However, when I use the same boot file on my RAID0 setup I get the same old KP. As far as I can tell none of the RAID code has been removed so yet another mystery to solve...

[Master Chief]

Hi MC

 

Have tried your suggestion on a single-drive setup and it does indeed work. However, when I use the same boot file on my RAID0 setup I get the same old KP. As far as I can tell none of the RAID code has been removed so yet another mystery to solve...

Ah. Good news. Another little step forward. I wonder; Did you reinstate the code I mentioned in post #45?

 

You probably noticed that the background color changes a little sooner in the boot process. And there was this short delay (up until Revolution v0.6.16) which made the Apple logo appear after a short delay. But not anymore; I optimized bootlogo.c and drivers.c and now the gray background and Apple logo appear (almost) simultaneously. And this without moving the calls to functions showBackground and showBootLogo which would be cheating.

 

The problem here was that all except one function in bootlogo.c was written to make it work (which I simply copied from Chameleon). Not to do it as fast as possible. Which also shows that my work can have a positive affect on Chameleon. Some people 'just' don't get it. Let's have a look at one example:

    [color="#008000"]int rem = (pixelBytes * width) % 4;	
   int length = pixelBytes * width / 4;[/color]

   while (height--)
   {
       // [color="#FF0000"]int rem = (pixelBytes * width) % 4;[/color]

       // [color="#FF0000"]if (rem)
		bcopy(&color, vram, rem);[/color]

       // [color="#FF0000"]stosl(vram + rem, color, pixelBytes * width / 4);[/color]
       stosl(vram + rem, color, length);
       vram += VIDEO(rowBytes);
   }

And while this is just a minor improvement – you have to look at the bigger picture here, because this sort of 'hand brakes' keep adding up for a notable slower boot process – doing 2400 multiplications – at a screen resolution of 1900 x 1200 – is was pretty much useless. Not to mention that function convertImage did it even 16384 times... but hey these are just a few milliseconds. Yeah right.

 

Another problem is that Chameleon let people dump their files anywhere on their hard disk, which basically results in a considerably slower boot process. Being a tad more restrictive with this kind of "features" would have helped, and a lot.

 

The most important note for today is – at least for some of our readers here – is that I am not blaming any of the Chameleon developers for it, but I am merely trying to help improve our boot time. Maybe this wasn't clear (enough) for some, but it should now.

 

Edit: New text added about the Boot Process in post #1.

[Master Chief]

Update: I keep making process (boot2 is now 63008 bytes) but I also need some time for my new hardware (Asus main board, dual Xeon 5520, 24MB ECC RAM, ATI 5770) which apparently arrives tomorrow already.

 

Edit: I think to have made room for the missing boot drive selection menu. Let me try to add it back in (keeping boot2 below the 65536 bytes marker).

[bossob]

Nice work indeed.

 

Cant wait to try it

[Master Chief]

Good news. My new hardware arrived today and thus I installed OS X (Server Edition) and everything but audio is working. Had to disable the on-board video, and I still have some DSDT hacking to do, but the boot time is basically the same, even with two 5550's, as my P5K Pro hack. Please note that I used the same brand/type of hard drives so that might explain it.

 

Note: My Intel Xeon L5520's should arrive in a day or two, but I couldn't resist and thus I decided to install two 5550's from a defunct server board. The CPU's I am using now are much faster, but also a lot more power hungry (two L5520 are using less power than one single 5550) than what I will be using.

 

This new hardware shows me something that even I wasn't expecting, which is that our boot loader is still as slow/fast as before, and thus I took the original boot-132 sources to give it a whirl. Boy this is fun because I can now boot, be it in 32-bit mode only, with Apple's boot-132 plus Dave Elliot's modifications only.

 

There's one thing I have to fix and that is that booting without smbios_patcher makes it a slow dog, so I have to come up with something better or use Macerintel's smbios_patcher (for the time being). All in all another step forward. Something I was looking for so long already.

[dgsga]

MC,

 

Good luck with your experiments. Have tried re-instating the code you mentioned but still no joy. It's a pity because the boot logo appears almost instantly after bios POST screen before the KP occurs. Would it be possible for me to reinstate the old smbios code or would that defeat the object?

[Master Chief]

MC,

 

Good luck with your experiments. Have tried re-instating the code you mentioned but still no joy. It's a pity because the boot logo appears almost instantly after bios POST screen before the KP occurs. Would it be possible for me to reinstate the old smbios code or would that defeat the object?

Hi,

 

Should not be a problem. Give it a try.

 

And I will keep experimenting to find other possible improvements, and share them when possible (read: when they are ready for the general public). We're on track, but I need to find a more general acceptable booter. One that works for a wider audience. Should be possible, but it might be a bumpy ride to get there.

 

Anyway. Keep me posted!

[Master Chief]

Today I made a few changes to improve USB boot support, and that was when I was hit by a five rev penalty on my hard drive! Please note that I did not replace a single file on my hard drive. Only /boot on my USB stick. Which begs the question why something this simple can even have such a huge impact!

 

The first thing I tried was to clear (remove):

 

/System/Library/Caches/

/Library/Caches/

 

Which unfortunately did not help. It's still the same. The "Waiting for DSMOS..." is back. I don't get it!?!

 

We have to figure out what it is, because this could lead to much improved boot times for everyone!!!

[Master Chief]

Revision 0.6.18 will soon be released [maybe after lunch already].

 

This version [with only a few minor modifications to 0.6.16] boots from a cheap 4GB Kingston USB memory stick. Please note that I disabled all hard drives [under ACPI] in the BIOS so that it passes the BIOS post routine a lot quicker [at least here with five hard drives]. And this is all I have on this USB stick:

drwxrwxr-x  8 chief  staff	   340 Feb 22 11:42 .
drwxrwxrwt@ 9 root   admin	   306 Feb 22 11:37 ..
drwxr-xr-x  3 root   admin	   102 Feb 22 11:34 Library
drwxr-xr-x  3 root   wheel	   102 Feb 22 11:08 System
-rw-r--r--@ 1 root   admin	 63520 Feb 22 11:26 boot
-rw-r--r--@ 1 root   wheel  18676624 Feb 22 11:11 mach_kernel

Nothing special in com.apple.Boot.plist from /Library/Preferences/SystemConfiguration/:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>arch=i386 boot-id=uuid boot-uuid=2F539C63-CA1B-3361-AFE0-F05616148A71</string>
<key>Graphics Mode</key>
<string>1600x1200x32</string>
</dict>
</plist>

Please note that you need Extensions.mkext (in /System/Library/Caches/com.apple.kext.caches/Startup/) so that OS X can take care of the drive initialization, and then /boot loads without any issues. Even with the drives disabled in the BIOS. Sweet.

 

Let's hope that this update works [like it does here] for people where Revolution previously failed to boot from USB sticks.

 

Edit: If you get a gray background but not the Apple logo, then you must disable the drives in the BIOS. I hope to fix this in the next update [or just revert the: if 1 // CHAMELEON lines] !!!

Revolution_618.zip

[Master Chief]

Time for another experiment – proof of concept

 

It was time for another experiment (make sure to read post #60 first). This time I was trying to:

 

1) Boot from a 4GB Kingston DataTraveler with all drives disabled in the BIOS (last paragraph).

2) Speed up the boot process of my 4GB Kingston DataTraveler.

3) Understand why boot-132 includes unused code, which could be used to speed up the boot process.

 

Let's jump right in. Here's what I did. I copied all kexts from /System/Library/Extensions/ to ~/Extensions/ (my local user folder) and started to remove one kext after the other. Well not really. Sometimes I removed 5 or 10 files at a time. Anyway. The next step was to create a fresh copy of Extensions.mkext for which I used the following terminal command:

sudo kextcache -v 1 -t -l -mkext2 /Volumes/USBBOOT/S*/L*/C*/c*/S*/Extensions.mkext ~/Extensions/

 

And after a few times... this is what I have. Here's my list of essential kexts (required to boot):

AppleACPIPlatform.kext    [AppleACPIEC.kext removed]
AppleAHCIPort.kext
AppleAPIC.kext
AppleFileSystemDriver.kext
AppleFSCompressionTypeZlib.kext
AppleHIDKeyboard.kext    [Required for Apple keyboard / AppleBluetoothHIDKeyboard.kext removed]
AppleHPET.kext
AppleIntelCPUPowerManagement.kext
AppleLPC.kext
AppleMatch.kext    [Removal = stuck at blue screen]
ApplePlatformEnabler.kext
AppleProfileFamily.kext
AppleRTC.kext
AppleSMBIOS.kext    [Removal = slow boot]
fakesmc.kext        [Removal = stuck before blue screen]
IOACPIFamily.kext
IOAHCIFamily.kext
IOHIDFamily.kext
IOPCIFamily.kext
IOPlatformPluginFamily.kext
IOSCSIArchitectureModelFamily.kext
IOSCSIParallelFamily.kext
IOStorageFamily.kext
OSvKernDSPLib.kext
Quarantine.kext
Sandbox.kext
System.kext    [Removal = KP]

Now. Before you start counting... there are now only 27 essentials kexts left in Extensions.mkext [2.133.806 bytes]. And yes audio, LAN and everything else is still fully functional. But please note that I boot in 32-bit mode and haven't had the time to check 64-bit mode yet (which may fail so you are warned).

 

And this ladies and gentlemen tells me that the kernel doesn't really need Extensions.mkext (notably in the boot loader) nor that it needs all kexts in it... simply because it will load all required kexts anyway. Let me add that it loads Extensions.mkext right before the Apple logo is shown, and thus the larger the file... the longer it takes before the logo appears. No wonder of course because loading ~6MB extra data hurts. Even on a fast boot drive.

 

And while this experiment took off 10 revs i.e. booting from USBBOOT is now just as fast as booting from my hard drive, shedding new light on the matter, we still have to find a good balance between size and speed. But one thing is sure; limiting the number of kexts in Extensions.mkext does help. A lot even.

 

Conclusions

 

First. This was a fun experiment. And no regrets here, because now I can boot without any drive enabled in my BIOS. Which is cool for people who are still stuck with USBBOOT methods – hello RAID users? My initial thought (more a hope really) however was wrong. No. Extensions.mkext is not loaded twice! Which is too bad for us because now there isn't that much to gain for everyone. Anyway. It was not a complete waste of time. No sir. I think to have a much better understanding now, about how and why things are done in boot-132.

 

Also. It might still be a good idea to have a reduced copy of Extensions.mkext for normal boots. One with all unused kexts removed. That however is for you to find out since I already did this, and even before I started to work on this.

 

Notes

 

The SATA configuration in my BIOS is set to AHCI [other options are IDE and RAID] and all drives under BIOS menu: Main > AHCI Settings are set to "Not Installed". And booting is normally not possible due to the simple fact that the drives are undetected, but the setup I have here [on my USBBOOT] may enable me to boot with an unmodified copy of Chameleon. In fact it should work [why wouldn't it?] but I haven't verified it myself.

 

Oh and I spotted a few errors in kernel.log and had to restore IOCDStorageFamily.kext and IODVDStorageFamily.kext to fix them.

 

Revolution 0.6.18

 

Oh bugger. I just noticed something! The following change wasn't made:

-orig_address = (struct SMBEntryPoint *)0xfc430; // getAddressOfSmbiosTable();
+orig_address = (struct SMBEntryPoint *) getAddressOfSmbiosTable();

Which basically means that you have to fix this yourself. Well either that or wait for Revolution 0.6.19 to come out.

[Master Chief]

Time for another experiment – proof of concept

 

Time for another experiment. Today I like to show you how I replaced Chameleon's SMBIOS patcher with a stripped down version of my own. The basic idea is to incorporates a patched SMBIOS table in the boot loader. Let's jump right in and have a look at the new smbios_patcher.c:

#include "smbios_patcher.h"

inline struct SMBEntryPoint *getSmbios()
{
   int tableLength = sizeof(SMBIOS_Table);
   void *customSMBIOS = (void *)AllocateKernelMemory(tableLength);
   memcpy(customSMBIOS, SMBIOS_Table, tableLength);

   struct SMBEntryPoint *modSMBIOS = (struct SMBEntryPoint *)AllocateKernelMemory(sizeof(struct SMBEntryPoint));

   modSMBIOS->anchor[0]          = 0x5f; // _
   modSMBIOS->anchor[1]          = 0x53; // S
   modSMBIOS->anchor[2]          = 0x4d; // M
   modSMBIOS->anchor[3]          = 0x5f; // _
   modSMBIOS->checksum           = 0;
   modSMBIOS->entryPointLength   = 0x1f;
   modSMBIOS->majorVersion       = 2;
   modSMBIOS->minorVersion       = 1;
   modSMBIOS->[color="#FF0000"]maxStructureSize[/color]   = 0xc0; // taken from my dump!
   modSMBIOS->entryPointRevision = 0;

   modSMBIOS->formattedArea[0]   = 0;
   modSMBIOS->formattedArea[1]   = 0;
   modSMBIOS->formattedArea[2]   = 0;
   modSMBIOS->formattedArea[3]   = 0;
   modSMBIOS->formattedArea[4]   = 0;

   modSMBIOS->dmi.anchor[0]      = 0x5f; // _
   modSMBIOS->dmi.anchor[1]      = 0x44; // D
   modSMBIOS->dmi.anchor[2]      = 0x4d; // M
   modSMBIOS->dmi.anchor[3]      = 0x49; // I
   modSMBIOS->dmi.anchor[4]      = 0x5f; // _
   modSMBIOS->dmi.checksum       = 0;
   modSMBIOS->dmi.tableLength    = tableLength; 
   modSMBIOS->dmi.tableAddress   = (uint32_t) customSMBIOS; 
   modSMBIOS->[color="#FF0000"]dmi.structureCount[/color] = 0x47; // taken from my dump!
   modSMBIOS->dmi.bcdRevision    = 0x21;

   // Fix checksum
   modSMBIOS->dmi.checksum = 256 - checksum8(&modSMBIOS->dmi, sizeof(modSMBIOS->dmi));
   modSMBIOS->checksum = 256 - checksum8(modSMBIOS, sizeof(*modSMBIOS));

   return modSMBIOS;
}

Which is a lot smaller and simpler, and thus easier to read, but there is a catch; The red values have to be taken from a dump. And while there are better ways to solve this, I have yet to decided what to do. How to implement it. Anyway. Here's my version of smbios_patcher.h:

#ifndef __LIBSAIO_SMBIOS_PATCHER_H
#define __LIBSAIO_SMBIOS_PATCHER_H

#include "libsaio.h"

typedef UInt8  SMBString;
typedef UInt8  SMBByte;
typedef UInt16 SMBWord;
typedef UInt32 SMBDWord;
typedef UInt64 SMBQWord;

struct DMIEntryPoint {
   SMBByte    anchor[5];
   SMBByte    checksum;
   SMBWord    tableLength;
   SMBDWord   tableAddress;
   SMBWord    structureCount;
   SMBByte    bcdRevision;
} __attribute__((packed));

struct SMBEntryPoint {
   SMBByte    anchor[4];
   SMBByte    checksum;
   SMBByte    entryPointLength;
   SMBByte    majorVersion;
   SMBByte    minorVersion;
   SMBWord    maxStructureSize;
   SMBByte    entryPointRevision;
   SMBByte    formattedArea[5];
   struct DMIEntryPoint dmi;
} __attribute__((packed));


// Patched SMBIOS table in little endian formatted
static uint32_t SMBIOS_Table[] =
{ 
   0x00001800, 0xF0000504, 0xDE900F06, 0x00017F8B, 0x05330000, 0xFFFF0C08, 0x72656D41, 0x6E616369, 
   0x67654D20, 0x65727461, 0x2073646E, 0x2E636E49, 0x30333100, 0x20202033, 0x2F323100, 0x322F3631, 

...

   0x00000008, 0x00000000, 0x00000000, 0x01000000, 0x39333156, 0x49554734, 0x7F000044, 0x00004704, 
   0x48068300, 0x00050100, 0x00000000, 0x00000000
};

#endif /* !__LIBSAIO_SMBIOS_PATCHER_H */

And before you start wondering... I took out the middle section [of smbios_patcher.h] because you get the picture without the extra data – you can find a complete example [of this data] in Revolution v0.6.13 and up. Please note that this example isn't loading a file from disk, but we could easily do that. Piece of a cake.

 

Getting the SMBIOS data

 

Creating the data for smbios_patcher.h was pretty easy. Here is how I did it:

 

1) I opened IORegistryExplore

2) Went to: Root -> MacPro3,1 -> bios -> AppleSMBIOS -> SMBIOS

3) Double clicked on the SMBIOS data and copied it [cmd+c].

4) Paste [cmd+v] it into HexEdit and save [cmd+s] it as smbios.dat.

5) Ran: sudo perl swap-5.pl smbios.dat > ~/Desktop/smbios-le.txt

6) Dumped the data in smbios_patcher.h

 

This however is not enough. It won't work without two values from your running version of Revolution / Chameleon. I used Revolution 0.6.19 and here's the lines I added to function getSmbios [in smbios_patcher.c]:

	...
new_address = smbiosDryRun(orig_address);
smbiosRealRun(orig_address, new_address);

[color="#FF0000"]setVideoMode(0); // VGA_TEXT_MODE
printf("\n%04x", new_address->maxStructureSize);
printf("\n%04x", new_address->dmi.structureCount);
getc(); // press a key to pass gray background[/color]

return new_address;
}

Oh and one extra line at the top of smbios_patcher.h: extern void setVideoMode(int mode); Well. That's it. Bit of a hack. I know, but it works.

 

What's next

 

While this works, it is far too complicated. Period. Thus what we need is a simple tool to dump and convert our SMBIOS data. I would opt for an OS X specific tool. A tool that let's us work with the SMBIOS data [add/change/remove] would be a plus to me. That would be cool. Any takers?

 

Chameleon's new pref panel would be an excellent candidate as SMBIOS data collector/converter, but I don't know if Rekursor and/or Diebuche is willing to do add this feature (waiting for a reply).

 

 

Conclusions

 

My preliminary conclusions are as follow:

 

1) It works.

2) The boot file is 1785 bytes smaller (now 61.670 bytes).

- this despite the fact that I included the SMBIOS data (2770 bytes).

3) It is faster.

4) We want need some script or tool to rip out unused stuff like: COM1, FLOPPY, PRI_EIDE, PS/2 Mouse, PS/2 Keyboard and to rename slot names.

swap_5.pl.zip

smbios_patcher.zip

[scrax]

Hi, i've tried the last revolution (bug corrected) also with only one drive active in bios but it still hang on gey screen, using my ssdt...

[Master Chief]

Hi, i've tried the last revolution (bug corrected) also with only one drive active in bios but it still hang on gey screen, using my ssdt...

I don't know what you have changed, but here are a few tips:

 

When it hangs at the gray background (before the Apple logo is shown) then this usually means that it can't find: /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext

Copy this file to your USB stick and it should load.

 

When it hangs at the Apple logo, without a spinner, then it can't find the kernel [mach_kernel].

 

When it hangs at the spinner [below the Apple logo] then either a driver (kext) is missing or something else is wrong.

 

And when you disable all drives in the BIOS then you must have a copy of mach_kernel on your USB stick so that boot2 can find / load it. The kernel (and Extensions.mkext) will enable the hard drives, and boot from the drive you have specified in /Library/Preferences/SystemConfiguration/com.apple.Boot.plist (on your USB stick).

 

What is the: "Ignore ownership on this volume" setting for your USB stick i.e. keep an eye on group / ownership and file permissions.

[Master Chief]

This is my current kernel.log (hack @2.5GHz stock speed):

Feb 27 03:16:36 localhost kernel[0]: npvhash=4095
Feb 27 03:16:36 localhost kernel[0]: PAE enabled
Feb 27 03:16:36 localhost kernel[0]: 64 bit mode enabled
Feb 27 03:16:36 localhost kernel[0]: Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386
Feb 27 03:16:36 localhost kernel[0]: vm_page_bootstrap: 973636 free pages and 74940 wired pages
Feb 27 03:16:36 localhost kernel[0]: standard timeslicing quantum is 10000 us
Feb 27 03:16:36 localhost kernel[0]: mig_table_max_displ = 73
Feb 27 03:16:36 localhost kernel[0]: AppleACPICPU: ProcessorId=1 LocalApicId=0 Enabled
Feb 27 03:16:36 localhost kernel[0]: AppleACPICPU: ProcessorId=2 LocalApicId=1 Enabled
Feb 27 03:16:36 localhost kernel[0]: AppleACPICPU: ProcessorId=3 LocalApicId=2 Enabled
Feb 27 03:16:36 localhost kernel[0]: AppleACPICPU: ProcessorId=4 LocalApicId=3 Enabled
Feb 27 03:16:36 localhost kernel[0]: calling mpo_policy_init for Quarantine
Feb 27 03:16:36 localhost kernel[0]: Security policy loaded: Quarantine policy (Quarantine)
Feb 27 03:16:36 localhost kernel[0]: calling mpo_policy_init for Sandbox
Feb 27 03:16:36 localhost kernel[0]: Security policy loaded: Seatbelt sandbox policy (Sandbox)
Feb 27 03:16:36 localhost kernel[0]: calling mpo_policy_init for TMSafetyNet
Feb 27 03:16:36 localhost kernel[0]: Security policy loaded: Safety net for Time Machine (TMSafetyNet)
Feb 27 03:16:36 localhost kernel[0]: Copyright © 1982, 1986, 1989, 1991, 1993
Feb 27 03:16:36 localhost kernel[0]: The Regents of the University of California. All rights reserved.
Feb 27 03:16:36 localhost kernel[0]: MAC Framework successfully initialized
Feb 27 03:16:36 localhost kernel[0]: using 16384 buffer headers and 4096 cluster IO buffer headers
Feb 27 03:16:36 localhost kernel[0]: IOAPIC: Version 0x20 Vectors 64:87
Feb 27 03:16:36 localhost kernel[0]: ACPI: System State [s0 S3 S4 S5] (S3)
Feb 27 03:16:36 localhost kernel[0]: RTC: Only single RAM bank (128 bytes)
Feb 27 03:16:36 localhost kernel[0]: mbinit: done (64 MB memory set for mbuf pool)
Feb 27 03:16:36 localhost kernel[0]: netkas presents fakesmc, a kext which emulates smc device
Feb 27 03:16:36 localhost kernel[0]: From path: "uuid", 
Feb 27 03:16:36 localhost kernel[0]: Waiting for boot volume with UUID ...
Feb 27 03:16:36 localhost kernel[0]: Waiting on ...
Feb 27 03:16:36 localhost kernel[0]: com.apple.AppleFSCompressionTypeZlib load succeeded
Feb 27 03:16:36 localhost kernel[0]: AppleIntelCPUPowerManagementClient: ready
Feb 27 03:16:36 localhost kernel[0]: Got boot device = ...
Feb 27 03:16:36 localhost kernel[0]: BSD root: disk2s2, major 14, minor 8
Feb 27 03:16:36 localhost kernel[0]: FireWire (OHCI) VendorID 1106 ID 3044 built-in now active, GUID ...; max speed s400.
Feb 27 03:16:36 localhost kernel[0]: systemShutdown false
Feb 27 03:16:38 Chief kernel[0]: NVDANV50HAL loaded and registered.
Feb 27 03:16:38 Chief kernel[0]: Previous Shutdown Cause: 0
Feb 27 03:16:38 Chief kernel[0]: DSMOS has arrived
Feb 27 03:16:38 Chief kernel[0]: AppleIntelCPUPowerManagement: initialization complete

Please note that I disabled AUDIO and LAN for this run, and that I replaced the ID's with "..." but this is it. And while AUDIO and LAN adds another 5 seconds to my kernel.log... I do not see a change in the actual boot time. They are both the same. Time for drastic measures. Time for me to figure out what it is that makes the spinner [below the Apple logo] spin. Well. It is mach_kernel but I mean why it is taking so long, and if we can speed it up somehow.

 

Let's have another look at the following list:

[color="#FF8C00"]AppleACPIPlatform.kext [/color][not cached and thus required]
[color="#006400"]AppleAHCIPort.kext
AppleAPIC.kext
AppleFileSystemDriver.kext
AppleFSCompressionTypeZlib.kext
AppleHIDKeyboard.kex[/color]t [Required for Apple keyboard / AppleBluetoothHIDKeyboard.kext removed]
[color="#006400"]AppleHPET.kext
AppleIntelCPUPowerManagement.kext
AppleLPC.kext
AppleMatch.kext [/color]
[color="#006400"]ApplePlatformEnabler.kext
AppleProfileFamily.kext
AppleRTC.kext
AppleSMBIOS.kext
fakesmc.kext[/color]
IOACPIFamily.kext
IOAHCIFamily.kext
[color="#FF8C00"]IOHIDFamily.kext[/color] [required for Apple keyboard]
IOPCIFamily.kext
IOPlatformPluginFamily.kext
[color="#006400"]IOSCSIArchitectureModelFamily.kext
IOSCSIParallelFamily.kext
IOStorageFamily.kext[/color]
OSvKernDSPLib.kext
[color="#006400"]Quarantine.kext
Sandbox.kext[/color]
[color="#FF0000"]System.kext[/color]

The same list from one of my previous posts. And I can remove all kexts that are marked green on this list – because I have them cached in Extensions.mkext on my USBBOOT already – but the others cannot be removed. But why? Time to check the kernel sources. The first file that I looked at was: bootstrap.cpp where I found the following lines:

static const char * sKernelComponentNames[] = {
  // The kexts for these IDs must have a version matching 'osrelease'.
  "com.apple.kernel",
  "com.apple.kpi.bsd",
  "com.apple.kpi.dsep",
  "com.apple.kpi.iokit",
  "com.apple.kpi.libkern",
  "com.apple.kpi.mach",
  "com.apple.kpi.private",
  "com.apple.kpi.unsupported",
  "com.apple.iokit.IONVRAMFamily",
  "com.apple.driver.AppleNMI",
  "com.apple.iokit.IOSystemManagementFamily",
  "com.apple.iokit.ApplePlatformFamily",

#if defined(__ppc__) || defined(__i386__) || defined(__arm__)
  /* These ones are not supported on x86_64 or any newer platforms.
   * They must be version 7.9.9; check by "com.apple.kernel.", with
   * the trailing period; "com.apple.kernel" always represents the
   * current kernel version.
   */
   "com.apple.kernel.6.0",
   "com.apple.kernel.bsd",
   "com.apple.kernel.iokit",
   "com.apple.kernel.libkern",
   "com.apple.kernel.mach",
#endif

  NULL
};

Which explains why it needs System.kext in /System/Library/Extensions/ – the kernel loads this file, despite the fact that it is already available from Extensions.mkext [on USBBOOT]. I don't know why it isn't using the one from Extensions.mkext but at least now we know that the kernel needs it.

 

Ok. I am done with this. This isn't really going to help us. Next

[scrax]

I don't know what you have changed, but here are a few tips:

 

I've merged the file you provided (0.6.18) in a copy of the chameleon2RC4 source folder, and then i added my ssdt (from the ssdt working with revolution 0.4) data instead of yours, dsdt data is the same.

then i've made this correction:

-orig_address = (struct SMBEntryPoint *)0xfc430; // getAddressOfSmbiosTable();
+orig_address = (struct SMBEntryPoint *) getAddressOfSmbiosTable();

compiling it gives me only a boot file so I used it on a Chameleon RC4 installation on usb stick but it hangs at the grey screen.

 

I've tried with your tips but nothing:

/Library/Preferences/SystemConfiguration/com.apple.Boot.plist and /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext plus mach_kernel copied on usb stick, only one drive in bios active, and UUID in c.a.B.p but nothing change.

Mi last working revolution is the 0.4 posted in the P5K Pro topic with the PlatformUUID code you optimized.

[Master Chief]

...

compiling it gives me only a boot file so I used it on a Chameleon RC4 installation on usb stick but it hangs at the grey screen.

Try this; disable all drives in the BIOS.

 

Edit: I am still trying to figure out why other people can't boot with the latest versions of Revolution, and I thought to have found something, but that wasn't it. I even switched back to the original 1303 BIOS [with only the logo data removed] to be sure that the in-BIOS version of Revolution isn't loading Extensions.mkext and/or mach_kernel

 

1) Did you check the file ownership and permissions?

- I used the same as the files on my hard drive.

2) What is the content of /Library/Preferences/SystemConfiguration/com.apple.Boot.plist?

- You do have something like: boot-id=uuid boot-uuid=... pointing to the boot drive ?

3) Are you booting in 32-bit mode?

- If not give it a try.

4) Do you have a RAID setup?

- I wonder about USB RAID setups... if that works. Going to give it a try.

[scrax]

Try this; disable all drives in the BIOS.

 

Edit: I am still trying to figure out why other people can't boot with the latest versions of Revolution, and I thought to have found something, but that wasn't it. I even switched back to the original 1303 BIOS [with only the logo data removed] to be sure that the in-BIOS version of Revolution isn't loading Extensions.mkext and/or mach_kernel

 

1) Did you check the file ownership and permissions?

- I used the same as the files on my hard drive.

2) What is the content of /Library/Preferences/SystemConfiguration/com.apple.Boot.plist?

- You do have something like: boot-id=uuid boot-uuid=... pointing to the boot drive ?

3) Are you booting in 32-bit mode?

- If not give it a try.

4) Do you have a RAID setup?

- I wonder about USB RAID setups... if that works. Going to give it a try.

 

disable ALL drives? included the one there are the SL install? i'll try...

 

1) I've set permissions 775 on all the system folder copied on the usb (owner root:admin)

2) yes i've copied it from yours but it's in /Volumes/USB4Revolution/Library/Preferences/SystemConfiguration/com.apple.Boot.plist

3) yes always

4) No raid a simple usb booter

 

just to be sure is it all right that i have only boot compiled from the last Revolution source?

[Master Chief]

disable ALL drives? included the one there are the SL install? i'll try...

Yes. I had similar problems. Stuck at the grey screen. The problem is that I can't remember what it was. It might be as simple as pressing a key – since I had debug stuff in it – or something else. Can't remember. Sorry.

 

1) I've set permissions 775 on all the system folder copied on the usb (owner root:admin)

2) yes i've copied it from yours but it's in /Volumes/USB4Revolution/Library/Preferences/SystemConfiguration/com.apple.Boot.plist

3) yes always

4) No raid a simple usb booter

The name doesn't matter, but the number of partitions might. How many do you have? And GUID or not?

 

just to be sure is it all right that i have only boot compiled from the last Revolution source?

I used Dr Hurts installer [as a test] and only replaced /boot which works fine here.

 

I still think that it can't find Extensions.mkext on your USBBOOT. This might be due to group ownership and/or permission problems, but you can easily verify this, and add something like:

setVideoMode(0);
printf("\nWAIT");
getc();

so see where it stops doing anything.

[scrax]

I'm using Chameleon2RC4 v3 installer by Dr.Hurt on my USB stick

 

On the USB I have:

/Volumes/Revolution/System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext

/Volumes/Revolution/Library/Preferences/SystemConfiguration/com.apple.Boot.plist

/Volumes/Revolution/mach_kernel

/Volumes/Revolution/boot

 

 

-First SATA port:

2 partition in GUID one for SL and one for Time Machine Backups (of another Snow on another HD)

 

I can/will also make some test with a 8GB USB with all in it SL and Revolution if you think this could help.

Or i can use another old SATA HD just to have only one partition on it.

 

I still think that it can't find Extensions.mkext on your USBBOOT. This might be due to group ownership and/or permission problems, but you can easily verify this, and add something like:

setVideoMode(0);
printf("\nWAIT");
getc();

so see where it stops doing anything.

 

I can't figure where to put this code, I tried boot.c but I get errors in compilation.

Is there a way to have default 32bit boot ?

 

 

EDIT: Finally I can boot with 2 HD connected to SATA1 and SATA2 the second one is my SL install described above

It start's with the grey apple not in center like for a wrong resolution setting, but it's just a cosmetic issue.

It looks fast but after login looks like there is some problem with the SSDT code because device-id are the original one not the one injected by SSDT, graphic card also isn't recognized, and USB are not internal.

Another thing not good is that the PlatformUUID has changed, but also this need further test...

 

Now i'll try to understand why the SSDT is not working...

[Master Chief]

...

EDIT: Finally I can boot with 2 HD connected to SATA1 and SATA2 the second one is my SL install described above

Can you still boot after disconnecting SATA2?

 

It start's with the grey apple not in center like for a wrong resolution setting, but it's just a cosmetic issue.

What do you have in com.apple.Boot.plist (on the USB stick)?

 

It's looks fast but after login it looks like there is some problem with the SSDT code because it looks like the device-id are the original one not the one injected by SSDT, graphic card also isn't recognized, and USB are not internal. Another thing not good is that the PlatformUUID has changed, but also this need further test...

 

Now i'll try to understand why the SSDT is not working...

It should be faster yes. And I didn't change the SSDT code – not for a while – and thus it should work. Working here.

[scrax]

Can you still boot after disconnecting SATA2?

I'll tryIt still boots, but disconnecting SATA1 because SATA2 is the HD I need to use, the one on SATA1 has another UUID

What do you have in com.apple.Boot.plist (on the USB stick)?

nothing more than "arch=i386 boot-id=uuid boot-uuid=8B09DAB6-B2F0-3C1F-9D74-0C133A62F158"

It should be faster yes. And I didn't change the SSDT code – not for a while – and thus it should work. Working here.

I've changed it because it's a little different for my mobo, I used your script to make it littke endian checking it's divisible by 4

this is what I'll use now (changed a little than the first boot to see if it works now EDIT: it works!):

0x54445353, 0x000005A4, 0x434D0C01, 0x00000000, 0x45574F50, 0x00004D52, 0x00000001, 0x4C544E49, 
0x20091112, 0x4E574608, 0x24100054, 0x5F52505F, 0x50434E08, 0x08020A55, 0x31545350, 0x08082A0B, 
0x32545350, 0x0807240B, 0x33545350, 0x10061D0B, 0x5F032F21, 0x505F4253, 0x45304943, 0x14494348, 
0x53445F11, 0x4DA4044D, 0x6A444943, 0x3A80860C, 0x054D103A, 0x535F032F, 0x43505F42, 0x44483049, 
0x4C144645, 0x53445F04, 0x1270044D, 0x620D0639, 0x746C6975, 0x006E692D, 0x00010311, 0x79616C0D, 
0x2D74756F, 0x11006469, 0x73040A07, 0x0D000003, 0x436E6950, 0x69666E6F, 0x61727567, 0x6E6F6974, 
0x02110073, 0x434D6000, 0x716A5044, 0x1060A460, 0x5F032F21, 0x505F4253, 0x4C304943, 0x14424350, 
0x53445F11, 0x4DA4044D, 0x6A444943, 0x1680860C, 0x1B4A1029, 0x535F032F, 0x43505F42, 0x30503049, 
0x825B3250, 0x46471A48, 0x5F083058, 0x00524441, 0x55535F08, 0x4514014E, 0x53445F19, 0x1270044D, 
0x0D181842, 0x632C3040, 0x61706D6F, 0x6C626974, 0x0E110065, 0x564E0B0A, 0x4E2C4144, 0x63614D56, 
0x30400D00, 0x7665642C, 0x5F656369, 0x65707974, 0x0A0B1100, 0x73696408, 0x79616C70, 0x30400D00, 
0x6D616E2C, 0x12110065, 0x564E0F0A, 0x442C4144, 0x6C707369, 0x412D7961, 0x31400D00, 0x6D6F632C, 
0x69746170, 0x00656C62, 0x0B0A0E11, 0x4144564E, 0x4D564E2C, 0x0D006361, 0x642C3140, 0x63697665, 
0x79745F65, 0x11006570, 0x64080A0B, 0x6C707369, 0x0D007961, 0x6E2C3140, 0x00656D61, 0x0F0A1211, 
0x4144564E, 0x7369442C, 0x79616C70, 0x0D00422D, 0x4143564E, 0x17110050, 0x0004180A, 0x00000000, 
0x000C0003, 0x00000000, 0x00000700, 0x4E0D0000, 0x004D5056, 0x1C0A1F11, 0x00000001, 0x00000000, 
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x4152560D, 0x6F742C4D, 0x736C6174, 
0x00657A69, 0x040A0711, 0x10000000, 0x7665640D, 0x5F656369, 0x65707974, 0x0A0F1100, 0x44564E0C, 
0x61502C41, 0x746E6572, 0x6F6D0D00, 0x006C6564, 0x170A1A11, 0x6469566E, 0x47206169, 0x726F4665, 
0x38206563, 0x20303036, 0x0D005447, 0x2D6D6F72, 0x69766572, 0x6E6F6973, 0x0A281100, 0x69566E25, 
0x20616964, 0x6F466547, 0x20656372, 0x30303638, 0x20544720, 0x6E65704F, 0x45204C47, 0x6E69676E, 
0x4D600065, 0x6A504443, 0x60A46071, 0x2F074010, 0x42535F03, 0x4943505F, 0x50305030, 0x25825B38, 
0x5F304D4A, 0x44415F08, 0x825B0052, 0x4952500B, 0x415F0844, 0x5B005244, 0x45530B82, 0x5F084443, 
0x01524441, 0x5037825B, 0x08415441, 0x5244415F, 0x0B825B01, 0x44495250, 0x44415F08, 0x825B0052, 
0x4345530B, 0x415F0844, 0x14015244, 0x53445F11, 0x4DA4044D, 0x6A444943, 0x9E80860C, 0x04471026, 
0x535F042F, 0x43505F42, 0x30503049, 0x414C3950, 0x3214304E, 0x4D53445F, 0x20127004, 0x75620D04, 
0x2D746C69, 0x11006E69, 0x0D010103, 0x61636F6C, 0x6E6F6974, 0x0A051100, 0x60003102, 0x5044434D, 
0xA460716A, 0x07411060, 0x535F032F, 0x43505F42, 0x43503049, 0x825B4249, 0x5246054F, 0x5F085257, 
0x0C524441, 0x00030000, 0x50475F08, 0x140B0A45, 0x445F0447, 0x70044D53, 0x0D063412, 0x6C697562, 
0x6E692D74, 0x01031100, 0x77660D00, 0x74726F70, 0x07110073, 0x0002040A, 0x640D0000, 0x63697665, 
0x64692D65, 0x0A071100, 0x00304404, 0x434D6000, 0x716A5044, 0x1060A460, 0x5F032F21, 0x505F4253, 
0x53304943, 0x14415441, 0x53445F11, 0x4DA4044D, 0x6A444943, 0x8180860C, 0x2F211026, 0x42535F03, 
0x4943505F, 0x43485530, 0x5F111431, 0x044D5344, 0x49434DA4, 0x860C6A44, 0x103A3480, 0x5F032F21, 
0x505F4253, 0x55304943, 0x14324348, 0x53445F11, 0x4DA4044D, 0x6A444943, 0x3580860C, 0x2F21103A, 
0x42535F03, 0x4943505F, 0x43485530, 0x5F111433, 0x044D5344, 0x49434DA4, 0x860C6A44, 0x103A3680, 
0x5F032F21, 0x505F4253, 0x55304943, 0x14344348, 0x53445F11, 0x4DA4044D, 0x6A444943, 0x3780860C, 
0x2F21103A, 0x42535F03, 0x4943505F, 0x43485530, 0x5F111435, 0x044D5344, 0x49434DA4, 0x860C6A44, 
0x103A3880, 0x5F032F21, 0x505F4253, 0x55304943, 0x14364348, 0x53445F11, 0x4DA4044D, 0x6A444943, 
0x3980860C, 0x2F21103A, 0x42535F03, 0x4943505F, 0x43485530, 0x5F111449, 0x044D5344, 0x49434DA4, 
0x860C6A44, 0x083A3C80, 0x30424449, 0x040A0711, 0x00000000, 0x42444908, 0x0A071131, 0x00000004, 
0x094F1400, 0x4449434D, 0x0945A002, 0x697B7069, 0x8800FF0A, 0x30424449, 0x7A700000, 0x000B697B, 
0x080A00FF, 0x44498800, 0x00013042, 0x7B931FA0, 0x00000C69, 0x0000FFFF, 0x02111270, 0x7665640D, 
0x2D656369, 0x49006469, 0x60304244, 0x7A0449A1, 0x69100A69, 0x0A697B70, 0x498800FF, 0x00314244, 
0x7B7A7000, 0xFF000B69, 0x00080A00, 0x42444988, 0x70000131, 0x0D042012, 0x646E6576, 0x692D726F, 
0x44490064, 0x640D3042, 0x63697665, 0x64692D65, 0x42444900, 0x434D6031, 0x71685044, 0xA460A460, 
0xA3A3A300

 

 

EDIT: Ok after changing the first SSDT code i used with this it works, now i have all the device correctly recognized and working as expected but the boot time is longer now i counted 58 spin...

 

EDIT2: The 58 spin was something wrong with jMicron, It was enabled but not recognized, now I've disabled it in bios and it boots in 12 spin 5 less than Chameleon2RC5 r118 on HD (on the SATA1 install). I think that maybe there is no code in SSDT i need to check...

Now I'm finally again able to continue testing Revolution.

 

EDIT3: I've modded again the SSDT to match the DSDT I use with Chameleon and now JMicron works good, just a spin more at boot. I'm now trying to reduce the Extensions.mkext to a minimal one starting from yours suggestions, i'll post the results.

 

EDIT4: With the kest you listed and com.apple.iokit.IOBDStorageFamily i can boot without errors in kernel.log, but the boot time is now 28 rev instead of 14...

With this list (I don't have an apple keyboard) i get still more revs than with the full mkext:

AppleACPIPlatform.kext		
AppleAHCIPort.kext		
AppleAPIC.kext			
AppleFSCompressionTypeZlib.kext	
AppleFileSystemDriver.kext	
AppleHPET.kext			
AppleIntelCPUPowerManagement.kext
AppleLPC.kext			
AppleMatch.kext			
ApplePlatformEnabler.kext	
AppleProfileFamily.kext		
AppleRTC.kext			
AppleSMBIOS.kext 
fakesmc.kext		
IOACPIFamily.kext		
IOAHCIFamily.kext
IOBDStorageFamily.kext
IOCDStorageFamily.kext
IODVDStorageFamily.kext
IOHIDFamily.kext 
IOPCIFamily.kext 
IOPlatformPluginFamily.kext 
IOSCSIArchitectureModelFamily.kext
IOSCSIParallelFamily.kext
OSvKernDSPLib.kext 
Quarantine.kext 
Sandbox.kext 
System.kext

 

EDIT5: I'm writing from a fresh install on a 8GB USBstick with SL installed with my working Revolution,first start was more than 90 spins but after setting up user and a first permissions repair, it starts in 32 spins and that is not bad.

The strange thing is that there are none of the SATA device they are all disabled in BIOS like before but in SL i can see only the USB one.

Do you think this is normal?

Now i'll try to enable them in bios and see what happen...

Nothing, still SATA unrecognized from a USB install...

[Master Chief]

...

nothing more than "arch=i386 boot-id=uuid boot-uuid=8B09DAB6-B2F0-3C1F-9D74-0C133A62F158"

You need to add something like:

		<key>Graphics Mode</key>
	<string>1600x1200x32</string>

You are on your way, but it should boot in under 10 revs with all drives disabled in the BIOS. And please note that you need to check kernel.log because you should not see this: "Waiting for DMOS..." because that basically means that it can boot even faster – will take off 5 seconds from your kernel.log boot time.

 

Also. You need to boot at least a few times before everything is setup properly, but I have yet to figure out why it (some OS X process) works this way.

 

And yes. You should see all attached hard drives and USB drives on your desktop – that is when you have changed the finder preferences for it – otherwise it means that a required kext is missing.

 

Notes: I have five hard drives in my Hack of which one HD with three Snow Leopard partitions on it (Boot/Data and User) and another HD as secondary (backup) Snow Leopard boot drive, and I have never had any troubles booting with the latest versions of Revolution.

 

And Revolution v0.6.20 (Revolution v0.6.19 with patches from post #62 and some minor cleanups) on my main HD takes 6.10 revs to boot. Which is great because on another HD (same brand/type) it takes much longer to boot. Like 19-22 revs.

 

The only thing left to do is to try a (USB) RAID setup and/or to install SSD drives to speed up my boot process. Which won't happen soon due to my involvements in other projects.

[scrax]

You need to add something like: ...

 

Waiting for DMOS don't show up from a long time now, also in chameleon with the dsdt I'm using, same in Revolution since v0.4.3.

 

I can see all the drives and USB if I start with Revolution on USBBOOT, the problem comes when I boot with Revolution on a USB installation, in that case I can boot but no SATA drives are connected. Extensions.mkext and com.apple.Boot.plist are the default one 'cause it's all on the USB stick...

I'll try to use the Chameleon's boot to see if the drive are recognized.

 

I've also tried to make a RAID with 4x2GB usb key to have a 8GB Drive stripped with another 8GB USB key but I can't install boot0, so I can't go on...

 

My next step is to try Revolution v0.6.19 on HD instead of USB to see how fast it is, for now from USB it's faster than Chameleon2RC5 r118 booting from HD

[Master Chief]

Waiting for DMOS don't show up from a long time now, also in chameleon with the dsdt I'm using, same in Revolution since v0.4.3.

Perfect then.

 

I can see all the drives and USB if I start with Revolution on USBBOOT, the problem comes when I boot with Revolution on a USB installation, in that case I can boot but no SATA drives are connected. Extensions.mkext and com.apple.Boot.plist are the default one 'cause it's all on the USB stick...

I'll try to use the Chameleon's boot to see if the drive are recognized.

First. I mainly boot without USBBOOT from my hard disk with Revolution v0.6.20 on it, and it doesn't matter if I enable or disable hard drives in the BIOS. I say this because it should work, without a hassle, if only it finds the kext for your SATA controller. Do you have all required kexts for it in /System/Library/Extensions and removed everything in: /System/Library/Caches/com.apple.kext.caches/Startup so that OS X can re-create it for you?

 

I've also tried to make a RAID with 4x2GB usb key to have a 8GB Drive stripped with another 8GB USB key but I can't install boot0, so I can't go on...

I can't test this myself right now – reviewing the new Intel i7 980 eXtreme – but hope to give it a try next week or so.

 

My next step is to try Revolution v0.6.19 on HD instead of USB to see how fast it is, for now from USB it's faster than Chameleon2RC5 r118 booting from HD

Sounds good.

 

p.s. Do you plan to including your SMBIOS data like I did here?