How to boost the OS X boot process...

[blackosx]

The only thing I can come up with that can hurt boot for you, and scrax, must be this change:

	if (shouldLoadMKext) // We'll skip this in safe mode.
{
	[color="#FF0000"]fileLoadDrivers("/Extra/Extensions", 0);
	matchLibraries();
	loadMatchedModules();[/color]

	if (loadMultiKext("/System/Library/Caches/com.apple.kext.caches/Startup/") == STATE_SUCCESS)
	{
		gKextLoadStatus |= 1;
	}

	[color="#FF0000"]/* if (loadMultiKext("/Extra/") == STATE_SUCCESS)
	{ */[/color]
		gKextLoadStatus |= 2;
	[color="#FF0000"]// }[/color]
}

Undoing this change should get you back up and running (but in normal/verbose mode only). It is however only a test. It will tell me if what I'm thinking is right. Will explain later.

 

Note: Remember to change the function names when you use files from a previous version!

I've looked at attempting your suggested change but I'm confused

 

I read your instructions as to remove/comment out the lines in red - would that be correct? I ask because I don't see those lines in my code here. In 636_3 I have:

if (shouldLoadMKext) // Skipped in "Safe Boot" mode.
{
	if (loadMultiKext("/System/Library/Caches/com.apple.kext.caches/Startup/") == STATE_SUCCESS)
	{
		gKextLoadStatus |= 1;

		_DRIVERS_DEBUG_DUMP("loadMultiKext(1) OK.\n");
	}

	if (loadMultiKext("/Extra/") == STATE_SUCCESS)
	{
		gKextLoadStatus |= 2;

		_DRIVERS_DEBUG_DUMP("loadMultiKext(2) OK.\n");
	}
}

 

and in 636_2b I have:

if (shouldLoadMKext) // We'll skip this in safe mode.
{
	if (LoadDriverMKext("/System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext") == STATE_SUCCESS)
	{
		gKextLoadStatus |= 1;
	}

	if (LoadDriverMKext("/Extra/Extensions.mkext") == STATE_SUCCESS)
	{
		gKextLoadStatus |= 2;
	}
}

 

Also, nowhere do I have those three lines (shown in red above) together.

I'm sure there's a quick and easy answer to this but I'm stuck. So can you please point the error of my ways?

[DB1]

Just popping in to say I got 636_2a/b working and have not had time this past weekend to keep up so will be catching up this evening. I had a graphics problem that caused me to get held back and I still need to sort it out as currently im 800x600 no kext loaded. Oh and I tried 636_3 this morning about 5 mins before shooting of to work but it grey screen apple no thobber, did'nt have any debug set so that's next on my try list with the fix above after I sort my graphics.

 

Catch up later with you guys & gals.

[blackosx]

Or even better... jump to post #507

I like the jump option. Good thinking and thanks.

 

And... when you can boot with the directive in default setting (0) than you simply have a (missing) driver issue to sort out.

And when I can't boot with the directive set to either 0 or 1?

Still no go for me with 636_2c resulting in the same error as I showed in post #484.

 

The last version I can boot with is my 2b then with 2a added plus the additions in post #457 which gave me these files which I can compile and boot from.

Revolution_636_2b_and_a.zip

[humph]

Looking at drivers.c will reveal that I am actually working on improving this. Just search for isLoadableInSafeBoot but finding the right balance between keeping things fully functional and breaking it is difficult and time consuming.

Yes, saw that. Not at all sure that I understand it, but looks exciting!

 

Just a quickish reply, as out'n'about this evening. (Means may not be worded as well as I'd like!).

 

I found interesting things happening earlier.

If I used OSBundleRequired of "Safe Boot", then as expected, not loaded in normal boot. But if I used "Revolution" (or anything, including Root etc) then loaded. By that I mean, eg: my audio kext is loaded in preference to the main HDA from /S/L/E. So, not sure if this is due to the way the bootoader works, or due to kextd. But I thought was more likely to be bootloader as when loading an mkext (built to include all from /E/E w/o bothering with any flags like -l) stuff works irrespective of Bundle.

 

(Note: in any case, I probably should investigate stuff like probe scores, to see if that can resolve the situation).

 

So, from my perspective, IF we are going to be using an Extra/Extensions folder, then this is going to contain stuff which is not in /S/L/E. And it needs to load. But ideally not be forced to use "Root" for things that ought not to be loaded if doing a "Safe Boot" but are needed normally; and of course vice-versa E/E/ may contain things that are needed for a Safe Boot on a hack as well as normally - so Root is OK for that. Also kextd or kernel does not know about /E/E and can't go grab them. In reality Safe Boot is the only situation where any of this matters, as normally will use mkext or prelinked kernel that can be built "as required". So might be a non-issue really....

Of course, the goal of this project is to reduce boot time. Perhaps use of /E/E is anyway not really aligned with that so inclusion of /E/E loading is more "for test & development" than day to day.

 

Personally, I could anyway live with the nasty hack of inventing "new" OSBR strings for my situation, as this seems - so far - to work. But thought I'd mention the above, see how it aligns (or not) with what you are thinking!

[blackosx]

Then you drop files from the copy that works into the folder of Revolution 636-3 and see if you can boot with it. Start by doing it with these:

 

1.) i386/libsaio/sys.c

2.) i386/libsaio/acpi_patcher.h

3.) i386/libsaio/acpi/patcher.c

Good morning DHP. Thanks for the continued advice here. This morning I tried your suggestion and by replacing each of the above files I can boot So I guess the next step is to try to narrow down a bit further?

 

I'll report back...

 

Update: Narrowed it down to acpi_patcher.c

 

And there's not much changed between the one in 636_3 and my previous version so it shouldn't be too hard to identify what the problem is now.. But I have to go to work now.. I'll continue this tonight.

[blackosx]

I found the problem this morning already, but was unable to reply since my Vodafone Mobile Internet – which I am using in the train – didn't work anymore. No idea what is going on there. Anyway. The solution is in the file ..

Good spot and such a simple fix. Well done.

As for the mobile internet, great when it works otherwise a right PITA.

[Dr. Hurt]

Sorry to interrupt your work guys, but what is revolution? How does it differ from Chameleon?

I've been very busy at school, so I couldn't follow osx86. Thanks in advance )

[humph]

Good Evening All

 

Glad to hear you are recovering well, DHP.

And good to see blackosx should be up running now also. But I guess perhaps not scrax as -x issue still present?

 

Kext Loading:

So, I think I've got my head around the pending kext load code. Am I right to be thinking it's gonna work like:

- You get to specify what kexts *you* want to load, in the list.

- For normal boot, the list is checked by Revolution to exclude any that are tagged Safe Boot

- For normal boot, we'd load up all in the list other than Safe Boot. Which would then include ones with no OSBR flag. ??

- For Safe Boot, we only load those that are Root, Console, Local Root or Network. And Safe Boot. ??

 

If so, nice

 

Performance

Decided to load Revolution to HD as main bootloader for now, and do some speed tests SD card vs HD load vs RC5; as I failed when trying to get a prelinked kernel working*

 

Here's some rough data comparing boot times - recalling that this is on a dog slow atom netbook…

AJA Disk Whack Tests: Disk read SD card 11MB/s vs Disk read HD 55MB/s.

Using static data for SMBIOS and CPU.

 

Timed from hitting "Enter" to select the boot device in BIOS, to Spinner then to log-in screen. Of course, the longest part is due to slow atom and probably have too much gunk loading that I need to selectively clean out (voodoo monitor, VBox etc).

 

SD card: 14s - 74s approx

HD: 10s - 72s approx

RC5 (HD): 11s - 72s approx

(Total about 60s when plugged in to AC)

 

Then I realized that the rest of my results were not comparable, as had plugged into mains, which sped things up saving 10s or so in total.

One thing that did speed up time to spinner & log in was to move HDA over to /S/L/E, saved 2-3s. But whether that helps in terms of time to usable desktop, not tested yet.

One thing jumps out from the log, that is a wait of around 10s between waiting for DMOS and arrived. On earlier posts, I see that others had eliminated that. So not sure if due to slow atom, or my config.

 

But - its so nice to see, almost immediately, the logo screen.

 

*PreLinked Kernel Issue

Probably am doing prelinked kernel wrong, using wrong name, wrong build approach or something. Got Waiting for root device error due to Apple File System driver bad UUID, or smthg like that. Sorry, can't remember exact words.

[blackosx]

@DHP - Just tested the change to acpi_pacther.c and can confirm it works.

 

Sorry to interrupt your work guys, but what is revolution? How does it differ from Chameleon?

Hi Dr. Hurt - It's been a while...

I'd better let dutchhockeypro explain as you're guaranteed a better explanation that way. But the first post in this topic by MC might go a little way to explain.

 

And good to see blackosx should be up running now also. But I guess perhaps not scrax as -x issue still present?

Thanks humph. I'm back up and running now.

Hopefully soon too for scrax and DB1.

[blackosx]

Just had a go at booting with the prelinked kernel option and the debug output shows it was found and loading. However, the kernel goes though it's verbose messages as I normally see and gets right near the end of booting where it fails with 'failed to locate SMC driver' which I guess tells me I need to add fakesmc.kext somewhere?

 

Here's the debug screenshot(s):

 

and stall message:

 

So can I just ask what exactly I need to be doing here? and maybe this ties in with the kext conversation with humph earlier? I understand the prelinked kernel is a cache which contains the kernel and extensions from my running system, so if I am loading that from Revolution then why does my boot fail due to missing SMC driver?

 

I'll catch up with this tomorrow. Bye

[humph]

-char rootUUID[36];
+char rootUUID[37];

That should sort it. Works for me.

Thank you.

Yes, works here also.

But have same smc issue as blackosx. Too late tonight to reconfigure/resolve all that & rebuild kernel as need sleep!! (You dont wan to know how many edits it took to fix my typo's for this quick post!). But tomorrow is another day!

[blackosx]

Hi DHP

Thanks for the details..

 

This morning I setup a second HDD in my machine with Revolution to boot from. It boots fine and is obviously much faster than USB, though I will need to uncheck some of the debug directives and not boot in verbose mode to get an overall sense of the speed.

 

The pre-linked kernel image is created by /usr/sbin/kextcache and that will only check kexts loaded from /S*/L*/E* and thus you will have to move fakesmc.kext et all from /E/E/ or it won't even be included.

Tonight I'll look at moving my essential kexts, currently in /E/E, to /S*/L*/E* for creating a prelinked kernel to try booting from.

 

So when using the pre-linked kernel, is /S*/L*/Caches/com.apple.kext.caches/Startup/Extensions.mkext still used?

[blackosx]

Please do not concentrate too much on speed rather than getting a more streamlined boot process – it won't turn your Flymo into an F16 – with the option to recover when things go bust. More about this at a later stage.

Lol.. no problem.. I guess it's just that this topic is entitled 'How to boot the OSX process..' and sometimes curiosity just gets the better of me.

 

What I did for my USB-stick was to specify source directories, including /E/E/ and we can do this because the kernel won't touch it. That's not the case for your regular boot partition, but just to let you gentlemen know that there is an option to this. See man kextcache (still at school).

So do you recommend still booting from USB for now? and I'll find some time to do some reading.

 

Now back to playing with my new girly white iPhone

Lol.. that's why I went for the black one. Enjoy

[scrax]

hi all,

I went sick too in the last days, but today i'm felling a little better.

 

I've tried to boot using the last acpi_patcher.c but I have still the same hang when the kernel loads.

 

I'll try the FileMerge way to see if I can find out something

[DB1]

Good evening DB1,

 

This is much more fun than watching TV. Attached is a specially crafted version of Revolution 636-3 with the drivers.c patch reverted. This way it is much easier for you gentlemen to do your testing.

 

Note: Simply toggle the switch #define REVOLUTION_636_3 0 to 1 and off you go with Revolution 636-3 (new code also included / the easiest way I could think of)

 

And... when you can boot with the directive in default setting (0) than you simply have a (missing) driver issue to sort out. Darnit. Mom is yelling that I must quit. Great. back later, when she sleeps hihi

 

Hi DHP and everyone else.

 

Thanks for this it made catch up easier, now can boot 636a/b/c&_3. drivers.c 1 or 0 works for me. Still having issues with my graphics which is a real pain 800x600 on a 10" screen is a real bind. Chameleon has drivers for the GMA950 and then all i do is fix the id with some patched kext's but it wont work in Revolution. I'll revisit earlier posts as I recall you having discussion with blackosx re putting the data in Private h. I guess this is an EFI string converted to hex then to little endian. Any pointers are helpful.

 

Gettig dinner now and will be back later.

[humph]

... Still having issues with my graphics which is a real pain 800x600 on a 10" screen is a real bind. Chameleon has drivers for the GMA950 and then all i do is fix the id with some patched kext's but it wont work in Revolution. I'll revisit earlier posts as I recall you having discussion with blackosx re putting the data in Private h. I guess this is an EFI string converted to hex then to little endian. Any pointers are helpful.

Hi DB1. I migrated the display enabling stuff to DSDT, so I could use bootloaders w/o the GMA laptop patch.

I'll send a PM with the code I use, so save cluttering up this thread.

 

@DHP (well everyone who's interested )

Onto my progress - or perhaps lack of - today. Been messing around with prelinked kernel.

 

a. Well it certainly "improves" the boot up process in terms of what gets loaded when in the log. More like MBP now.

 

b. At times, has considerably improved the wait for DMOS - although not sure whether total boot time changed

 

c. What I was hoping for, but seems not possible, is to boot (standard kernel+E/mkext) then build a linked one that includes stuff from /E/E as well as those kexts loaded from /S/L/E, so as to incorporate my "over-ride" kexts (GMA, audio etc from /E/E) without having to rm the "duplicated" kexts from /S/L/E and replace in S/L/E with the ones from /E/E.

- Had hoped that use of "-r" flag would mean it ignores stuff in /S/L/E that didn't load at boot since was using similar kext from /E/E and include those /E/E ones. Does not seem to work that way. So far.

- Additionally, does not seem to want to include the GMA video one in /E/E. But MIGHT be as SafeBoot on the accelerator, GAM950...see*

- However, it does seem to work for non-duplicated kexts (eg: fakesmc, AnyCardReader etc, but still using OSBR Root there).

 

Of course, no problems if I first put everything into /S/L/E, replacing hack kexts as needed. But trying to avoid that, as more hassle when upgrading OS.

 

* You mentioned a way to see what's in the prelink. What is that. Not mkextunpack AFAIK?

 

Am using this command for prelink build, having cd'd to the / on boot volume:

(sudo) kextcache -c mach_kernel -K mach_kernel_atom -a i386 Extra/Extensions -r

[blackosx]

And here I am. now going to finish the rewrite of functions loadKexts (done) and loadPlist in drivers.c

Great.. I'm Looking forward to the next installment of changes

 

Also, I know we shouldn't be concentrating on speed here.. lol... but I finished making my prelinked kernel (albeit with the complete set of kexts in S*/L*/E* combined with my kexts from E/E) and turned off all the debug / verbose settings. Booting from HDD using static SMBIOS settings I can now get from HDD selection in BIOS to desktop in 29 seconds. A lot better than the 53 seconds I posted previously though that was booting a different OSX installation with VMware installed.

 

Note to DHP (so as not to shoot me down for the speed tests ): I've posted the above just for reference for me for future comparison tests.

[blackosx]

Well. I just finished the rewrite of the two functions, and I am happily surprised by the result of it e.g. smaller, quicker (be it marginal) and a lot more fun to read.

Well done.. I'll keep my eye out for the next update.

 

LOL I won't. Only trying to protect myself against people who may expect too much and get disappointed i.e. I think that it is better to lower the expectations, and hope for a nice surprise. Much better than the other way round.

Fair point. This is just fun for me and I'm not expecting my flymo to turn in to an F16! he he

 

Time for me to go to bed. See you in the morning. Good night!

Goodnight.. Me too

[humph]

I ran kextstat and used the output to copy the loaded kexts to a dummy directory where I added fakesmc et all from /E/E/ and used this directory to create the pre-linked kernel ..

Great idea!

Battling to boot here as must have left out something important, so that'll keep me busy/quiet for a while. Or a very long while. EDIT. missing AppleFileSystem. Pretty critical that. LOL.

 

Anyway, good night and am also looking forward to the new stuff.

[blackosx]

Thanks for the update DHP.

I won't have much time to play this evening but hopefully I'll get some. I'll report back after I've tested.

 

Sounds like your brother want's one of these? he he

[humph]

Hi all & good evening.

 

DHP - Yep, it's fixed now, and working fine. Don't see much difference though vs use of mkext and std kernel. Perhaps a couple of seconds and a slightly different loading order of a few kexts. I probably need to do more reading about why and where use of prelinked kernel is advantageous, other than for a small USB recovery stick!

 

Thank you for the v4 upload. Might be me, or perhaps some other file changed & "missing" since get following compile error:

drivers.c: In function ‘initDriverSupport’:

drivers.c:165: error: ‘PlatformInfo_t’ has no member named ‘KextFileName’

drivers.c:166: error: ‘PlatformInfo_t’ has no member named ‘KextPlistSpec’

drivers.c:167: error: ‘PlatformInfo_t’ has no member named ‘KextFileSpec’

drivers.c:169: error: ‘PlatformInfo_t’ has no member named ‘KextFileName’

drivers.c:169: error: ‘PlatformInfo_t’ has no member named ‘KextPlistSpec’

drivers.c:169: error: ‘PlatformInfo_t’ has no member named ‘KextFileSpec’

drivers.c: In function ‘loadKexts’:

drivers.c:359: error: ‘PlatformInfo_t’ has no member named ‘KextFileName’

drivers.c:362: error: ‘PlatformInfo_t’ has no member named ‘KextFile’

drivers.c:362: error: ‘Name’ undeclared (first use in this function)

etc etc etc

[blackosx]

636_4 builds and complies fine with the change in post #534 and revised platfom.h. I have successfully booted from USB normally and my HDD using pre-linked kernel.

 

So are the changes mostly code cleanup and restructure, or should I notice anything different?.

[humph]

Funny. Just got a phone call about it. Gotta run now. Later.

Cheers. Found I also needed to:

Add in platform.h, _PlatformInfo_t

 

char *				KextFile;			// Initialized and used in drivers.c

And remove an = sign in drivers.c

 

[code]isBundleType2 = (GetFileInfo(gPlatform.KextFileName, "Contents", &dirEntryFlags, &dirEntryTime) == 0); //not =Name

[/code]

 

Well, now compiled, so off to check it out!

[dgsga]

Just to confirm that all's hunky dory with 636-4. Sorry I've not visited much as I've been busy experimenting with getting revolution in-bios as a PCI option ROM but no joy so far I shall persevere, but it's a bit like the blind leading the blind when it comes to me and assembler code...

[DB1]

All cool here with 636_4 here to.

 

Strangely some kexts that would not load previous are now. humph thanks for the dsdt code but in the previous version my GMA950 and Framebuffers would not load so was not getting 915Resolution. This version Revolution has fixed that and also my VoodooHDA which was not loading is now. Just got to sort out why webcam not working and I'm back up to fully functioning as with Chameleon.

 

Keep it up DHP, and thanks.