1109 replies to this topic

[Master Chief]

Work in progress – a painful slow progress even...

Introduction

I started this new topic here because I think that most of us are ready for the next step.  I mean our hacks are working, mostly thanks to devoted hackers / developers thank you very much, but the Chameleon boot process is still taking ages.  Way too long for my taste.  Let's change that shall we.

And there are of course a number of things that I tried already, but I cannot possibly be the only person who tried to speed up the boot process now can I.  So.  Are you also interested in speeding up your boot process, then please join me and start sharing ideas and information, so that everyone here can benefit from our work.

This is of course just an initial announcement, but good things are about to happen.... that is when enough people share the same passion and need for speed.

What are your plans Chief?

First.  This all is still A WORK IN PROGRESS – pardon the shouting – and it will take me some time before everything I want to talk about is either added here or linked to.  And certain parts of my text will be rewritten, replaced with better text.  At least two subjects here already will eventually be moved over to a new thread.  So that we can link to it.

Now.  There are several different areas where we can improve things – at least that's how I see things.  Some are easy.  Others more complicated.  Most of my work here however will be limited to the boot process in general.  I'll also mention / link to previously explored subjects like DSDT patching, but hardware hacking like BIOS modifications may only appear in the form of links here.  And let's be perfectly clear about one thing; flashing a modified BIOS may end in misery.

Also.  You are doing everything on your own risk!   Don't feel comfortable?  Then please don't even start.  Still here?  Fine.  Let us start with a relatively easy process.  Gathering data.  And for this we'll be looking at the boot process first.

Boot process

I don't intent to explain every single little detail here because there are plenty other places on the web doing a great job already.  Google or Bing should help you get there.  However.  There are a few areas we should name:

1) BIOS Post – The time it takes to go through the BIOS initialization, this includes ACPI and USB initialization.
    - Disabling ACPI for all but the boot drive shortens the time it takes to go through this process.
2) Text Spinner Duration – The time it takes to load boot2.
    - With the in-BIOS version of Revolution this process is eliminated.
3) Post Screen Blanking – The time it takes before the screen turns gray.
    -  I have modified some of the Chameleon function to perform this step a little quicker.
4) Screen Blanking Duration – The duration of the gray screen.
    - The time it takes to load either Extensions.mkext or the kexts one after the other (need to check with a reduced copy of Extensions.mkext again).
5) Post Spinner Initialization – The time it takes before the spinner starts revving.
    - Undetermined (Kernel load time?).
6) Spinner Duration – also known as the Kernel load time.
    - Undetermined (kernel initialization time?).


SSD Drive(s)

Having one or more SSD drives helps a great deal, and this task can be done by everyone.  And this is by far the best way to boost your boot process.  Just have a look at the size of the kernel file, which is one of the big files that needs to be loaded at boot time.  No surprises here, but even with a fast SSD drive there are things to speed up the process.  Let's have a closer look.

pro et contra: Still too expensive compared to regular hard drives, but this is a huge win.  A must have!

Removing Unused Kexts

I presume that most people here already tried this.  And some seem to think that is pointless.  Probably because Extensions.mkext is not that big after all.  Let's look at it.  Ah only 8.9MB here.  Now try this on a simple USB stick and it will do wonders.  It took five revs off here.  And not surprisingly, because there was like 40% less to load.  Only 5.4MB now.  Seems like this actually does something.  Even on your ultra fast hard disk.  But this might not be what you are looking for.  Probably not.  And I could remove a few more, but I have only 111 kexts left now in: /Systm/Library/Extensions/

pro et contra: Too much work for only a little gain.  Has to be done carefully, and after each upgrade or installation.   A must have for CD/USB boot only!

DSDT Patching / Stripping

The DSDT (Differentiated System Description Table) is one of the other files that are loaded at boot time.  And this work is actually done twice (sort of) because it is part of the ACPI in the BIOS.  So why do we load it?  Simple.  It was not written for OS X and thus we have to patch it.  My P5K PRO BIOS reserved 35,633 byte for the DSDT.

There are also four other tables called SSDT (Secondary System Description Table) in my P5K PRO BIOS, which are much smaller, but these are totally meaningless to OS X.  A waste of time to load them.  That's why I removed them.  You can read more about this task here and here.

pro et contra: Been there already.  A big plus and a must do!

DSDT Loading

It should be clear by now that reducing the file size of your DSDT is a good thing.   Not only will it load faster, but it will also take less time to do its thing.  And the change is pretty obvious when you start with a large file and then use say one of only 2480 bytes.  That's how small my DSDT is and I don't even have to load it anymore.  Nope.  And here is where Revolution comes into place.  It not only includes a patched and rather common DSDT but it also enables you to load and/or incorporate a custom SSDT with all your patches.

Incorporating DSDT (move to new thread)

To be added...

pro et contra:  This is an absolute must do for the die hard hacker!

static uint32_t DSDT_Table[] = { // DSDT in little-endian format
	0x54445344, 0x000009B0, 0x30419401, 0x00363139, 0x31393041, 0x32333036, 0x00000032, 0x4C544E49, 
	0x20080926, 0x5F154E10, 0x085F5250, 0x5F445350, 0x0A050C12, 0x0A000005, 0x50434EFC, 0x53500855, 
	0x3C125F53, 0x060D1204, 0x100A0000, 0x5350100A, 0x12003154, 0x0000060D, 0x100A100A, 0x32545350, 
	0x060E1201, 0x100A0000, 0x5350100A, 0x020A3354, 0x00060E12, 0x0A100A00, 0x54535010, 0x08030A34, 
	0x5F545343, 0x04054E12, 0x1C12030A, 0x0A141104, 0x000C8211, 0x0002017F, 0x00000000, 0x00000000, 
	0x01010079, 0x12041C0B, 0x1411041D, 0x0C82110A, 0x00080100, 0x00081400, 0x00000000, 0x0A007900, 
	0xF40B0102, 0x041D1201, 0x110A1411, 0x01000C82, 0x15000008, 0x00000008, 0x79000000, 0x0A030A00, 
	0x5BFA0A55, 0x50432683, 0x10013155, 0x06000008, 0x53535006, 0x53505F5F, 0x53500653, 0x505F5F44, 
	0x43064453, 0x5F5F5453, 0x5B545343, 0x50432683, 0x10023255, 0x06000008, 0x53535006, 0x53505F5F, 
	0x53500653, 0x505F5F44, 0x43064453, 0x5F5F5453, 0x5B545343, 0x50432683, 0x10033355, 0x06000008, 
	0x53535006, 0x53505F5F, 0x53500653, 0x505F5F44, 0x43064453, 0x5F5F5453, 0x5B545343, 0x50432683, 
	0x10043455, 0x06000008, 0x53535006, 0x53505F5F, 0x53500653, 0x505F5F44, 0x43064453, 0x5F5F5453, 
	0x5B545343, 0x4F494280, 0x900C0053, 0x01CFF8E0, 0x420B815B, 0x01534F49, 0x42535341, 0x764E1008, 
	0x5F42535F, 0x554C825B, 0x30494350, 0x44415F08, 0x5F080052, 0x00444955, 0x42425F08, 0x5F08004E, 
	0x0C444943, 0x030AD041, 0x49485F08, 0xD0410C44, 0x5F08080A, 0x0A443353, 0x505F0802, 0x40125452, 
	0x0B12120E, 0xFFFF0C04, 0x00000001, 0x0B12100A, 0xFFFF0C04, 0x00010001, 0x0C12110A, 0xFFFF0C04, 
	0x020A0001, 0x12120A00, 0xFF0C040C, 0x0A0001FF, 0x130A0003, 0x0C040B12, 0x001FFFFF, 0x120A0000, 
	0x0C040B12, 0x001FFFFF, 0x160A0001, 0x0C040C12, 0x001FFFFF, 0x0A00020A, 0x040B1212, 0x1DFFFF0C, 
	0x0A000000, 0x040C1217, 0x1AFFFF0C, 0x00020A00, 0x0B12120A, 0xFFFF0C04, 0x0000001B, 0x0B12160A, 
	0xFFFF0C04, 0x0001001D, 0x0C12130A, 0xFFFF0C04, 0x020A001D, 0x12120A00, 0xFF0C040B, 0x00001AFF, 
	0x12100A00, 0xFF0C040B, 0x01001AFF, 0x12150A00, 0xFF0C040B, 0x000002FF, 0x12100A00, 0xFF0C040B, 
	0x010002FF, 0x12110A00, 0xFF0C040B, 0x00001CFF, 0x12110A00, 0xFF0C040B, 0x01001CFF, 0x08100A00, 
	0x30315241, 0x12042C12, 0xFF0B0409, 0x0A0000FF, 0x04091210, 0x01FFFF0B, 0x12110A00, 0xFF0B040A, 
	0x00020AFF, 0x0A12120A, 0xFFFF0B04, 0x0A00030A, 0x52410813, 0x2C123131, 0x04091204, 0x00FFFF0B, 
	0x12110A00, 0xFF0B0409, 0x0A0001FF, 0x040A1212, 0x0AFFFF0B, 0x130A0002, 0x0B040A12, 0x030AFFFF, 
	0x08100A00, 0x33315241, 0x12042C12, 0xFF0B0409, 0x0A0000FF, 0x04091213, 0x01FFFF0B, 0x12100A00, 
	0xFF0B040A, 0x00020AFF, 0x0A12110A, 0xFFFF0B04, 0x0A00030A, 0x57500812, 0x06123439, 0x0A090A02, 
	0x16825B04, 0x4845434D, 0x49485F08, 0x10060C44, 0x5F080600, 0x0A415453, 0x21825B0B, 0x32503050, 
	0x44415F08, 0x00000C52, 0x41060001, 0x5F303152, 0x06545250, 0x34395750, 0x5752505F, 0x0945825B, 
	0x42494350, 0x44415F08, 0x00000C52, 0x5F08001E, 0x12545250, 0x12090743, 0xFF0C040B, 0x000001FF, 
	0x12110A00, 0xFF0C040B, 0x010001FF, 0x12120A00, 0xFF0C040C, 0x0A0001FF, 0x130A0002, 0x0C040C12, 
	0x0001FFFF, 0x0A00030A, 0x040B1210, 0x02FFFF0C, 0x0A000000, 0x040B1212, 0x02FFFF0C, 0x0A000100, 
	0x040C1213, 0x02FFFF0C, 0x00020A00, 0x0C12100A, 0xFFFF0C04, 0x030A0002, 0x12110A00, 0xFF0C040B, 
	0x000003FF, 0x08100A00, 0x5752505F, 0x0A020612, 0x5B040A0B, 0x4C094082, 0x08424350, 0x5244415F, 
	0x1F00000C, 0x33825B00, 0x54455048, 0x49485F08, 0xD0410C44, 0x5F080301, 0x0A415453, 0x435F080F, 
	0x17115352, 0x0122140A, 0x01002200, 0x00000986, 0xFED00000, 0x00000400, 0x825B0079, 0x43545222, 
	0x485F085F, 0x410C4449, 0x08000BD0, 0x5352435F, 0x0A0A0D11, 0x00700147, 0x02010070, 0x825B0079, 
	0x4D495425, 0x485F0852, 0x410C4449, 0x080001D0, 0x5352435F, 0x0D0A1011, 0x00400147, 0x04010040, 
	0x79000122, 0x0F825B00, 0x41544153, 0x44415F08, 0x00020C52, 0x825B001F, 0x4348451B, 0x415F0849, 
	0x070C5244, 0x08001D00, 0x5752505F, 0x0A020612, 0x5B040A0D, 0x48551B82, 0x5F084943, 0x0C524441, 
	0x001A0007, 0x52505F08, 0x02061257, 0x040A0D0A, 0x5021825B, 0x08345030, 0x5244415F, 0x1C00000C, 
	0x52410600, 0x505F3031, 0x50065452, 0x5F343957, 0x5B575250, 0x30502182, 0x5F083550, 0x0C524441, 
	0x001C0001, 0x31524106, 0x52505F31, 0x57500654, 0x505F3439, 0x825B5752, 0x50305021, 0x415F0836, 
	0x020C5244, 0x06001C00, 0x33315241, 0x5452505F, 0x39575006, 0x52505F34, 0x21825B57, 0x37503050, 
	0x44415F08, 0x00030C52, 0x4106001C, 0x5F333152, 0x06545250, 0x34395750, 0x5752505F, 0x5021825B, 
	0x08385030, 0x5244415F, 0x1C00040C, 0x52410600, 0x505F3031, 0x50065452, 0x5F343957, 0x5B575250, 
	0x50054782, 0x08395030, 0x5244415F, 0x1C00050C, 0x52410600, 0x505F3131, 0x50065452, 0x5F343957, 
	0x5B575250, 0x54535080, 0x8C0A0253, 0x815B040A, 0x5453500F, 0x10000153, 0x53454D50, 0x5B0F0001, 
	0x414C1782, 0x5F08304E, 0x00524441, 0x52505F08, 0x02061257, 0x030A090A, 0x483A825B, 0x08464544, 
	0x5244415F, 0x1B00000C, 0x505F0800, 0x06125752, 0x0A0D0A02, 0x48805B04, 0x02534344, 0x040A540A, 
	0x4812815B, 0x03534344, 0x5F5F5350, 0x500D0002, 0x0153454D, 0x551B825B, 0x08314348, 0x5244415F, 
	0x1D00000C, 0x505F0800, 0x06125752, 0x0A030A02, 0x1B825B04, 0x32434855, 0x44415F08, 0x00010C52, 
	0x5F08001D, 0x12575250, 0x040A0206, 0x825B040A, 0x4348551B, 0x415F0833, 0x020C5244, 0x08001D00, 
	0x5752505F, 0x0A020612, 0x5B040A0C, 0x48551B82, 0x5F083443, 0x0C524441, 0x001A0000, 0x52505F08, 
	0x02061257, 0x040A0E0A, 0x551B825B, 0x08354348, 0x5244415F, 0x1A00010C, 0x505F0800, 0x06125752, 
	0x0A050A02, 0x1B825B04, 0x36434855, 0x44415F08, 0x00020C52, 0x5F08001A, 0x12575250, 0x200A0206, 
	0x4A10040A, 0x475F5C1E, 0x42144550, 0x304C5F09, 0x5C860039, 0x535F032F, 0x43505F42, 0x30503049, 
	0x020A3250, 0x032F5C86, 0x5F42535F, 0x30494350, 0x35503050, 0x5C86020A, 0x535F032F, 0x43505F42, 
	0x30503049, 0x020A3650, 0x032F5C86, 0x5F42535F, 0x30494350, 0x37503050, 0x5C86020A, 0x535F032F, 
	0x43505F42, 0x30503049, 0x020A3850, 0x032F5C86, 0x5F42535F, 0x30494350, 0x39503050, 0x5C86020A, 
	0x535F032F, 0x43505F42, 0x30503049, 0x020A3450, 0x5F2E5C86, 0x505F4253, 0x0A425257, 0x5F251402, 
	0x0042304C, 0x032F5C86, 0x5F42535F, 0x30494350, 0x42494350, 0x5C86020A, 0x42535F2E, 0x5257505F, 
	0x14020A42, 0x4C5F0445, 0x86004430, 0x5F032F5C, 0x505F4253, 0x45304943, 0x0A494348, 0x2E5C8602, 
	0x5F42535F, 0x42525750, 0x5C86020A, 0x535F032F, 0x43505F42, 0x48553049, 0x020A4943, 0x5F2E5C86, 
	0x505F4253, 0x0A425257, 0x5F251402, 0x0033304C, 0x032F5C86, 0x5F42535F, 0x30494350, 0x31434855, 
	0x5C86020A, 0x42535F2E, 0x5257505F, 0x14020A42, 0x304C5F25, 0x5C860034, 0x535F032F, 0x43505F42, 
	0x48553049, 0x020A3243, 0x5F2E5C86, 0x505F4253, 0x0A425257, 0x5F251402, 0x0043304C, 0x032F5C86, 
	0x5F42535F, 0x30494350, 0x33434855, 0x5C86020A, 0x42535F2E, 0x5257505F, 0x14020A42, 0x304C5F25, 
	0x5C860045, 0x535F032F, 0x43505F42, 0x48553049, 0x020A3443, 0x5F2E5C86, 0x505F4253, 0x0A425257, 
	0x5F251402, 0x0035304C, 0x032F5C86, 0x5F42535F, 0x30494350, 0x35434855, 0x5C86020A, 0x42535F2E, 
	0x5257505F, 0x14020A42, 0x324C5F25, 0x5C860030, 0x535F032F, 0x43505F42, 0x48553049, 0x020A3643, 
	0x5F2E5C86, 0x505F4253, 0x0A425257, 0x1D825B02, 0x42525750, 0x49435F08, 0xD0410C44, 0x5F080C0C, 
	0x0A444955, 0x535F08AA, 0x0B0A4154, 0x4D53805B, 0x0B014549, 0x050A0830, 0x5316815B, 0x0145494D, 
	0x53500400, 0x00014531, 0x5004001B, 0x01533153, 0x505F1F14, 0xA0015354, 0x68939218, 0x0170050A, 
	0x53315350, 0x53500170, 0x68704531, 0x42535341, 0x575F0C14, 0xA4014B41, 0x00020412, 0x535F0800, 
	0x06125F30, 0x00000004, 0x535F0800, 0x06125F31, 0x00000104, 0x535F0800, 0x07125F33, 0x00050A04, 
	0x5F080000, 0x125F3453, 0x060A0407, 0x08000000, 0x5F35535F, 0x0A040712, 0x00000007, 0x434D1114, 
	0xA0025044, 0x0068930A, 0x01031170, 0xA3A36903
};

Incorporating SSDT Table  (move to new thread)

The next thing I did was a rather new approach, sort of, but this enabled me to patch a much smaller file.  Mine now is only 951 bytes, and it includes everything I need for my board: Easy P-States, Sata, HDEF, Graphics card,  PATA, FireWire and two of my very own methods being MCDP and MCID.  And here is it:

DefinitionBlock ("ssdt.aml", "SSDT", 1, "MC", "POWERM", 0x00000001)
{
	External (_SB.PCI0.SATA, DeviceObj)
	External (_SB.PCI0.HDEF, DeviceObj)
	External (_SB.PCI0.P0P2, DeviceObj)
	// External (_SB.PCI0.P0P8, DeviceObj)
	External (_SB.PCI0.PCIB, DeviceObj)

	Scope (_PR)
	{
		Name (NCPU, 0x04)							// Number of processor cores.
		Name (PST1, 0x4720)							// Easy P-State values.
		Name (PST2, 0x071E)
		Name (PST3, 0x461C)
		Name (PST4, 0x0616)
	}

	Scope (_SB.PCI0.SATA)
	{
		Method (_DSM, 4, NotSerialized)
		{
			 Return (MCID (Arg2, 0x26818086))					// MacPro3,1 – Both device-id and vendor-id specified!
		}
	}

	Scope (_SB.PCI0.HDEF)
	{
		Method (_DSM, 4, NotSerialized)
		{
			Store (Package (0x04)
			{
				"layout-id",
				Buffer (0x04)
				{
					0x73, 0x03, 0x00, 0x00
				},

				"PinConfigurations",
				Buffer (Zero) {}	  
			}, Local0)

			Return (MCDP (Arg2, RefOf (Local0)))
		}
	}

	Scope (_SB.PCI0.P0P2)							// PCI Express Root Port
	{				
		// 427 bytes.
		Device (PXS1)								// Newly added device.
		{
			Name (_ADR, Zero)
			Name (_SUN, One)
			Method (_DSM, 4, NotSerialized)
			{
				Store (Package (0x18)
				{
					"@0,compatible", 
					Buffer (0x0B)
					{
						"NVDA,NVMac"
					}, 

					"@0,device_type", 
					Buffer (0x08)
					{
						"display"
					}, 

					"@0,name", 
					Buffer (0x0F)
					{
						"NVDA,Display-A"
					}, 

					"@1,compatible", 
					Buffer (0x0B)
					{
						"NVDA,NVMac"
					}, 

					"@1,device_type", 
					Buffer (0x08)
					{
						"display"
					}, 

					"@1,name", 
					Buffer (0x0F)
					{
						"NVDA,Display-B"
					}, 

					"NVCAP", 
					Buffer (0x18)
					{
						0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0B, 0x00, 
						0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 
						0x00, 0x00, 0x00, 0x00
					}, 

					"NVPM", 
					Buffer (0x1C)
					{
						0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
						0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
						0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
						0x00, 0x00, 0x00, 0x00
					}, 

					"VRAM,totalsize", 
					Buffer (0x04)
					{
						0x00, 0x00, 0x00, 0x20
					}, 

					"device_type", 
					Buffer (0x0D)
					{
						"NVDA,Parent"
					}, 

					"model", 
					Buffer (0x17)
					{
						"nVidia GeForce 9600 GT"
					}, 

					"rom-revision", 
					Buffer (0x2B)
					{
						"nVidia GeForce 9600 GT OpenGL Engine"
					}
				}, Local0)

				Return (MCDP (Arg2, RefOf (Local0)))
			}
		}
	}

	/* Comment this out when you have/add PATA hardware!
	Scope (_SB.PCI0.P0P8)
	{
		Device (PATA)
		{
			Name (_ADR, Zero)

			Device (PRID)
			{
				Name (_ADR, Zero)
			}

			Device (SECD)
			{
				Name (_ADR, One)
			}

			Method (_DSM, 4, NotSerialized)
			{
				Return (MCID (Arg2, 0x269e))
			}
		}
	} */

	Scope (_GPE)
	{
		Method (_L18, 0, NotSerialized)						// FireWire support.
		{
			Notify (\_SB.PCI0.PCIB.FRWR, Zero)
		}
	}

	Scope (_SB.PCI0.PCIB)
	{
		Device (FRWR)
		{
			Name (_ADR, 0x00030000)
			Name (_GPE, 0x18)

			Method (_DSM, 4, NotSerialized)
			{
				Store (Package (0x02)
				{
					"fwhub",
					Buffer (0x04)
					{
						0x00, 0x00, 0x00, 0x00
					}
				}, Local0)

				Return (MCDP (Arg2, RefOf (Local0)))
			}
		}
	}

	// 18 Bytes.
	Method (MCDP, 2, NotSerialized)											  // New Method V1.3 – By Master Chief.
	{
		If (LEqual (Arg0, Zero))												 // Function index: 0
		{
			Return (Buffer (One) { 0x03 })
		}

	Return (DeRefOf (Arg1))							// Modified return value!
	}

	Name (IDB0, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 })			// New Method V1.4 – By Master Chief.
	Name (IDB1, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 })
	Method (MCID, 2, NotSerialized)
	{
		If (Arg1) // Either a device-id like 0x2693 or a 32-bit combo like 0x269e8086 with both a device-id and a vendor-id.
		{
			Store (And (Arg1, 0xFF), Index (IDB0, Zero))			// 0x9e => BUF0 is now 0x9e 0x00 0x00 0x00
			Store (ShiftRight (And (Arg1, 0xFF00), 0x08), Index (IDB0, One))	// 0x2600 => 0x26 => BUF0 is now 0x9e 0x26 0x00 0x00

			If (LEqual (And (Arg1, 0xFFFF0000), Zero))
			{
				Store (Package (0x02)
				{
					"device-id",
					IDB0							// 0x9e 0x26 0x00 0x00
				}, Local0)
			}
			Else
			{
										// BUF0 is now 0x86 0x80 0x00 0x00
				ShiftRight (Arg1, 0x10, Arg1)					// 0x269e0000 => 0x269e
				Store (And (Arg1, 0xFF), Index (IDB1, Zero))					// 0x9e => BUF1 is now 0x9e 0x00 0x00 0x00
				Store (ShiftRight (And (Arg1, 0xFF00), 0x08), Index (IDB1, One)) // 0x2600 => 0x26 => BUF1 is now 0x9e 0x26 0x00 0x00
				Store (Package (0x04)
				{
					"vendor-id",
					IDB0,							// 0x86 0x80 0x00 0x00
					"device-id",
					IDB1							// 0x9e 0x26 0x00 0x00
				}, Local0)
			}

			Return (MCDP (Arg2, RefOf (Local0)))
		}

		Return (Zero)
	}
}

And this in converted AML formad looks like this:

static uint32_t SSDT_Table[] = { // SSDT in little-endian format
	0x54445353, 0x000003B7, 0x434D7601, 0x00000000, 0x45574F50, 0x00004D52, 0x00000001, 0x4C544E49, 
	0x20080926, 0x505F2C10, 0x4E085F52, 0x0A555043, 0x53500804, 0x200B3154, 0x53500847, 0x1E0B3254, 
	0x53500807, 0x1C0B3354, 0x53500846, 0x160B3454, 0x2F211006, 0x42535F03, 0x4943505F, 0x54415330, 
	0x5F111441, 0x044D5344, 0x49434DA4, 0x860C6A44, 0x10268180, 0x032F044D, 0x5F42535F, 0x30494350, 
	0x46454448, 0x445F3C14, 0x70044D53, 0x0D042B12, 0x6F79616C, 0x692D7475, 0x07110064, 0x0373040A, 
	0x500D0000, 0x6F436E69, 0x6769666E, 0x74617275, 0x736E6F69, 0x00021100, 0x434DA460, 0x716A434D, 
	0x1B491060, 0x535F032F, 0x43505F42, 0x30503049, 0x825B3250, 0x58501A47, 0x5F083153, 0x00524441, 
	0x55535F08, 0x4414014E, 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, 0x0004000B, 0x00000000, 0x00000700, 0x4E0D0000, 
	0x004D5056, 0x1C0A1F11, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 
	0x00000000, 0x4152560D, 0x6F742C4D, 0x736C6174, 0x00657A69, 0x040A0711, 0x20000000, 0x7665640D, 
	0x5F656369, 0x65707974, 0x0A0F1100, 0x44564E0D, 0x61502C41, 0x746E6572, 0x6F6D0D00, 0x006C6564, 
	0x170A1A11, 0x6469566E, 0x47206169, 0x726F4665, 0x39206563, 0x20303036, 0x0D005447, 0x2D6D6F72, 
	0x69766572, 0x6E6F6973, 0x0A281100, 0x69566E2B, 0x20616964, 0x6F466547, 0x20656372, 0x30303639, 
	0x20544720, 0x6E65704F, 0x45204C47, 0x6E69676E, 0xA4600065, 0x434D434D, 0x1060716A, 0x50475F21, 
	0x5F1B1445, 0x0038314C, 0x042F5C86, 0x5F42535F, 0x30494350, 0x42494350, 0x52575246, 0x044B1000, 
	0x535F032F, 0x43505F42, 0x43503049, 0x825B4249, 0x57524639, 0x415F0852, 0x000C5244, 0x08000300, 
	0x4550475F, 0x2214180A, 0x4D53445F, 0x11127004, 0x77660D02, 0x00627568, 0x040A0711, 0x00000000, 
	0x434DA460, 0x716A434D, 0x4D131460, 0x02434D43, 0x689309A0, 0x0311A400, 0x83A40301, 0x44490869, 
	0x07113042, 0x0000040A, 0x49080000, 0x11314244, 0x00040A07, 0x14000000, 0x434D094F, 0xA0024449, 
	0x70690945, 0xFF0A697B, 0x44498800, 0x00003042, 0x697B7A70, 0x00FF000B, 0x8800080A, 0x30424449, 
	0x1FA00001, 0x0C697B93, 0xFFFF0000, 0x12700000, 0x640D0211, 0x63697665, 0x64692D65, 0x42444900, 
	0x49A16030, 0x0A697A04, 0x7B706910, 0x00FF0A69, 0x42444988, 0x70000031, 0x0B697B7A, 0x0A00FF00, 
	0x49880008, 0x01314244, 0x20127000, 0x65760D04, 0x726F646E, 0x0064692D, 0x30424449, 0x7665640D, 
	0x2D656369, 0x49006469, 0x60314244, 0x5044434D, 0xA4607168, 0xA300A460
};

And this gets injected from within the boot loader.  More about this at a later stage.

pro et contra: The next step and a must do for die hard hackers!


Gathering Data

To be added...


Text Spinner

I assume that most people know what I mean with the text spinner.  It's nothing more than a few simple characters popping up in the top left corner of your screen.  And just before the Apple boot logo appears.  And the used characters are defined like this:

static char indicator[] = {'-', '\\', '|', '/', '-', '\\', '|', '/', '\0'};

And one of the first things I did was to remove all of the text spinner (code) but then I realized something.  Without this it is much harder, if not impossible to tell what is going on.  How long it takes.  I basically removed an easy way of measuring the time it takes (a certain process we are interested in).  And that is why I replaced it with the following:

static char indicator[] = {'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', '\0'};

There's another small modification required.  This to make it a little easier for us to spot the characters:

static char		  string[2] = {'\0', '\0'};

Nothing really mind blowing you say, but this showed me that I was wrong.  Yes sir.  I did not see three, but five (or even six) characters.  That's how easy it is to be wrong.

Hiding the text spinner was easy, yes, but it doesn't really speed up the boot process.  Eliminate the time it takes to get past this stage will.  A quiet boot process will also still be part of the deal, but at a later stage.  We first need to collect data about the time certain functions take.  We need this before we can change/improve anything.  Annoying, but also very true.

Boot Logo

On my P5K PRO with stock speed (2.5GHz) I see three five or six of the previously mentioned text characters, but your mileage may vary.  I know that booting from my USB stick takes a lot more time, and there the text spinner is a lot longer in action.

Next is this ugly Apple boot logo.  This normally only takes very little time to show up.  Even on my old NVIDIA 9600GT.

Then (after a lot of HD action) I get to see a graphical throbber.  And I don't start counting before it reaches the top for the first time.  That would be one rev.  Now.  Let's assume that it stops after five revolutions (spins) and on the second marker.  That would be: 5.10  And each next line will add another five (5).  This way we all how to I  do things.  Easy huh?

The boot logo in my boot loader is still the same as the original, but it appears a bit earlier in the boot process. This way it seems to take longer before the spinner shows up and start spinning, but I hope to change this process a.s.a.p.  To speed it up even further that is.

Log files

Your log files (kernel.log and system.log) are another way of getting data.  The boot process there usually starts with npvhash=4095 and it may end with your network adapter or audio.  This depends in what you have installed.  Just have a look at it.

And now that we are looking at kernel.log... check the lines with: AppleIntelCPUPowerManagement: initialization complete and DSMOS has arrived which will quickly become important.  More about this at a later stage.

A First Test

The last thing for today is a test.  Simply disable your audio and network device in the BIOS and boot twice, to see what that saves you.  And yes, you need it.  I know, but we are going to change things remember?

Now.  I see five (5) revs of the graphical throbber (below the Apple boot logo) with audio and network disabled.  Which is four (4) revs less.  And this without doing anything else.  Just the factory 2.5GHz clock speed.  No SSD or any crazy stuff.   And yes we have to know what is taking so long... before we can start fixing things.  This might actually trigger some attention of other developers.  Which of course never hurts.

Note: The times given here are without Revolution in the BIOS activated!

This was update one.  I'll be back with more next time.


Verifying HPET compatibility

There's one thing you must do before you flash your BIOS with a patched DSDT and that is to verify that it works.  For this step you need a working/patched DSDT.  And one that enables you to remove both hpet.c and hpet.h from Chameleon's libsaio folder.

Below you'll find a part of the Makefile we are going to change:

#SAIO_OBJS = table.o asm.o bios.o biosfn.o \
	disk.o sys.o cache.o bootstruct.o \
	stringTable.o load.o pci.o memory.o misc.o \
	[color="#008000"]ufs.o ufs_byteorder.o[/color] \
	vbe.o [color="#008000"]nbp.o[/color] hfs.o hfs_compare.o \
	xml.o [color="#008000"]ntfs.o msdos.o[/color] md5c.o device_tree.o \
	freq_detect.o platform.o [color="#FF8C00"]dsdt_patcher.o[/color] \
	smbios_patcher.o fake_efi.o [color="#008000"]ext2fs.o[/color] \
	[color="#FF0000"]hpet.o[/color] spd.o [color="#008000"]usb.o pci_setup.o[/color] \
	[color="#008000"]device_inject.o nvidia.o ati.o[/color]

Remove the red part and save the file.  Now fix the caller force_enable_hpet() in pci_setup.c  Simply comment it out and do the usual: make clean and make > logfile.txt combo.  Now copy sym/i386/boot to / and reboot (crossing your fingers).  Does it boot?  No HPET error?  Great.  If not you have work to do (patch your DSDT's HPET device).  You should now be ready for the next step; assuming that all went well of course.  But please.  Do not continue with the next step until this works for you!

Notes: I removed all green items for my boot loader aka Revolution.  I also renamed dsdt_patcher in the Makefile to acpi_patcher but the actual code is new.  And I had to change almost every single file of Chameleon, but the fun part is that Revolution (the Hard Disk version that is) is now only 67360 bytes!  And everything I need works out of the box.  Even without smbios.plist or no /Extra/ at all.

Preparing for dsdt_patcher removal

The DSDT patcher in Chameleon is great when you need to patch something, but our goal is to speed up the boot process.  And to first load a table from BIOS to have it replaced with a different one from disk, isn't really helping us with this process.  That is why I removed it.  And completely.  Here is what I did.
  
I first replaced function setupAcpi() in Chameleon with the following lines:

	uint64_t acpi20_p = (uint32_t)getACPIBaseAddress();
	addConfigurationTable(&gEfiAcpi20TableGuid, &acpi20_p, "ACPI_20");

Note: This only works with a ACPI 2.0 compliant BIOS  People with a ACPI 1.0 BIOS either need a new or patched BIOS first (no help here).

The first line isn't even required.  Not if you know the address that is; you can get the address from your ACPI dump.  Just look for something like (example):

ACPI: RSDP 000FBC10, 0024 (r2 ACPIAM)

Which happens to be the address I am using.  Don't have your system ACPI dump handy?  Then add this helper function:

static struct acpi_2_rsdp* getACPIBaseAddress()
{
	void *baseAddress = (void*)ACPI_RANGE_START;
	
	for (; baseAddress <= (void*)ACPI_RANGE_END; baseAddress += 16)
	{
		if (*(uint64_t *)baseAddress == ACPI_SIGNATURE_UINT64_LE)
		{
			uint8_t csum = checksum8 (baseAddress, 20);
			
			if (csum == 0)
			{
				uint8_t revision = ((struct acpi_2_rsdp*)baseAddress)->Revision;
				
				if (revision > 0 && checksum8(baseAddress, sizeof(struct acpi_2_rsdp)) == 0)
					return baseAddress;
			}
		}
	}
	return NULL;
}

Add the above code to fake_efi.c and let it run once (print the address).  That should do the trick.  Oh and don't forget to remove it afterwards (or comment it out) to keep the file size as small as possible (we need this for Revolution).

What is Revolution?

Revolution is a new experimental boot loader aimed at improving our boot time.  Revolution is based on the source code of Chameleon v2.0 RC 4 (which is a fork of Apple's boot-132 source code) but Revolution should not be seen as a fork, but as another (unofficial) "branch" of Chameleon.

And the number one issue I have with Chameleon is the fact that one cannot compile an "official" Chameleon version without a GUI.  Which is too bad, but also why I got into 'Chameleon' hacking in the first place.

You can find the source code of Revolution in one of my posts here.  Please note that since Revolution is my experimental, and still unofficial branch, of Chameleon, which is why I only include the files I work with / modify (as in I do not include all files).  The reason for this is simply that I want to concentrate on boot2 first.  This to prevent possible boot issues.

Warning

Flashing a BIOS is relatively easy.  Unlike BIOS patching.  Don't even start when you don't know what you are doing!   The risk involved should not to be taken lightly.  This can basically wreck a good working motherboard.  Please think twice before you do this.  You are warned!

Happy Hacking!

[DB1]

Master Chief, on Jan 24 2010, 03:18 PM, said:

I am starting this new topic here because I think that most of us are ready for the next step.  I mean our hacks are working, mostly thanks to devoted hackers / developers, but the boot process is still taking ages.  Way too long for my taste.

And there are of course a number of things that I tried already, but I cannot possibly be the only person who tried to speed up the boot process now can I.  So.  Are you also interested in speeding up your boot process, then please join me and start sharing ideas and information, so that everyone here can benefit from our work.

This is of course just an initial announcement, but good things are about to happen.... that is when enough people share the same passion and need for speed.

p.s. I'll add the first ideas and experiments soon!

Yeah! this is what I'm looking for - I don't dual boot, don't have loads of disks or partitions, only use OSX so therefore don't need bells and whistles as part of the boot process (some great work recent though by Asere, rekursor, JRCs - if you need that kind of flexibility).

I like the idea of leaving the operating system partition completely vanilla, maybe booting from an SD card or usb? Have dabbled with replacing dsdt in bios which is hazardous (blanked one EPROM in the process), but that could be the best place to rectify device identification issues to clear the need for strings, additional dsdt, ssdt, and maybe some kexts if so then lots could be taken out of the post bios pre OS load process.

I'm not a coder or a dev but I'm ready to dabble with or test anything.

[-CEOS-]

great idea.
exactly what i was looking for...


i think we should start with disable fsck at every boot.
this takes up to 10 sec on my system  

[MacKonsti]

Master Chief, I guess part of speeding up the process is to kill or solve any errors presented on-screen? (verbose) Then I guess the "Firewire Power Conservation" error is one that I can report, here, that we have solved over another thread.
Also, I get another error that's marked as "bug" during launch process, think it's called launchctl.c error, but no mention in the kernel logs...

[bs0d]

use sleep (S3) instead of shutdown simples.

my boot is only 18 seconds anyhow when starting up from shutdown, what do people think is a slow boot time ?

[Master Chief]

bs0d, on Jan 24 2010, 07:12 PM, said:

use sleep (S3) instead of shutdown simples.

I am talking about the cold boot process.  Fixing that should also speed up resume after sleep.

bs0d, on Jan 24 2010, 07:12 PM, said:

my boot is only 18 seconds anyhow when starting up from shutdown, what do people think is a slow boot time ?

Defined how exactly?  When do you start counting?  See also my latest text edit/addition.

MacKonsti, on Jan 24 2010, 06:05 PM, said:

Master Chief, I guess part of speeding up the process is to kill or solve any errors presented on-screen? (verbose) Then I guess the "Firewire Power Conservation" error is one that I can report, here, that we have solved over

A quiet boot process is usually also a little faster, yes.  But I never had this FireWire error.  Not even before I started to fix my DSDT.  Lucky me.

MacKonsti, on Jan 24 2010, 06:05 PM, said:

Also, I get another error that's marked as "bug" during launch process, think it's called launchctl.c error, but no mention in the kernel logs...

Fixing errors should indeed be your first objective, but this is however not part of this exercise.

d.l., on Jan 24 2010, 05:48 PM, said:

i think we should start with disable fsck at every boot.
this takes up to 10 sec on my system  

Ten seconds?  So what is the size of your boot partition?  I only have 50GB set aside as boot partition, and don't have any issues with fsck.  I wonder why you do.

[MacKonsti]

Indeed, many times the "waiting for DSMOS" and "DSMOS has arrived" takes different amounts of time. I usually boot in 64bit mode with verbose -v setting, due to constant tampering with my DSDT. Sometimes the ethernet card gets an IP and info is displayed before having the "DSMOS has arrived" message appearing.

Also, I confirm that when the network card is out of the equation, the blue screen leading to the desktop comes faster, even in verbose boot, I can see that.

Initially, wanting to also speed up the process by eliminating the error "not loading AppleYukon.kext - not found and kextd not available in early boot" etc, I added my Marvell ethernet hardware code in the Info.plist of System/Library/Extensions/IONetworking.../Plugins/AppleYukon2.kext/ believing that injecting a kext (Chameleon) and proper system detection differ. So I booted a few times without a networking card; it was faster boot, I must say. Mind you, though, tampering with Info.plist of the original kext only removed the "funny" error during boot, didn't speed up the process in my opinion.

With "AppleIntelCPUPowerManagement: initialization complete" I don't see some delay there, to be honest (always in verbose boot)...

[Master Chief]

DB1, on Jan 24 2010, 05:35 PM, said:

Yeah! this is what I'm looking for - I don't dual boot, don't have loads of disks or partitions, only use OSX so therefore don't need bells and whistles as part of the boot process (some great work recent though by Asere, rekursor, JRCs - if you need that kind of flexibility).

I like the idea of leaving the operating system partition completely vanilla, maybe booting from an SD card or usb? Have dabbled with replacing dsdt in bios which is hazardous (blanked one EPROM in the process), but that could be the best place to rectify device identification issues to clear the need for strings, additional dsdt, ssdt, and maybe some kexts if so then lots could be taken out of the post bios pre OS load process.

I'm not a coder or a dev but I'm ready to dabble with or test anything.

The factory DSDT of my P5K PRO is 35,633 bytes plus the additional four SSDT's which of course makes it (an) even bigger (mess).  It would be nice if we could fix/change this, and I think we can.  Well eventually that is (looking at Google OS for inspiration).

p.s. What was the exact error you got when things went south (after the BIOS modification)?

[DB1]

Master Chief, on Jan 24 2010, 11:40 PM, said:

The factory DSDT of my P5K PRO is 32KB plus the additional four SSDT's which of course makes it (an) even bigger (mess).  It would be nice if we could fix this, and I think we can.  Well eventually that is (looking at Google OS).

p.s. What was the exact error you got when things went south (after the BIOS modification)?

LOL, no error as such other than human - I think I got the padding out of zeros wrong when filling up for the reduced dsdt in SingleLink.dat, there's no warnings if you get it wrong. Made the rom and flashed tried to reboot totally dead. You really don't want to have to solder on an eprom!

BlackCH succeeded first try and as far as I'm aware has had no issues, he maybe could become the bios rom maker for the project if thats where were heading? Where are you man, your usually hovering these type of threads?

[Master Chief]

DB1, on Jan 25 2010, 01:03 AM, said:

LOL, no error as such other than human - I think I got the padding out of zeros wrong when filling up for the reduced dsdt in SingleLink.dat, there's no warnings if you get it wrong. Made the rom and flashed tried to reboot totally dead. You really don't want to have to solder on an eprom!

I don't no.  Thanks for the warning.   I also ran into a BIOS problem last Sunday, but I was lucky to correct it with flashing the original BIOS back onto it.

DB1, on Jan 25 2010, 01:03 AM, said:

BlackCH succeeded first try and as far as I'm aware has had no issues, he maybe could become the bios rom maker for the project if thats where were heading? Where are you man, your usually hovering these type of threads?

And yes.  We have to modify our BIOS in order to change things big time... and thus having BlackCH here would indeed be a great help.

[DB1]

Ok, have done test one to see where i am current.

With Audio and Lan enabled 13.40, second boot 13.35. Without Audio and Lan 10.25, second boot 10.20.

I've been below this some time back (9.45) but it seems to have extended since install of Vmware fusion v3.1 - network & device searching?

Looking at system.log with Lan & Audio enabled I'm 25 seconds from first indication in system.log ( localhost com.apple.launchd[1]: *** launchd[1] has started up. ***)  of the OS loading process. (30 seconds on first cold boot - not been using for a couple of days).

[Master Chief]

DB1, on Jan 25 2010, 01:50 AM, said:

Ok, have done test one to see where i am current.

With Audio and Lan enabled 13.40, second boot 13.35. Without Audio and Lan 10.25, second boot 10.20.

I've been below this some time back (9.45) but it seems to have extended since install of Vmware fusion v3.1 - network & device searching?

Thanks for testing.  And yes VMWare is a slow dog.  I removed it because of this.

p.s. You can rename the VMWare directory with the kexts in it to see where you get without it.  I can't remember where the directory is, but you can use kextstat / locate to find it.

DB1, on Jan 25 2010, 01:50 AM, said:

Looking at system.log I'm 25 seconds from first indication in log of the OS loading process.

Nine seconds 25 seconds here.  With audio and LAN drivers loaded / functional that is.

p.s. My MacPro octo does it in 2 seconds.

Correction:  I thought that you were talking about kernel.log  Not system.log  Can't check my MacPro – currently not installed.

[blackosx]

System log times taken from *** launchd[1] has started up. ***
Kernel log times taken from npvhash=4095

1st boot with lan & audio
Revs:20.10
System Log: 28 seconds
Kernel Log: 15 seconds

2nd boot with lan & audio
Revs:20.00
System Log: 26 seconds
Kernel Log: 16 seconds

1st boot without lan & audio
Revs:11.00
System Log: 21 seconds
Kernel Log: 11 seconds

2nd boot without lan & audio
Revs:9.45
System Log: 19 seconds
Kernel Log: 9 seconds

In the System Log, there is an entry titled: bootlog[68]: BOOT_TIME: 1264407417 0
Would that be a useful indicator for testing?

[scrax]

Hi to all,
I'm using Revolution on a P5KC with P5KR bios to enable ICH9 AHCI, on my board I can disable Audio (A), Lan (L), Jmicron Pata/Sata (J) and Firewire (F). I've made 3 or more reboot for each test at 32bit and the results are (in spins under the apple logo):

N1: 9,5 - 10 - 9
A: 8 - 8,5 - 8
L: 11 - 9,5 - 10
J: 9 - 9 - 9,5
F: 8,5 - 9,5 - 10,5 - 9,5
All:9 - 9 - 9 - 9,5

For audio I'm using your AppleHDA.kext to gain some speed at boot.

Kernel Log with all enable

Jan 25 10:17:47 localhost kernel[0]: npvhash=4095
Jan 25 10:17:47 localhost kernel[0]: PAE enabled
Jan 25 10:17:47 localhost kernel[0]: 64 bit mode enabled
Jan 25 10:17:47 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
Jan 25 10:17:47 localhost kernel[0]: vm_page_bootstrap: 2007548 free pages and 89604 wired pages
Jan 25 10:17:47 localhost kernel[0]: standard timeslicing quantum is 10000 us
Jan 25 10:17:47 localhost kernel[0]: mig_table_max_displ = 73
Jan 25 10:17:47 localhost kernel[0]: AppleACPICPU: ProcessorId=1 LocalApicId=0 Enabled
Jan 25 10:17:47 localhost kernel[0]: AppleACPICPU: ProcessorId=2 LocalApicId=1 Enabled
Jan 25 10:17:47 localhost kernel[0]: AppleACPICPU: ProcessorId=3 LocalApicId=130 Disabled
Jan 25 10:17:47 localhost kernel[0]: AppleACPICPU: ProcessorId=4 LocalApicId=131 Disabled
Jan 25 10:17:47 localhost kernel[0]: calling mpo_policy_init for Quarantine
Jan 25 10:17:47 localhost kernel[0]: Security policy loaded: Quarantine policy (Quarantine)
Jan 25 10:17:47 localhost kernel[0]: calling mpo_policy_init for Sandbox
Jan 25 10:17:47 localhost kernel[0]: Security policy loaded: Seatbelt sandbox policy (Sandbox)
Jan 25 10:17:47 localhost kernel[0]: calling mpo_policy_init for TMSafetyNet
Jan 25 10:17:47 localhost kernel[0]: Security policy loaded: Safety net for Time Machine (TMSafetyNet)
Jan 25 10:17:47 localhost kernel[0]: Copyright © 1982, 1986, 1989, 1991, 1993
Jan 25 10:17:47 localhost kernel[0]: The Regents of the University of California. All rights reserved.
Jan 25 10:17:47 localhost kernel[0]: MAC Framework successfully initialized
Jan 25 10:17:47 localhost kernel[0]: using 16384 buffer headers and 4096 cluster IO buffer headers
Jan 25 10:17:47 localhost kernel[0]: IOAPIC: Version 0x20 Vectors 64:87
Jan 25 10:17:47 localhost kernel[0]: ACPI: System State [S0 S3 S4 S5] (S3)
Jan 25 10:17:47 localhost kernel[0]: RTC: Only single RAM bank (128 bytes)
Jan 25 10:17:47 localhost kernel[0]: mbinit: done (64 MB memory set for mbuf pool)
Jan 25 10:17:47 localhost kernel[0]: netkas presents fakesmc, a kext which emulates smc device
Jan 25 10:17:47 localhost kernel[0]: JMicronATA: JMB363 (CMD 0xd800, CTR 0xd480, IRQ 17, BM 0xd408)
Jan 25 10:17:47 localhost kernel[0]: From path: "uuid", 
Jan 25 10:17:47 localhost kernel[0]: Waiting for boot volume with UUID 5391094E-02AF-323A-9F76-D60EBEC3D3FF
Jan 25 10:17:47 localhost kernel[0]: Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResourceMatch</key><string ID="2">boot-uuid-media</string></dict>
Jan 25 10:17:47 localhost kernel[0]: com.apple.AppleFSCompressionTypeZlib load succeeded
Jan 25 10:17:47 localhost kernel[0]: AppleIntelCPUPowerManagementClient: ready
Jan 25 10:17:47 localhost kernel[0]: Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/SATA@1F,2/AppleAHCI/PRT1@1/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/Maxtor 6Y120M0 Media/IOGUIDPartitionScheme/Snow Leo@2
Jan 25 10:17:47 localhost kernel[0]: BSD root: disk1s2, major 14, minor 6
Jan 25 10:17:47 localhost kernel[0]: JMicronATA: JMB363 (CMD 0xdc00, CTR 0xd880, IRQ 17, BM 0xd400)
Jan 25 10:17:47 localhost kernel[0]: FireWire (OHCI) VendorID 1106 ID 3044 built-in now active, GUID 0011d800018fcabf; max speed s400.
Jan 25 10:17:47 localhost kernel[0]: USBMSC Identifier (non-unique): 000000016896 0x1111 0x370 0x31a
Jan 25 10:17:47 localhost kernel[0]: USBMSC Identifier (non-unique): 000AEB91BD075B8C050C00A1 0x951 0x1613 0x100
Jan 25 10:17:47 localhost kernel[0]: AppleIntelCPUPowerManagement: initialization complete
Jan 25 10:17:48 localhost kernel[0]: systemShutdown false
Jan 25 10:17:48 Mac-Pro-di-scrax kernel[0]: Previous Shutdown Cause: 0
Jan 25 10:17:49 Mac-Pro-di-scrax kernel[0]: NVDANV50HAL loaded and registered.
Jan 25 10:17:49 Mac-Pro-di-scrax kernel[0]: AttansicL1Ethernet(p5k) from markswell
Jan 25 10:17:49 Mac-Pro-di-scrax kernel[0]: DSMOS has arrived
Jan 25 10:17:50 Mac-Pro-di-scrax kernel[0]: [AttansicL1Ethernet] Error: Mac address through SPI is invalid
Jan 25 10:17:50 Mac-Pro-di-scrax kernel[0]: AttansicL1Ethernet: Ethernet address 00:1d:60:ea:cd:57

[MacKonsti]

Guys, I have added the following kexts/services in my mobo, that could slow down the process. Judging from the VMWare removal reported by Master Chief, please comment...

(1) lspci.kext (64-bit)
(2) little snitch service (appears in the boot log, too)

As I mentioned in my previous post (which nobody commented) is there a serious difference in detecting/loading method of the ethernet card between (a) injected plist kext via chameleon, and ( system native detection (by addind h/w ID in the plist of the driver)?

[BlackCH]

DB1, on Jan 25 2010, 01:03 AM, said:

BlackCH succeeded first try and as far as I'm aware has had no issues, he maybe could become the bios rom maker for the project if thats where were heading? Where are you man, your usually hovering these type of threads?

Hey guys! Sure I can help with whatever you need (if I know how to, of course).
About the BIOS mod, I didnt invent anything, I just followed method by kabyl/davis tsu. DB1 linked it some time ago HERE.
I didnt run into any problems doing it. I used the AZflash utility (resident in BIOS) to update the rom. It seems the safer way since it checks the rom integrity before flashing it....
The booting was faster (I dont remember how much; I would say 10 spin less) but I had to fold back to the unmlodifyed BIOS to be able to boot windows xp (I need it time to time)....
Another thread about BIOS mod to check is THIS (to modify bootscreens, DMI data, etc)

[MacKonsti]

BlackCH, on Jan 25 2010, 12:49 PM, said:

Hey guys! Sure I can help with whatever you need (if I know how to, of course).
About the BIOS mod, I didnt invent anything, I just followed method by kabyl/davis tsu. DB1 linked it some time ago HERE.
I didnt run into any problems doing it. I used the AZflash utility (resident in BIOS) to update the rom. It seems the safer way since it checks the rom integrity before flashing it....
The booting was faster (I dont remember how much; I would say 10 spin less) but I had to fold back to the unmlodifyed BIOS to be able to boot windows xp (I need it time to time)....
Another thread about BIOS mod to check is THIS (to modify bootscreens, DMI data, etc)

Guys, I think you must differentiate the speeding of boot process that you're after, in this thread. Or clarify!
Are we talking a boot time/process past the selection of the boot-drive in Chameleon, or before, including BIOS settins/patching etc? (as per BlackCH's mention) Are you even using Chameleon at all? I have no idea about the newly-mentioned project "Revolution" and I don't want to keep posting my findings/thoughts here like a newbie, and be ignored at the same time
Cheers to all.

[scrax]

MacKonsti, on Jan 25 2010, 11:59 AM, said:

Guys, I think you must differentiate the speeding of boot process that you're after, in this thread. Or clarify!
Are we talking a boot time/process past the selection of the boot-drive in Chameleon, or before, including BIOS settins/patching etc? (as per BlackCH's mention) Are you even using Chameleon at all? I have no idea about the newly-mentioned project "Revolution" and I don't want to keep posting my findings/thoughts here like a newbie, and be ignored at the same time
Cheers to all.

We are talking about the spins under the apple logo.
If you change the original dsdt in BIOS with the modded one you use you don't have to load it from the HD and so boot time is faster (after the BIOS POST), this is what BlackCH did.

[BlackCH]

Indeed, my BIOS mod only gets rid of the need to load a DSDT.aml from disk.
BTW, Im using chameleon for booting.

[DB1]

BlackCH, on Jan 25 2010, 11:59 AM, said:

Indeed, my BIOS mod only gets rid of the need to load a DSDT.aml from disk.
BTW, Im using chameleon for booting.

@BlackCH - would you be so kind to make the P5K VM - bios rom with the attached dsdt.dsl so I can measure the difference between loading an updated dsdt from bios as opposed to via chameleon.

I'm currently using rekursor-r32 Chameleon to boot.

 P5K_VM_ASUS_1001.ROM.zip   640.44K   13 downloads
 v3.4_dsdt.dsl.zip   3.02K   53 downloads