How to boost the OS X boot process...

[GrootWitBaas]

Ok some tee-spoon time here ... patch -p0 < diff_638_639.txt gives warnings. So I tried all from fresh extract on a new separate directory with patch -R -p0 < diff_638_639.txt and still have warnings on the version and revision. am I doing it wrong ?

 

next it seems like I am the only one having problems (boot freeze). Time for Diagnostics. ok let met check every thing from start to finish again and lets see where it hangs exactly.

 

Edit: ok here is my current boot sequence with all the debug I could find turned on. settings in P.D is same as I had on last version (and the old one boots) after the logo comes up nothing happens, and -v is specified c.a.B.p so the logo should not really come up. Tried also with UUID in c.a.B.p, same story. Not able to get past this.

[humph]

It is a painstakingly slow process, but we keep making progress..

Indeed. And much appreciated too!

Version 638 all OK here, both all dynamic and mostly all static.

(Still grabbing SSDT from BIOS rather than injecting - perhaps one day will take the plunge on that).

I didn't really follow the stuff earlier about moving private_data.h. Prob as had 'flu' and brain befuzzled. But did mod one of the pointers in cpu/cpu.somthing as it seemed did not go to same directory as others (had ../../ vs ../../../ in others. I have p_d in same folder as the Revo main folder).

[blackosx]

and -v is specified c.a.B.p so the logo should not really come up.

Hi groot.. It's strange the verbose kernel flag isn't being picked up? I have to ask, but can you double check your c.a.B.p?

 

Much better. Not only had you reversed the signature, but you also used bytes instead of longs (like you do now).

Yeah.. I realised my mistake and sought to solve it. However, I still don't have success with a patched FACS table. The debug image I posted earlier shows the FACS table signature is not being found to enable to patching process.

 

Thanks. It is a painstakingly slow process, but we keep making progress. I should add that we still have a long way to go, but the next update will show, once again, that I take things serious. Even if that results in long hours to do cleanups that nobody ever considered worth the while

I can image it is.. but it's only by paying meticulous detail to something that a masterpiece can be achieved.

[GrootWitBaas]

Hi groot.. It's strange the verbose kernel flag isn't being picked up? I have to ask, but can you double check your c.a.B.p?

Actually it looks like it is, but not applied correctly, see second last screen shot "/ gVerboseMode is true"

or am I interpreting this the wrong way

[blackosx]

Yep, you're correct and mine says that too.. good spot Groot

So your boot must be hanging just at the end of the the Revolution code and just before the kernel starts?

 

Maybe try turning off your per-linked kernel setting in private_data.h? as it's not being found anyhow.

 

Also, one of your images reads: Setting gPlatform.OSVersion to 10.6.

I mention it because I don't see this in my debug?

[DB1]

Good idea. Let me make a quick patch for it. Done. See attachments.

 

Now add a new file in i386/private_data.h with something like this:

#ifndef __LIBSAIO_PRIVATE_H
#define __LIBSAIO_PRIVATE_H

// #include "private_data_asus.h"
#include "../../private_data_hp.h"

#endif /* !__LIBSAIO_PRIVATE_H */

Which shows you that I have two. This is also why I was so quick, because I am in fact already using something like this. One for the new Asus and one for the HP G72 notebook.

 

Nice, works for me, a lot less hassle then trawling through all those files to make the adjustments. Looking forward to the next release. Now about speeding up? (after you cleaning up unneeded code)

 

I currently only inject device properties, smbios and dsdt, are there gains / benifits in splitting out SSDT, static cpu, APIC or the other tables we see in ioreg/AppleACPIPlatformExpert/ACPI Tables?

[DB1]

I'm constantly on the lookout for improvements. Just go back to the version of Revolution I started with, and you'll find ~5 seconds improvement.

 

 

Every little change will add up and help reduce your boot time, but don't expect a massive gain from it because like I said earlier; most of the time is used up by the mach_kernel. But why don't you give static CPU data a try?

 

This of course will change when InstandOn is supported. No more cold boot time

 

Not sure how to find the cpu static data but will look into that, and have in past played with adapting DSDT for SSDT injection so might play with that over the weekend. Perhaps I'll get a minor benefit from a 32bit only kernel if I can work it out - there's the Atom problem that goes with that though as well to consider.

 

Off out tonight to eat French, prefer Asian but my son's paying so got to go with the flow. Catch up tomorrow. Maybe you should take a break for some R & R!

[blackosx]

Hi STLVNUB

 

The kernel log reads the same for me using either Chameleon or Revolution:

blah blah blah / SAMSUNG HD501LJ Media/IOGUIDPartitionScheme/Mac@3

 

So maybe the line length for your machine is too long as you suspect. I'm sure DHP can confirm.

 

Edit: ok here is my current boot sequence with all the debug I could find turned on. settings in P.D is same as I had on last version (and the old one boots) after the logo comes up nothing happens, and -v is specified c.a.B.p so the logo should not really come up. Tried also with UUID in c.a.B.p, same story. Not able to get past this.

I've been doing some quick tests this morning and this may be linked in particular with Groot's issue of a hang before the kernel starts?

 

Booting from my USB with rev 639, if I include the kernel flag -v in c.a.B.p then the kernel starts and my machine boots, however, removing the kernel flag -v from c.a.B.p causes the same symptoms as Groot - I see the grey screen with the Apple logo and nothing else happens.

 

Correction. it does boot, just seems to take a long time and I think that's because I had the ACPI debug directive set to 1. I'll just try it again with the directive set to 0.

 

Done.. the long time is due to the auto UUID detection on my machine. Without any debugs enabled, the time it takes to get from USB disk selection in BIOS to seeing the throbber is 31 seconds! where I was previously reaching my desktop in 25 seconds.

 

Thanks. And yes. We walk all partition backwards from your twelfth partition to the first, but so is Chameleon! Not only that, because the latter also searches, opens and reads a file to extract the volume label. And that for all of your 12 partitions. We don't [have to] do this so we're obviously taking a shortcut and return quicker.

 

This is however related to the bug I am working on (which I failed to fix for v6.39) because the current (old Chameleon code) is jumping around like an idiot.

Hi DHP.. I hope that bug you mention will solve this issue?

As even if the current Chameleon RC5 code searches each of my 12 partitions, it does it a lot faster. Just checked using Chameleon without GUI from USB, and it presents me a list of bootable partitions in 6 seconds, though to be fair, I then don't see the throbber for another 23 seconds which equates to 31 seconds in total, the same as rev639...

 

So overall there is no time lost? but the boot process with the previous revolution code did feel a lot faster when I manually added a UUID in c.a.B.p. though the manually added UUID route no longer works in rev 638/9.

 

Off out tonight to eat French, prefer Asian but my son's paying so got to go with the flow. Catch up tomorrow. Maybe you should take a break for some R & R!

Hope you enjoyed your French meal

[blackosx]

Hi STLVNUB.. Wow.. you have been very busy!!

 

This is what I have: aml2struct.pl , EFI_Struct, smbios2struct.

Generators.zip

though the originally posted files by DHP are dotted throughout this topic.

[GrootWitBaas]

I've been doing some quick tests this morning and this may be linked in particular with Groot's issue of a hang before the kernel starts?

 

Booting from my USB with rev 639, if I include the kernel flag -v in c.a.B.p then the kernel starts and my machine boots, however, removing the kernel flag -v from c.a.B.p causes the same symptoms as Groot - I see the grey screen with the Apple logo and nothing else happens.

 

Correction. it does boot, just seems to take a long time and I think that's because I had the ACPI debug directive set to 1. I'll just try it again with the directive set to 0.

 

Done.. the long time is due to the auto UUID detection on my machine. Without any debugs enabled, the time it takes to get from USB disk selection in BIOS to seeing the throbber is 31 seconds! where I was previously reaching my desktop in 25 seconds.

 

I have tested also, and you said a long time, so I left it on the logo screen for at least a hour ....nothing.

 

I have the following set to 1 in P.D. I have tried most other settings. and have also tried with some of the below turned to 0. There is 2 that is "needed" on my system by the looks of it, A20 and EFI_64. I have tried with and without c.a.B.p having a UUID

 

#define ACPI_10_SUPPORT
#define APPLE_STYLE_ACPI
#define MUST_ENABLE_A20	
#define APPLE_STYLE_EFI
#define INJECT_EFI_DEVICE_PROPERTIES
#define EFI_64_BIT

Example of MY EFI DEVICE PROPERTIES
/* 0x0000 */	0x71, 0x02, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, \
/* 0x0008 */	0x01, 0x00, 0x00, 0x00, 0x65, 0x02, 0x00, 0x00, \
……
/* 0x0268 */	0x69, 0x6e, 0x74, 0x65, 0x72, 0x6e, 0x61, 0x6c, \
/* 0x0270 */	0x00

 

Until now I was NOT once able to boot with rev 638. In 637 settings that work is below and this worked without fail as long as I have a UUID in c.a.B.p

#define ACPI_10_SUPPORT
#define APPLE_STYLE_ACPI
#define MUST_ENABLE_A20	
#define APPLE_STYLE_EFI
#define INJECT_EFI_DEVICE_PROPERTIES

[blackosx]

Bummer. I found that issue you've reported blackosx. FACS is not a normal table. Learned that from reading the ACPI specification earlier, but I simply copied the same code snippet for ECDT, HPET and FACS. Which is wrong. Let me correct this right away... Here it is. Please add the following lines in acpi/patcher.h:

...../snip/......

Added a debug dump for you, so that you can see when it works.

Hi DHP. I've tried the above patch to acpi/patcher.h and I now have the following in my debug

PatchedFADT->FIRMWARE_CTRL: 0xdfee0000

 

Checking diff for other errors... Ok. Another one. Can you please try using sys.c from the previous release to see if that solves it?

Replacing sys.c from previous (v636_5) makes no difference.

[GrootWitBaas]

yes I boot fine with 637 If UUID is set static in c.a.B.p.

 

As per request below here : diff_637_638.txt

 

this will also include most corrections you asked for in the thread, but I was not able to do the patch you listed see this post

[blackosx]

Sorry for the delay, I've been busy building in the garden.

 

I lost a hard drive today when brother dear accidentally formatted it when he installed OS X for me. He said that the drives were swapped in diskutility?!?

Nightmare! I bet he feels bad...

 

Good. Have you changed the revision byte to see if what you get in IORegistryExplorer is yours? I did. Used 2 instead of 1 and it's there. Appears to work well.

No point in changing any bytes here yet as even though I see a value in my debug with the additional code, ioreg still doesn't show any data in my FACS table other than <"FACS@">.

 

One off the list to check. Back to the drawing board.

Hang on.. I reverted to a previous sys.c for testing the FACS table. That's why I reported it as making no difference. Should i have been checking for something else there?

[DB1]

Update: I now also attached a diff to Revolution 6.40 with dozens of cleanups and a number of bug fixes.

 

done 638>639>640 638,639 ok but 640 gives compile error:

In file included from acpi.c:100:
acpi/patcher.h: In function ‘setupACPI’:
acpi/patcher.h:219: error: ‘DSDT’ undeclared (first use in this function)
acpi/patcher.h:219: error: (Each undeclared identifier is reported only once
acpi/patcher.h:219: error: for each function it appears in.)
make[2]: *** [acpi.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

[humph]

Hi DHP, BlackOSX...I'm also in a bit of a mess in terms of getting 640 up here..

 

I know I got all out of shape with the changes to private_data.h, so reverted to the clean file downloads for 638 and the 638-639 and 639-640 patches. But getting patch errors....

eg: the "raw" 638 boot2/boot.c has ../../../private_data already. Whereas patch to 639 supposedly changes from ../ to ../../../; And patch to 640 has change from ../ to removing altogether. But it's already ../../../ either from raw 638 or from patch to 639, so fails. Can't see quick way around.

 

I know I could run through all changes by hand, but given the large size of the diff to 640, would be really appreciated if you could upload a good version of 640 !!

 

EDIT:

P.S. Earlier I tried the "move tables to /i386/data folder" trick for a couple of tables and compiled nicely. Definitely nicer as was pain to have to recopy DSDT data to new template each time, since on this old ATOM thing X Code Tools runs rather slow for that sort of thing!

P.P.S. Yes, am using static CPU with no probs that I am aware of. Got the info from CPU debug output (and cross-checked with some info on the processor from some CPU tech-data site out there).

[blackosx]

done 638>639>640 638,639 ok but 640 gives compile error:

....

Same for me.

 

I know I could run through all changes by hand, but given the large size of the diff to 640, would be really appreciated if you could upload a good version of 640 !!

Hi humph

 

Here's the one I just did from 638 thru 640 that gives the same compile error as DB1.

Revolution_640_from_Fresh.zip

 

P.S. Earlier I tried the "move tables to /i386/data folder" trick for a couple of tables and compiled nicely. Definitely nicer as was pain to have to recopy DSDT data to new template each time, since on this old ATOM thing X Code Tools runs rather slow for that sort of thing!

I haven't tried that yet. Maybe I'll look at that later this evening, but I'm off out a bit later for a meal.

[blackosx]

On the subject of diffs, how do I apply them.

Yes, too lazy to look.AND TOO OLD TO REMEMBER.

Thanks

Hi STLVNUB

 

I cd to the folder I want to patch, then use the command:

patch -p1 < patchfile.diff

 

doing this for the original Revolution-638 shows the following:

Reversed (or previously applied) patch detected!  Assume -R? [n]

and repeats for more than one file, but I just answer Y for each.

 

doing the same for patch command from 639-640 works just fine.

 

Ah ok. Change this acpi/esessentials.h

Lovely. That builds. Thanks

 

 

EDIT:

Testing rev640, first boot failed with:

APCI_SMC_PlatformPlugin::registerLPCDriver - failed to locate SMC driver

 

I've got to leave this for now. I'll check back in later. Keep up the good work everyone.

[DB1]

Ah ok. Change this acpi/esessentials.h

-#if LOAD_DSDT_TABLE_FROM_EXTRA_ACPI
+#if STATIC_DSDT_TABLE_INJECTION || LOAD_DSDT_TABLE_FROM_EXTRA_ACPI
DSDT,
#endif

..

-#if LOAD_SSDT_TABLE_FROM_EXTRA_ACPI
+#if STATIC_SSDT_TABLE_INJECTION || LOAD_SSDT_TABLE_FROM_EXTRA_ACPI
SSDT,
#endif

 

Yep, that sorted it out. Up and running no issues - except playing with static cpu I get a 16ghz atom core 2

[GrootWitBaas]

used the 640 from Blackosx and made the change as above. Compiles with no problem, and I can boot again \o/

 

will test now without -v and uuid (or even without c.a.B.p)

Works Perfect without a c.a.B.p

 

Now can someone get out a tee-spoon please, and tell me how to fix "Warning: audit space low (< 5% free)on audit log file-system"

[humph]

Thankyou BlackOSX, DB1. Have now compiled 640 and about to reboot.

Thought I'd better post now just in case I'm not back for a while...

 

P.S. I'd love to have a 16GHz ATOM processor. Would speed things up no end!!

 

EDIT: Hmm, well not working here. But as tried versions of files from BlackOSX and DB1 (thank you again!) as well as my hacked about mess, it's most likely something I'm doing wrong. Will have to take a look tomorrow. Issue is never get to spinner/kernel loading. Have not tried debug yet so can only guess. Is sort of like if EFI=64bit, but I have that set to 32bit already.

 

UPDATE: It's an "Allocate Kernel Memory Error".....well, over to the expert(s) on that one!

[dgsga]

used the 640 from Blackosx and made the change as above. Compiles with no problem, and I can boot again \o/

 

will test now without -v and uuid (or even without c.a.B.p)

Works Perfect without a c.a.B.p

 

Now can someone get out a tee-spoon please, and tell me how to fix "Warning: audit space low (< 5% free)on audit log file-system"

 

I think you need to do your housekeeping tasks using Tinker Tool System to rotate log files etc. (in the system maintenance section of the app.)

[GrootWitBaas]

think I got it fixed with "sudo audit -t". Not sure if that is the right way, but I don't have the error no more

[blackosx]

Building in the garden? In this weather? Brave man!

Yeah, was a bit windy and a little wet but the weekends are the only daylight time I get at the moment.

 

Most of my new stuff was on this drive.

Oh bummer!

 

That's weird. I see the values I changed in it. Might need more attention for people with a broken/invalid FACS table.

mmm. I'm afraid so.

I'll let you know what happens when booting from rev-640 once I can boot with #define PATCH_ACPI_TABLE_DATA. See below

 

Unrelated to the FACS patch. Is about finding the UUID. Should have a new patch later today though I am only starting just yet.

ah, okay.. I understand that now.. I'll wait for your next patch for that then.

 

Went to the Apple store for a keyboard replacement. This BT one works just great.

Nice.. For my iMac, I have the wired keyboard with number keypad and the BT Apple magic mouse, which I didn't like at first but absolutely love now, except maybe for the flatness of it.

 

I see that it works now. Great. Thanks for the confirmation.

Yep rev-640 is working but not completely (yet).. see below

 

I guess you've seen what I did?

To get it to compile? yes.

 

Time for me to finish the patch I was planning to work on, after dinner, and then go back to the ACPI patcher... to allocate all needed memory in one go

Cool.. see you when you're next online.

 

 

 

UPDATE: It's an "Allocate Kernel Memory Error".....well, over to the expert(s) on that one!

Hi humph

 

Yes, I'm getting the 'Allocate Kernel Memory Error' too.

I've been trying different settings in private_data.h to try to find out the reason and I can say that I've nailed the problem down only as far as enabling #define PATCH_ACPI_TABLE_DATA brings up the error. As I'm using a patched bios, I can boot perfectly without that setting.

 

Setting SAFE_MALLOC to 1 makes no difference.

[blackosx]

Let's make this easy for me. What are your ACPI directives?

For testing now, these work

#define ACPI_10_SUPPORT 1

#define PATCH_ACPI_TABLE_DATA 0

#define USE_STATIC_ACPI_BASE_ADDRESS 0

#define STATIC_APIC_TABLE_INJECTION 0

#define STATIC_DSDT_TABLE_INJECTION 0

#define STATIC_SSDT_PR_TABLE_INJECTION 0

#define STATIC_SSDT_USB_TABLE_INJECTION 0

#define STATIC_SSDT_GPU_TABLE_INJECTION 0

#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 0

#define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI 0

#define DROP_SSDT_TABLES 0

#define APPLE_STYLE_ACPI 0

#define DEBUG_ACPI 0

 

Just changing:

#define PATCH_ACPI_TABLE_DATA to 1 causes the AllocateKernelMemoryError.

 

Otherwise, normally I'm using:

#define ACPI_10_SUPPORT 1

#define PATCH_ACPI_TABLE_DATA 1

#define USE_STATIC_ACPI_BASE_ADDRESS 1

#define STATIC_APIC_TABLE_INJECTION 0

#define STATIC_DSDT_TABLE_INJECTION 1

#define STATIC_SSDT_PR_TABLE_INJECTION 0

#define STATIC_SSDT_USB_TABLE_INJECTION 0

#define STATIC_SSDT_GPU_TABLE_INJECTION 0

#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 0

#define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI 0

#define DROP_SSDT_TABLES 1

#define APPLE_STYLE_ACPI 1

#define DEBUG_ACPI 0

 

I can still boot with the brown coloured ones.

The purple one won't allow compilation if the blue one is not enabled which make sense.

[GrootWitBaas]

and that said remember both Blackosx and my bios is of the very few as per comments "but please note (very well) that this is only supported by very few motherboards / BIOS'es." that does not need a patch or restart fix.