How to boost the OS X boot process...

[DB1]

Sounds like fakeSMC.kext or another required kext is missing. It may be looking for a kext in:

/System/Library/Extensions/ that it cannot locate (think dependencies).

 

Configuration of SDbooter is same as with 635 and kextstat shows fakeSMC loading and boots (not with standing some other minor issues). If I swap just the boot file and dont kextcashe it should load same - should it not? Therefore it must be something to do with the changes in 636a/b.

 

The same configuration of SDbooter but with c.a.B.p & dsdt & mkext in SDbooter/Extra and my Chameleon boot file works fine and it's the same setup on the EFI partition so I dont think it's a dependancies issue.

 

3.1 - Screen Resolution. Made changes to default in wherever it was..to 1280x800x32.

Now the verbose text (Darwin stuff, not the booter debug) is "nice". But on non-verbose, the apple logo is off to right. With the default resolution, verbose was nasty, but apple logo in right place.

 

humph Change to this in boot2/boot.h for my 10" screen this sorted it for me.

#define DEFAULT_SCREEN_WIDTH 800

#define DEFAULT_SCREEN_HEIGHT 600

[dgsga]

3.1 - Screen Resolution. Made changes to default in wherever it was..to 1280x800x32.

Now the verbose text (Darwin stuff, not the booter debug) is "nice". But on non-verbose, the apple logo is off to right. With the default resolution, verbose was nasty, but apple logo in right place.

Spinner OK in both cases. Strange, as code seems simple enough (X/2 etc). Then again, there's probably other stuff going on somewhere that's not obvious to a non-coder!

 

I had this exact same bug, if you've a desktop PC it's caused by your graphics card not supporting the vesa mode 1280x800x32. You have to dump your video card ROM using the appropriate flasher onto a DOS formatted USB stick. Mod it using a hex editor using these instructions:

 

http://www.insanelymac.com/forum/index.php...211294&st=0

 

Then reflash your video card with new ROM. It worked a treat on my Radeon 5770, I previously couldn't get 1920x1200x32. If it's a laptop then DB1's advice sounds good to me. Now all's well...

[humph]

For SystemID, I'm currently using the value that Chameleon shows in it's log when booting (or quickly find it by running bdmesg after booting). It will be on the line: Customizing SystemID with : 00000000-0000-0000-0000-000000000000.

I add this value in to private_data.h

BlackOSX, thanks for the info. Well I guess I am doing stuff wrong. (This whole UUID always confused me, was so glad when Chameleon implemented random UUID, but still don't "get it"!). Here's my situation:

 

RC5:

SysProf:

Hardware UUID: 354E9A15-29D2-5480-AA1B-BE13DBF11C06

 

bdmesg:

Customizing SystemID with : 4d9900e0-3f63-11df-995d-cfa4b57c1eb1

(Yeah! Found a version of bdmesg from Slice that works 32 bit!!!)

 

REVO:

SysProf:

Hardware UUID: 0D3E1AF9-66EB-53B8-939F-63827791695B

 

bdmesg:

(no log of course)

 

private_data.h:

#define PUT_YOUR_SYSTEM_ID_HERE { '4','d','9','9','0','0','e','0', '3','f','6','3', '1','1','d','f', '9','9','5','d', 'c','f','a','4','b','5','7','c','1','e','b','1' }

Perhaps this is totally the wrong format..but got compile errors the other ways I tried.

 

 

For DB1, DHP.

Just read the latest posts. Interesting. Gotta dash now, but will get back to it later tonight..

[DB1]

I attached diff_635_636_1.txt in post #435 and in post #452 you said Yeeeeeeeeha (with a patched kernel) so that went fine. Later I attached Revolution_636_2a.zip in post #455 and Revolution_636_2b.zip in post #457 so when did it stop working for you? Remember. You can always go back one or more steps.

Found the problem, you mentioning dependancies and then drivers.c made me backtrack post #457 changes showing removal of this:

 

	
	FileLoadDrivers("/Extra/Extensions", 0); // db1 added back in
	MatchLibraries();						// ditto
	LoadMatchedModules();					// ditto

 

Putting it back gets me booting again.

[DB1]

Great. So what do you have in /Extra/Extensions? Apparently something that isn't loading, or is not included in /Extra/Extensions.mkext

 

p.s. You can have a look with mkextunpack to unpack the multi-kext package.

 

Going to get the HP now. Back later.

After putting that section back in I Checked the previous built kextcached mkext and it showed that the kexts in E/E were not included. I rebuilt and tried to boot but it went grey screen and hung. Seems there is one or several causing me a problem so I'm going to strip to minimum then work up one by one to find out whats going on.

 

I'm done for today though.

[humph]

humph Change to this in boot2/boot.h for my 10" screen this sorted it for me.

#define DEFAULT_SCREEN_WIDTH 800

#define DEFAULT_SCREEN_HEIGHT 600

And also ref info from dgsa..

Well, my VESA supports 1280x800x32, plus lower resolutions. So ought to work (does with Chameleon).

Not a huge problem as only cosmetic, but would be nice if both verbose worked at native resolution as well as having non-verbose working with "correct" graphics!

 

It is hard to imagine what is going on, but you could help me by supplying the data from:

IOREG : AppleACPIPlatformExpert -> ACPI Tables -> FACP

 

Hopefully a cosmetic only issue. The output of cpu/dynamic_data.h is ok?

In reverse order:

Sure, CPU debug output shows Atom @ 1.6GHz OK. MSR tools shows speed step up to 1.6GHz.

 

FACP for Revo, RC5 and Linux raw attached!

FACP_Listings.zip

Note: I saw something from Slice about how you can't (in Chameleon) do FADT restart fix on ACPI 1.0 tables; Chameleon uprevs the data from ACPI v1.0 to v4 (or v2?). Not sure what Revo is doing, but perhaps that is something to consider?

 

w.r.t. the kext load "issue", so I looked at the source for the checks in lines 261 thru 283 of drivers.c and the tests against gKextLoadStatus. But kind of seems strange (or really clever!! - guess I don't really understand the operators used in C).

[scrax]

I have made some quick tests and the last code is booting again but only if I use -x and with the boot volume loaded wrong as before.

It didn't load the dsdt but I need to check better the options if all is set ok.

[humph]

Thanks hump for the FACP dumps. Still cut off in Revolution. Looking into it... but breakfast first now.

 

Trust you had a hearty breakfast!

 

Thanks for clarification on the ACPI 1.0 thing. Am setting that flag.

 

printf("factoryFADT->Length = %d\n", factoryFADT->Length); 116

printf("tableLength = %d\n", tableLength); 116

printf("patchedFADT->Length = %d\n", patchedFADT->Length); 116

printf("sizeof(*patchedFADT) = %d\n", sizeof(*patchedFADT)); 244

[blackosx]

It's been a busy weekend for me but I'm back from last nights party and feeling fresh again after eating a fantastic carvery dinner today to help me sober up

 

How's the iPhone4 DHP? - that's a nice gift to receive.

Nice avatar humph

 

I've seen the continued work here and can report I've applied the changes of rev636_2a, 2b and the code changes shown in post #457 which now allows me to boot successfully with /Extra/Extensions.mkext.

[blackosx]

BlackOSX, thanks for the info. Well I guess I am doing stuff wrong. (This whole UUID always confused me, was so glad when Chameleon implemented random UUID, but still don't "get it"!). Here's my situation:

....

Looks like you've done as I did, but the difference is I get the same Hardware UUID reported in system profiler when booting from either Chameleon or Revolution.

 

I'm just doing some reading to double check something...

[blackosx]

And here it is. Yah Or not (forgot to click on UPLOAD).

So what's this for DHP? Sorry if I've missed a bit..

 

Also I get compilation error:

/usr/bin/ld_classic: Undefined symbols:
_DecodeKernel
_LoadDrivers
collect2: ld returned 1 exit status
make[2]: *** [boot] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

 

LOL At least someone here was having fun then

...

And I love FaceTime.

Yeah.. it was great to catch up with some old friends

I haven't really made much use of Facetime, other than to one person.

[blackosx]

Yikes. I renamed tons of functions. Will attach Revolution-636-3 shortly.

I see.. I'll be patient.. Lol

[blackosx]

I'm failing to boot with the AppleACPIPlatformExpert::start failed message from the kernel. So I think I'm missing setting one of the directives in the source code but I can't remember which one. Can you help to remind me?

 

 

But on a positive, here's the debug feedback when running the boot process with /Extra/Extensions.mkext

and again with /Extra/Extensions/*.kext.

[humph]

Well you've done some magic for 636-3, DHP.

Here, now seems kext loading is working, and also restart!

So I did not try alternate settings 0/1 (machine is ACPI 1.0 anyway). And I think that other thing you suggested to add (length 244) was already in the code??

 

Anyway, FACP is different (still) to RC5, bur does seem to work. And is now the right length. For completeness, enclosing all versions; although you may not want or need to examine, as it does seem to work.

FACP_Listings.zip

 

Strangely on booting w/o an /E/E mkext in /E; it takes a couple of minutes for DMOS to arrive. Also audio fails (failed to find IOHDAFamily, even with all audio Plugins set as Root bundle required). Although with a full mkext, no issues. DMOS in around 15s, and audio all good. (I use a full older version AppleHDA in /E/E plus dependencies, not a legacy injector. So I can be as upgrade-proof as possible).

 

My dinner time now..

[scrax]

Here ya go.

 

I can't boot anymore.

I see that it find's and loads system mkext and nothing in extra (because I have all the needed kexts in S/L/E)

But after kernel starts it hangs without panic...

 

I'll make and attach some picture right now.

Here the debug info:

and the kernel output:

 

tried with and without:

<key>TargetOSVersion</key>

<string>10.6.6</string>

[humph]

Thank you. Yeah. I finally got it sorted. Took a while but still. I'm pleased with it. Very much even.

It's awesome. I even get 1.6 (well. 1.59GHz) in sysprof. Very very good stuff.

 

 

I better be different. I mean you are using a custom DSDT. And with both runs? With Revolution and Chameleon? Correct?

Sure, but same one on RC5 and Revo.

 

Let me start by asking a question: Do you have /System/Library/Extensions/*.kext to fulfill all possible dependencies? If not. Start fixing it.

Ah, my mistake, had a mixed up ir/ri in "Required" in the .plist.

But, seems to have also resolved the time to get DMOS. Perhaps coincidence (although I tested a few times before to be sure), perhaps delayed as processor off unsuccessfully chasing stuff in the main /S/L/E HDAaudio.

 

I hope it was nice. I think I'm getting sick too

Hope it's not Noravirus. That's nasty...I know as had it last year. But over in a day or two usually.

 

@scrax - so it won't boot even with multiple hard resets? I had a few "hangs" in earlier version before FACP stuff resolved (if I tried a reboot, and had to hard-off to recover), so wonder if it's somehow related to recent fixes that worked here but might have broke stuff for your config. Just a wild guess though.

[blackosx]

Have you checked the directives in: acpi_patcher.c, cpu.c and smbios_patcher.c?

Yep. Checked and compared settings against my previous build of Revolution and I can't boot with 636_3. Could it be something to do with the changes in drivers.c?

 

I'll have another look at it in the morning. I'm signing off for the night.

 

I think I'm getting sick too

I hope it passes quickly.

[scrax]

You mean you also lost the ability to boot with -x (or pressing the x key)?

 

Yes 2b worked only with -x

636_3 dan't works anymore even with -x

[blackosx]

Same for me.. I could boot with all changes preceding 636_3.

Booting with -X still fails. Here's a screenshot:

[humph]

Tried booting with -x (press x key or flag) and get the same panic as scrax and blackosx.

Debug output saying should not load caches, but it does appear not load any kexts from /S/L/E, based on the time that it should take versus how fast it proceeds to launch kernel.

 

But:

Verbose works if I do a normal verbose boot with -v in kernel flags, or if no flag but pressing v on startup.

 

Single User mode works when pressing s.

 

Or normal works also.

 

"f" or "F" ignore cache? - anyway could not seem to get either to ignore caches. EDIT: Aha, I see that this function is not included in code.

[blackosx]

p.s. You boot with dynamic CPU/SMBIOS detection?

Good morning dutchhockeypro.

I've been using dynamic CPU detection and static SMBIOS injection.

 

I have narrowed down our safe boot problem to the following files:

Well done with hunting the troublesome code. I hope it proves fruitful.

 

Used diff -rq Revolution-636-2b Revolution-636 to get the files that have changed.

I used /Developer/Applications/Utilities/FileMerge to view the changes between 636_2b and 636_3, although it didn't help me understand why I couldn't boot . The app is great for viewing changes between files and folders visually as you can drop the whole folders for comparison. Cartri introduced me to the app a while back and I love it.

 

What I will do now is to compile a new version of Revolution (636-4) with all but the last three files in it. This should work, after I fixed some of the function names that have changed since – function names should start wiith a lowercase character. Let's see...

I'll be able to test it when I get home this evening.

[humph]

I used /Developer/Applications/Utilities/FileMerge to view the changes...

Hi blackosx. Thank you for that tip. It's very cool - way better than TextWrangler Compare docs, which is what I've used up to now. So much good stuff in OSX "hidden away".

 

DHP: Agree on the -f/F thing (wasn't really asking for it!). As I understand, if mkexts are missing - or, perhaps more relevant, are corrupted - then current functionality is to move onto /E/E and /S/L/E.

[humph]

Hi DHP,

 

In boot.h:

/* TODO; Fix me!!!
extern void drawColorRectangle( unsigned short x, unsigned short y, unsigned short width, unsigned short height, unsigned char  colorIndex );
extern void drawDataRectangle( unsigned short  x, unsigned short  y, unsigned short  width, unsigned short  height, unsigned char * data );
extern int convertImage( unsigned short width, unsigned short height, const unsigned char *imageData, unsigned char **newImageData );
extern char * decodeRLE( const void * rleData, int rleBlocks, int outBytes );
extern void drawBootGraphics(void); */

// extern void loadImageScale(void *input, int iw, int ih, int ip, void *output, int ow, int oh, int op, int or);

 

Not sure if that was related to my earlier comment about apple logo position. Perhaps not. But did some more checking, and hmmm...

- Added some debug printfs in Chameleon RC5 graphics.c getVESAMode to re-confirm it sees 1280x800x/8/16/32 VESA modes. It does, as expected, since can also see then via the printVESA stuff for the ?Video Info help on banner screen.

- With Revo, the debug output of available modes does not include 1280 ones! (160/161/162). In fact, misses a load of modes (most are null, but are shown in Chameleon). Hence defaulting to next best 118.

 

Tried to see if was obvious fix by checking code differences, but head is now spinning!!

 

Anyway, so problem appears to be not "seeing" all the available modes, and hence not setting to the 1280 one. That would explain why logo is off to right - since 1280/2 is > than 1024/2.

 

Minor problem, but wanted to let you know in case saves time chasing wrong directions later.

 

P.S. Edit. ref DMOS, seems version I use has "Root" (and was not one of those that I changed!). Ho Hum. Working fine now anyway.

[blackosx]

Hi blackosx. Thank you for that tip. It's very cool - way better than TextWrangler Compare docs, which is what I've used up to now. So much good stuff in OSX "hidden away".

FileMerge is unbeatable (and free) when it comes down to having a quick look at changed files, but not for getting simple things done – like getting a list with changed files quickly (which is why I used diff -rq).

 

Good thing you've mentioned it. I'm sure that other people here will love it too.

No probs for mentioning it. It is one of those little tucked away gems that's always good to know about and if anybody else here gets any use from it then great.

 

As for the command line tools, I just don't know them that well but that's why I like this topic as it gives me a chance to learn to use them properly.

 

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

Thanks for giving me something to work with. I'll let you know how I get on later this evening.

[humph]

	bzero(&vbeInfo, sizeof(vbeInfo));
strcpy((char*)&vbeInfo, "VBE2");
status = getVBEInfo(&vbeInfo);

Yup, that did the trick. So, this is just telling Revo to ask for VBE2 (as opposed to v1) info from the graphics. I guess?

 

Not in the delta update. Set to "Safe Boot". Also what I have here.

Erm, used wrong words. I meant fakesmc.

EDIT1> Ok I can see this works with "SafeBoot". But not if "Safe Boot".

EDIT2> Aha, yes as if "SafeBoot" then not excluded from loading. Going to do more tests to see if I can get my head around all this...

 

Previously had thought that booters would only load the kext if was Root or part of an mkext (or perhaps Console for -s), and leave it up to kextd to figure what else to load from /S/L/E; which of course does not help if the kext is in /E/E, like fakesmc or my audio kexts. Of course, downside is always loaded, even for -s or -x.

Or am I not understanding this right?!

EDIT. Could you explain how Revo handles all this