How to boost the OS X boot process...

[blackosx]

I'll enable all my debugging to verify. (I should have done this before to be helpful, sorry DHP).

Yep. execKernel-[0-4] is the last I see from boot.c and if it helps, with all debug turned on, the code gets as far as showing the Factory RSDT: and all the xsdt-> values before the AllocateKernelMemory error

[blackosx]

Is it something to do with this?

int i = 0;

for (; i < sizeof(injectableTables); i++)
{
	if (staticTables[i].table)
	{
		staticTables[i].tableAddress = (void *)AllocateKernelMemory(staticTables[i].tableLength);
		memcpy(staticTables[i].tableAddress, (void*)staticTables[i].table, staticTables[i].tableLength);
		staticTables[i].table = 0;
	}
}

[blackosx]

Located the problem in acpi/patcher.h Me stupid. Make this change and it will boot again:

Fab. Fix added. Rebooting now..

And I'm back!.. Bingo..

Well done DHP.

 

Yes. And thank you for the excellent help in getting this fixed!

NP.. Team work

 

ps. I'm off to bed now.. I'll catch up with any more advancements in the morning.

[humph]

Located the problem in acpi/patcher.h Me stupid. Make this change and it will boot again:

#if LOAD_SSDT_TABLE_FROM_EXTRA_ACPI
loadACPITable(SSDT);
#endif

int i = 0;

[color="#FF0000"]for (; staticTables[i].table; i++)
{
	if (staticTables[i].tableLength)[/color]
	{

Back up booting with that. Awesome!

[scrax]

To make it compilo I had to change this:

#if LOAD_SSDT_TABLE_FROM_EXTRA_ACPI
{ "SSDT",	0,					[color="#FF0000"]SSDT_Table[/color],		0 },
#elif STATIC_SSDT_TABLE_INJECTION
{ { 0 },	sizeof(SSDT_Table),		SSDT_Table,		0 },

to this:

#if LOAD_SSDT_TABLE_FROM_EXTRA_ACPI
{ "SSDT",	0,					0,		0 },
#elif STATIC_SSDT_TABLE_INJECTION
{ { 0 },	sizeof(SSDT_Table),		SSDT_Table,		0 },

 

Now testing if it boots...

[blackosx]

Showing as MacBookPro6,1 How to fix this??

Boot in to your system with Chameleon using an SMBIOS.plist to override your settings to how you want them, then double-click the smbios2struct tool to convert all your settings to the data structure that Revolution wants. Then paste the result in to private_data.h.

 

Here's a sample of the start of mine:

#define USE_STATIC_SMBIOS_DATA				1	// Set to 0 by default. Change this to 1 to dynamically collect the SMBIOS data.

#define DEBUG_SMBIOS						0	// Set to 0 by default. Change this to 1 when things don't seem to work for you.


#if USE_STATIC_SMBIOS_DATA
#define	STATIC_SMBIOS_SM_STRUCTURE_SIZE		126

#define	STATIC_SMBIOS_DMI_STRUCTURE_COUNT	40

#define STATIC_SMBIOS_DATA \
/* 0x0000 */	0x00001800, 0xe0000504, 0x9e800f06, 0x00007fc9, 0x05330000, 0xffffffff, 0x72617741, 0x6f532064, \
/* 0x0008 */	0x61777466, 0x49206572, 0x7265746e, 0x6974616e, 0x6c616e6f, 0x6e49202c, 0x46002e63, 0x00633131, \
/* 0x0010 */	0x312f3131, 0x30322f38, 0x41003930, 0x656c7070, 0x636e4920, 0x504d002e, 0x382e3133, 0x302e5a38, \
......

 

Bug in private_data.h

.../snip/...

#if USE_STATIC_ACPI_BASE_ADDRESS //need this Or Next line is DEFINED

Nice one

 

Thank you for spotting this. Now look at acpi.c and see what I forgot. Yes indeed. There's one without USE_ in front of it. And that's the one causing people trouble. Thanks again!

Great. Applied.

 

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

Now I am up and booting with rev-640 I an report that unfortunately I still don't have populated data in ioreg for the FACS table.

 

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!

I can however confirm that Rev-640 now has a lot faster auto UUID detection when it comes so scanning all 12 of my partitions - Nice on DHP

 

Booting from HDD, the time taken from selecting the drive in BIOS until I see the throbber is 9.8 seconds, reaching the desktop in a further 19.8 seconds, giving a total duration of 30.6 seconds. And that's booting my system with VMWare, developer tools etc.

 

EDIT:

Just re-worked my system to boot from a pre-linked kernel and this saves 4 seconds.

Time from HDD selection in BIOS until throbber is still 9.8 seconds, though time to desktop now is only 26.6 seconds, rather than 30.6 .

 

hmmm.....

Just timed my boot process from USB flash drive using the same boot file and it's drastically different as the time taken from selecting the drive in BIOS until I see the throbber is 30.4 seconds! that's 20 seconds longer than from HDD? Why would that be?

[blackosx]

Good morning DHP.

 

I have to get back at this at a later stage, because I seriously need to fix the bug I am working on in sys.c first.

No problem.

 

Good to hear. The next update will be faster again as I will reinstate the EFI_BOOT_PARTITION_SUPPORT directive, and skip a partition or ten (in your case).

Looking forward to that one

 

A wild first guess. You have a different mkext or no pre-linked kernel on the USB-stick?

Good thinking young lady.. I'll check it now. Thanks

 

EDIT:

Unfortunately not. Updating my USB to use the same boot file and pre-linked kernel as I am using for booting from HDD still takes a lot longer. I just tested using the DEBUG_BOOT enabled and timing from USB selection in BIOS to when the pre-linked kernel loading is complete takes 25.4 seconds. I guess this is down to loading the pre-linked kernel from USB (or previously when i tested, loading the mach_kernel)?

 

I'm off to work again in the garden.. (better wrap up warm.. Lol)

I'll check in later. Have a good day

[GrootWitBaas]

Hope you win the match

 

Nice work DHP thanks. It works I am booted on 641, but I made a change .....I saw a second private_data.h in the i386 folder, but I have my private_data outside of the 641 folder. I removed this from there and fixxed the 3 compile errors by adding the ../../ for private_data. Hope this was the right thing to do.

 

And on boot time, I am down to 29,5 seconds taking the same measurement as before from selecting the drive until browser open on this page. Booting directly from my SSD drive. For future comparison I have measured cold boot time from power on until desktop display and this is 38 seconds. I am happy with this seeing that more than half this time is taken by loading the mach_kernel.

[humph]

And DB1 and other people booting from the hidden EFI partition must add / set #define EFI_BOOT_PARTITION_SUPPORT 1 under DISK.C in private_data.h

 

p.s. Have a hockey match in 30 minutes from now so I will be off-line for quite some time. Have fun!

Booting OK!

Note that my SD card does not have an EFI partition, but am booting from the 1st (and only) HFS partition on the card, so needed to add the above directive. I guess this (now) really means "boot from 1st partition" rather than EFI type?

 

DHP - Good Luck with the match/Hope it went well.

[dgsga]

Good afternoon all

 

DHP, hope you won the match! 641 boots without any issues, definitely faster on my rig and noticeably smaller too. My booter is 113984 bytes with static everything. Because of my ATI radeon graphics I have quite a long efi injection string which takes up most of the space No way round that as far as I can see...

[blackosx]

The next update is a lot faster now that:

Eh up.. another update.. good work DHP.. I'll try it now..

 

EDIT: Great job - boots just fine here - and faster too

 

Booting from USB is now as I would expect and almost as fast as from HDD now with me seeing the throbber in 9.9 seconds of selecting the USB flash drive from BIOS.

[DB1]

Notes: We didn't really support anything else but HFS, but setting directives now won't help make it work anymore. And DB1 and other people booting from the hidden EFI partition must add / set #define EFI_BOOT_PARTITION_SUPPORT 1 under DISK.C in private_data.h

 

641 up and running from SD card, same as humph single partition SD wont boot without EFI_BOOT_PARTITION_SUPPORT 1 addition to private_data.h (SD format is Mac OS Extended (Journaled)). Will try next on my spare hdd for EFI partition.

 

UPDATE

 

Working sweet from EFI partition, much faster than from SDcard.

[blackosx]

Nice work DHP thanks. It works I am booted on 641, but I made a change .....I saw a second private_data.h in the i386 folder, but I have my private_data outside of the 641 folder. I removed this from there and fixxed the 3 compile errors by adding the ../../ for private_data. Hope this was the right thing to do.

Hi Groot, I guess you've missed a previous post here?

A dummy private_data.h file is now included in the /i386 folder which contains a link to your own private_data.h file. This way if you have it in a different location to what's expected or have it as a different name then you only have to change the name in the dummy file rather than every occurrence in the source code.

[GrootWitBaas]

ok yes I have missed that part .....

but in this dummy it says #include "../../private_data_hp.h" and I guess it should say #include "../../private_data.h" ?

alternatively I rename my Private_data_groot.h and change the name in the dummy if I follow correctly

 

So back to SAMS teach yourself cpp in 21 days

[blackosx]

but in this dummy it says #include "../../private_data_hp.h" and I guess it should say #include "../../private_data.h" ?

alternatively I rename my Private_data_groot.h and change the name in the dummy if I follow correctly

That's right. The private_data.h file that DHP uses is called private_data_hp, that's why the sources have it named that way. You can change the name, and the path it you want to, to match your own private_data.h. So if you want to call it Private_data_groot.h then that's great. Or in my case, I have one called private_data_hdd.h and one called private_data_usb.h which I use for different scenarios and testing.

[GrootWitBaas]

nope not yet, was to lazy to get all the info. I have static smbios data and this gives me almost the right output on cpu. If I turn static smbios off the I have a unknown cpu running 33GHz

static

non static

 

static data was extracted booting from chameleon using the tools from blackosx

 

O and I REALLY need to get a spare HDD cleaned and ready for testing, should not do testing on my main drive

[blackosx]

@Blackosx: Can you replace this line in acpi/patcher.h:

_ACPI_DEBUG_DUMP("patchedFADT->FIRMWARE_CTRL: 0x%08x\n", patchedFADT->FIRMWARE_CTRL);

With these two:

_ACPI_DEBUG_DUMP("FADT->FIRMWARE_CTRL   @: 0x%08x\n", patchedFADT->FIRMWARE_CTRL);
_ACPI_DEBUG_DUMP("FADT->X_FIRMWARE_CTRL @: 0x%08x\n", patchedFADT->X_FIRMWARE_CTRL);

And tell me what you get?

I see the following:

FADT->FIRMWARE_CTRL	@:	0xdfee0000
FADT->X_FIRMWARE_CTRL	@:	0x00000000

 

You may also try:

-patchedFADT->X_FIRMWARE_CTRL	= (uint64_t) 0;
+patchedFADT->X_FIRMWARE_CTRL	= patchedFADT->FIRMWARE_CTRL;

To see if that works.

Does nothing.

 

Also worth mentioning is with rev-641, if I just turn on #define DEBUG_ACPI and have -v kernel flag in c.a.B.p, I still see the grey screen with the Apple logo at boot. Only if I also turn on a secondary debug, in this case #define DEBUG_BOOT, do I then see the debug.

[GrootWitBaas]

We did, but it was close. Thanks (everyone).

 

Is your bus speed really 1.76GHz?

 

A spare USB-stick or SD-card can also be used, and is a lot cheaper.

 

Congrats

 

No, 1600/1333/1066/800 MHz FSB

 

I have around 10 drives lying around, some usb drives also ....but I need a full backup in case, was just lazy to find a disk I can clean out and use. am running ccc right now so will have a backup shortly. Will be nice to compare boot speed from SSD,SataI and SataII

 

I am also looking for some explaining of all the static cpu info (I have dumps from linux and info from google) but am not sure where what is supposed to go. Some are easy but other I am not sure

 

#define STATIC_CPU_Vendor 0x756E6547 <-this is intel right ?

#define STATIC_CPU_Signature 0x20652 <-not sure where to get this

#define STATIC_CPU_Stepping 10 <- from linux

#define STATIC_CPU_Model CPU_MODEL_DALES_32NM <- again not sure (Yorkfield)

#define STATIC_CPU_Family 6 <-from linux

#define STATIC_CPU_ExtModel 2 <-from where ?

#define STATIC_CPU_ExtFamily 0 <-from where ?

#define STATIC_CPU_Type 0x901 <-from where ?

#define STATIC_CPU_NoCores 4 <-from linux

#define STATIC_CPU_NoThreads 4 <-from where ?

#define STATIC_CPU_Features 0xbffbfbff <-from where ?

#define STATIC_CPU_CurrCoef 0x11 <-from where ?

#define STATIC_CPU_MaxCoef 0 <-from where ?

#define STATIC_CPU_CurrDiv 0 <-from where ?

#define STATIC_CPU_MaxDiv 0 <-from where ?

#define STATIC_CPU_TSCFrequency 226100000ULL <-from where ?

#define STATIC_CPU_FSBFrequency 133333333ULL <- mine is 800Mhz what goes in here ? 800000

#define STATIC_CPU_CPUFrequency 226100000ULL <- mine is 2400Mhz what goes in here ? 2400000

#define STATIC_CPU_QPISpeed 33500[/code] <-from where ?

 

So above all in blue I have values from Linux dump, the rest I am not sure how to get, or how to convert it to the right value based on information for my cpu, see attached cpuinfo.txt and dmicode_uptocpu.txt as well as Intel specs

cpuinfo.txt

dmidecode_uptocpu.txt

[GrootWitBaas]

Hi Groot,

 

Everything you need can be obtained by using dynamic CPU data and enabling DEBUG_CPU (note the change I mentioned earlier here). That will dump the values you are looking for.

 

Using the data from the debug in static, but once I enable static CPU data then I get a reboot loop just when boot starts running, right after this :

 

Static Debug info is :

 

Yes I have over clocked to 3,3GHz and yes it runs nice a cool like this.

[blackosx]

Too bad. Will have to come up with something else. No idea yet unfortunately.

Again, it's no problem.

 

I keep forgetting about it. Slipped off the TODO list once again. Thank you for mentioning it. Easy fix. In boot.c change this snippet (will be part of the next update):

Thanks. That fixes it once and for all

[GrootWitBaas]

so the over-clocking should not make a change. I can set it back to default (6*400=2400) currently it is 7,5 * 440 = 3300 so maybe it does not like the 7,5 bit. Let me test it. I am more worried about the rebooting. sysctl -a | grep cpu is also attached just to see what I get from it. Looks like everything is in there, except the multiplier

 

sysctlgrepcpu.txt

 

Ok the reboot is caused because boot wants to "overclock" or set clock and the values it have is placing the CPU out of specks causing the protection from bios to reboot the system, with a nice warning when I enter bios about it. I have played and looked at all the values and also where they are applied, but still no luck. For now I use dynamic cpu (but the info is NOT correct) and I see some errors in the Kernel log like this :

P-State Stepper Error 18 at step 37 on CPU 0

P-State Stepper Error 18 at step 33 on CPU 2

This was not there before. I will go back to my old setting for now and test some more.

 

I am however happy with my new specs in about this mac

 

Except for DHP who else is using static CPU data ?

 

below is my current settings for q8300, I have also tried most variants

#define STATIC_CPU_Vendor					0x756E6547
#define STATIC_CPU_Signature				0x1067a
#define STATIC_CPU_Stepping				0xa
#define STATIC_CPU_Model				CPU_MODEL_PENRYN
#define STATIC_CPU_Family				0x6
#define STATIC_CPU_ExtModel				0x1
#define STATIC_CPU_ExtFamily				0x0
#define STATIC_CPU_Type					0x501
#define STATIC_CPU_NoCores				0x4
#define STATIC_CPU_NoThreads				0x4
#define STATIC_CPU_Features				0xbffbfbff
#define STATIC_CPU_CurrCoef				0x6
#define STATIC_CPU_MaxCoef				0x7
#define STATIC_CPU_CurrDiv				0x1
#define STATIC_CPU_MaxDiv				0x1
#define STATIC_CPU_TSCFrequency			2400000000
#define STATIC_CPU_FSBFrequency			0400000000
#define STATIC_CPU_CPUFrequency			2400000000
#define STATIC_CPU_QPISpeed				0

[GrootWitBaas]

look in Revolution-641/i386/libsaio/cpu/essentials.h for the name. Only way I see other than unknown cpu is by using static smbios data pulled from a chameleon boot showing Quad-Core Intel Xeon

[scrax]

so the over-clocking should not make a change. I can set it back to default (6*400=2400) currently it is 7,5 * 440 = 3300 so maybe it does not like the 7,5 bit. Let me test it. I am more worried about the rebooting. sysctl -a | grep cpu is also attached just to see what I get from it. Looks like everything is in there, except the multiplier

 

Are you using NullCPUPowerManagment.kext ?

If not give it a try because when you have a big OC AppleIntelCPUPowerManagement.kext does not work right because he want to use default value for p, c state and so on. So when in OC we have to get rid of speedstep and appleCPU management so we can go with the freq and volts we want (but we loose stop or reboot, I don't remember right).

[GrootWitBaas]

Only non standard kext I use is fakesmc and the one for audio. The rest of my system is completely vanilla and native speed-stepping works. It is something about when the values are static that makes it not to work. I have to play with it until I get it right. I have currently the OC turned off completely so I am running stock 6*400=2400

[scrax]

Only non standard kext I use is fakesmc and the one for audio. The rest of my system is completely vanilla and native speed-stepping works. It is something about when the values are static that makes it not to work. I have to play with it until I get it right. I have currently the OC turned off completely so I am running stock 6*400=2400

Yes, because if you go vanilla you need to keep also your CPU in a "vanilla" state so no OC.

If you make just a little Oc it can still works pretty well but when you have a big OC things go wrong because the system want to use different value (the one for a non OC CPU) than the ones set in bios.

I thought that Apple don't support more than a defined CPU freq. and so when our overclocked CPU Freq is higher than the apple limit we start to have problem with the OC and power management.

 

Hope this make sense.

 

I believe that if you want to OC you need to get rid of speedstep using NullCPUPowerManagement.kext

This will keep your system always at full speed and for a desktop computer it could be acceptable.