How to boost the OS X boot process...

[humph]

Attached is a patch for disk.c which should work for DB1 and Humph. Gentlemen. Please verify this patch to be working for you, so that we can apply it to the next update.

Well, seems to work here - without needing the EFI flag thing - and selects the 1st OSX installation (disk0s2) rather than previously picking the last one (not using UUID). So if that was the intention, then cool. Although I was sort of getting into the idea to be booting my sandbox clone (which is probably a good idea, mess with the clone, rather than the "real" installation. But is OK this way also, and I guess most people would expect to boot the 1st one anyway.

 

Also got carried away and added the cpu patch. Seems to not make any difference here - but that's OK as was working before, so not broke anything. Added the directive for INTEL, as I see no AMD in xx/cpu and was failing to compile w/o the directive due to no xx/cpu/amd. Or something like that .

 

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.

Can't you develop custom SSDT stuff for VIDs, P, C states etc?

Then load the custom SSDT rather than the in-BIOS one?

Also doesn't Cham with P&C state do something different - thought that now could handle some level of overclock also - although may be getting mixed up..Anyway, I do a mid overclock on the P55 from 2.6 to 3.2 and just use native speed step, no special SSDT tables.

[scrax]

Can't you develop custom SSDT stuff for VIDs, P, C states etc?

Then load the custom SSDT rather than the in-BIOS one?

Also doesn't Cham with P&C state do something different - thought that now could handle some level of overclock also - although may be getting mixed up..Anyway, I do a mid overclock on the P55 from 2.6 to 3.2 and just use native speed step, no special SSDT tables.

From the test made with other users like smith@@ and iFabio in the italian sections we have found that with a big OC the right P and C states are ignored either if injected with dsdt or ssdt

If I don't remember wrong the only way to have speedstep working with this type of OC was to use the app P-State enabler with AppleIntelPowerManagement.kext disabled or removed.

 

But also i see a lot of people in the "OC world" that don't want to use speedstep with an OC system because they want to have ALWAYS the max CPU freq. Is for that that they spend a lot on cooling stuff

 

I stopped to use an OC system when i went to a ssd drive for the os. That was a real performance increase, even if geekbench is still the same.

This and a lot of RAM are the best performance booster IMHO.

[GrootWitBaas]

ok but taking off all OC settings in bios, running stock, I should be able to use static cpu info. I can not do this. can any one else with q8300 run static cpu data, and if so please can you tell me what you have in there.

[DB1]

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):

-#if DEBUG_BOOT
+#if DEBUG_ACPI || DEBUG_BOOT || DEBUG_CPU || DEBUG_DISK || DEBUG_EFI || DEBUG_PLATFORM || DEBUG_SMBIOS
// Don't switch graphics mode / show boot logo when DEBUG is set to 1.
printf("\ngArchCPUType (CPU): %s\n", (gArchCPUType == CPU_TYPE_X86_64) ? "x86_64" : "i386");
#else
showBootLogo();
#endif

That should do the trick. Can't test it myself right now. In the middle of another rewrite of the ACPI patcher. Got to love it.

 

Attached is a patch for disk.c which should work for DB1 and Humph. Gentlemen. Please verify this patch to be working for you, so that we can apply it to the next update. Thank you for your assistance (much appreciated, as always).

 

OK updated to 642 and did the debug to get static CPU data. Then added the above debug also.

 

Re CPU igot a debug output:

 gArchCPUType (CPU) : i386
Mach-0 file has bad magic number

DecodeKernel () failed!

 

Dont forget we have a patched kernel because Atom support was pulled out at 10.6.2

 

With SDCard Tried with EFI directive set at 0, no boot, just grey screen and apple no throbber. Tried hashed out same result. Only boots with that set at 1 (BTW my SDCard is Guid single partition, no UUID or default partition settings in c.a.B.p)

 

Further cpu info screenshots:

Static is set from the CPU debug data! Dynamic gets pretty close and think it's only showing core 2 because the patched kernel is being fooled. My Chameleon has a core sole patch, I'll dig it out and see if it's something that can be applied

 

Here's the Chameleon core solo fix:

diff -uNr trunk/i386/libsaio/smbios_patcher.c trunk.coresolo/i386/libsaio/smbios_patcher.c
--- trunk/i386/libsaio/smbios_patcher.c	2010-02-24 20:31:36.000000000 -0500
+++ trunk.coresolo/i386/libsaio/smbios_patcher.c	2010-05-17 16:26:54.000000000 -0400
@@ -145,7 +145,7 @@
static int sm_get_cputype (const char *name, int table_num)
{
	if (Platform.CPU.NoCores == 1) {
-		return 0x0101;   // <01 01> Intel Core Solo?
+		return 0x0201;   // <01 02> Intel Core Solo
	} else if (Platform.CPU.NoCores == 2) {
		return 0x0301;   // <01 03> Intel Core 2 Duo
	} else if (Platform.CPU.NoCores >= 4) {

 

I see in Revolution Cpu>dynamic_data.h you have;

	if (gPlatform.CPU.Type == 0x301) // Intel Intel Core 2 Duo.
{
	if (gPlatform.CPU.NoCores >= 4)
	{
		gPlatform.CPU.Type = 0x0501;	// Intel Quad-Core Xeon (or similar).
	}
	else if (gPlatform.CPU.NoCores == 1)
	{
		gPlatform.CPU.Type = 0x0201;	// Intel Atom - Intel Core Solo.
	}
}

 

So it should be picking it up as core solo, assuming it's detecting NoCores ==1

 

UPDATE

 

Tried on my spare hdd from EFI partition and it wont boot without EFI Support directive being set 1

[blackosx]

I've had one instance in the last week and again this evening where I've returned to my hack which i had previously put to sleep to find the machine with no video and fans at full speed. A forced power off is then needed.

 

Could this be something to do with my ACPI tables? or maybe something in the bootloader? I've looked in the system log but can't find anything to help. I'll keep looking and maybe I'll try using dynamic data for a while to see if it occurs that way just so I can rule out my static data.

 

Also something else I've noticed is after booting from USB using kernel flag arch=i386 and looking at System Profiler/Software is see

64-bit Kernel and Extensions:	Yes

?????

 

Whilst booting with the same boot file and c.a.B.p from HDD I see

64-bit Kernel and Extensions:	No

which what I expect.

 

Is this something stupid I'm doing or is it a bug?

[DB1]

I've had one instance in the last week and again this evening where I've returned to my hack which i had previously put to sleep to find the machine with no video and fans at full speed. A forced power off is then needed.

 

Could this be something to do with my ACPI tables? or maybe something in the bootloader? I've looked in the system log but can't find anything to help. I'll keep looking and maybe I'll try using dynamic data for a while to see if it occurs that way just so I can rule out my static data.

 

Yeah I've had this too but with nobody else mentioning it thought it was something to do with the patched kernel i'm using as i've never had to use that before using Revolution. I think I was on 638 when i noticed it, but have not really since, then again I don't recall leaving it to sleep. Lid sleep and wake works fine, power switch to sleep and menu to sleep and then wake work fine.

 

I'll leave it to go into sleep and see what happens.

[blackosx]

Hi DB1.. It's funny but I haven't been paying much attention to things like sleep.

I've just manually put my machine to sleep and bang!.. it then crashes and does as I explained previously.

 

I'll go and do some testing.

[DB1]

Hi DB1.. It's funny but I haven't been paying much attention to things like sleep.

I've just manually put my machine to sleep and bang!.. it then crashes and does as I explained previously.

 

I'll go and do some testing.

 

Tested wit 640 and everything fine all modes of sleep. Perhaps a bug in previous revisions.

[DB1]

Good evening DB1,

 

Listen. The smbios/cpu detection code in Revolution 641 and 642 is identical. I only moved the files into a new sub-directory and changed some debug output related lines. Nothing else.

 

 

That is weird. Please don't tell me that your copy of disk.c still includes:

#if EFI_BOOT_PARTITION_SUPPORT
	int gptID = 1;
#else
	int gptID = 2;
#endif

Because then you missed a patch.

 

 

16GHz is a factor 10 of 1.6GHz and thus you have a zero too much at the end.

 

 

Open IORegistryExplorer and click on your CPU to find cpu-type. That will tell you what it is. And yes, it is 01 02 there.

 

 

You need the directive in order to boot from the EFI partition. Maybe we should eliminate the directive and just accept a tiny little few extra bytes. In fact that's my plan for the next update. Should just work...

 

Just have int gptID = 1; (in disk.c) and remove the extra junk.

 

Yeah missed a patch somewhere! I must learn to keep up LOL. Just downloading xcode onto spare hdd then will sort this stuff out. how much junk to remove? down to next endif?

 

BTW I was dynamic on cpu right up to 642 so am not saying anything changed for me. Actually would not mind setting model as MBP 6.1 as I get AGPM then and still have hyperthreading and stepping. How to make it MBP 6.1?

[blackosx]

One thing is for sure; the boot loader is gone and history when the kernel takes over.

Booting without patching ACPI allows me to wake from sleep just fine, it's when I'm patching ACPI that gives me the problem. Still looking in to it...

 

Is this consistent and reproducable? What if you move/swap com.apple.Boot.plist with the one on your hard drive?

I'll come back to that one.

[blackosx]

Something tells me that this is related to FACS (wake/sleep vectors) which you said wasn't picking up.

Maybe..

 

But just been testing without my static DSDT data and have noticed that rev-641 doesn't find /Extra/ACPI/dsdt.aml on my USB, but rev-640 does. Both built using the same private_data.h. And when booting from rev-640 i can wake from sleep again

 

EDIT:

This is far from conclusive. I'll continue testing in the morning to try and nail something down here.

But at the moment I'm testing with the following enabled directives in private_data.h and with rev-640 I can wake from sleep, though rev-641 doesn't find /Extra/APCI/dsdt.aml which results in a KP.

#define ACPI_10_SUPPORT					1
#define PATCH_ACPI_TABLE_DATA				1
#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI			1
#define DROP_SSDT_TABLES				1
#define	APPLE_STYLE_ACPI				1
#define DEBUG_ACPI					1
#define PRE_LINKED_KERNEL_SUPPORT			1
#define USE_STATIC_CPU_DATA				1
#define APPLE_STYLE_EFI					1
#define INJECT_EFI_DEVICE_PROPERTIES			1
#define EFI_64_BIT					1
#define USE_STATIC_SMBIOS_DATA				1

 

Bed time - I'll carry on in the morning.

[DB1]

The patch is attached a few post up. See post #844

 

I did the boot.c debug patch, and the diff in that post, cannot see anything in the diff re disk.c!

[DB1]

I don't get it. It clearly reads disk.c in it, so what are not seeing? Wait. Let me attach it for you.

 

Now you're messing with my head! Here is what's posted there:

diff_cpu_641_642.txt

[DB1]

LOL Not that one. I said: "The patch is attached a few post up. See post #844" and there it is: diff_disk_641_642.txt

 

Oh blimey. Bed time. Yes mom. I'll quite working now. See you gentlemen tomorrow.

 

OK all patched up (now I got the right patches), now on same page as everyone else! Works now without EFI support for SDcard, cannot try on my spare hdd at the moment as I was running it without the bottom cover on the netbook and it overheated during install of xcode and crashed out. Will reformat or clone and try from EFI partition tomorrow. Still cannot get MBP 6.1 though despite your advice, maybe got something wrong somewhere, but it's no big issue as all runs fine as MB4.1. My heads mashed so I'm off to bed. Catch you all tomorrow evening.

 

No doubt another update and plenty headaches to come!

[scrax]

ok but taking off all OC settings in bios, running stock, I should be able to use static cpu info. I can not do this. can any one else with q8300 run static cpu data, and if so please can you tell me what you have in there.

I have the same problem if I use Static CPU Data because DEBUG 1 returns me FSB, and CPU freq in a different way than than one required in private_data and I have not yet found how to convert the value right.

 

In debug I have:

TSCFreq: 2499MHz

FSBFreq: 333MHz

CPUFreq: 2499MHz

 

but using

2499999999ULL

0333333333ULL

2499999999ULL

doesn't work I have too a 7,5 multiplier but debug show me 0x07 for Max and CurrCoef; maybe something is not correct here?

 

Using dynamic cpu data and a lot of different setting I still have the hang when the kernel starts. Now also with -x in c.a.B.p

[scrax]

But that is 24GHz. Please. Have a look at the format (length) I am using: 226 100 000 ULL

Also. System Profiler reports: Bus Speed: 533 MHz (133 * 4) for the HP notebook with the value I use (133 333 333 ULL) and 333 333 333 ULL works for a Quad Core CPU where System Profile reports: Bus Speed: 1.33 GHz (333 * 4) .

 

Now. That should get you started. Right?

Yess thank's I putted a more zero in the TSCFreq, CPUFreq was right instead.

 

EDIT: Now it doesn't reboot anymore with static CPU data

[blackosx]

Good morning DHP and all

This is probably also why it doesn't open/read com.apple.Boot.plist and/or /Extra/ACPI/dsdt.aml anymore.

Just to confirm a bit more about my problem last night, I can use rev-641 to successfully find and load my /Extra/ACPI/dsdt.aml from HDD just not from USB.

 

Here's a screenshot of my ACPI debug booting with the same boot file and files from both USB and HDD.

 

This I guess is the same reason that I end up booting the kernel in 64-bit mode with booting from USB as rev-641 doesn't find my c.a.B.p on it.

 

Screenshot for the debug showing locating (or not) of c.a.B.p.

[GrootWitBaas]

I can boot with static cpu now. Only thing I am not sure is what actual speed I am running, about this mac and geek-bench does not agree on this. O and I still have Bus speed 1.76GHz but it should be 400*4. About this Mac reports a 3,3GHz even with my settings on 2,4. My current setting is below for Q8300

 

#define STATIC_CPU_Vendor      	0x756E6547 	 //Intel
#define STATIC_CPU_Signature   	0x1067a 	//Q8300
#define STATIC_CPU_Stepping    	0xa 		//Stepping 10
#define STATIC_CPU_Model       	CPU_MODEL_PENRYN //Intel® Core(tm)2 Quad CPU Q8300@2.50GHz
#define STATIC_CPU_Family      	0x6 		// 6
#define STATIC_CPU_ExtModel    	0x1 		//1
#define STATIC_CPU_ExtFamily   	0x0 		// 0
#define STATIC_CPU_Type        	0x501   	//1281
#define STATIC_CPU_NoCores     	0x4 		//4 
#define STATIC_CPU_NoThreads   	0x4 		//4
#define STATIC_CPU_Features    	0xbffbfbff  	//
#define STATIC_CPU_CurrCoef    	0x6 		// 6 current setting in bios
#define STATIC_CPU_MaxCoef 	0x7 		// should be 7.5 max setting in bios
#define STATIC_CPU_CurrDiv 	0x1 		// 1  
#define STATIC_CPU_MaxDiv  	0x1 		// 1
#define STATIC_CPU_TSCFrequency	240000000ULL	//2,4GHz
#define STATIC_CPU_FSBFrequency	400000000ULL	//400MHz
#define STATIC_CPU_CPUFrequency	240000000ULL	//2,4GHz
#define STATIC_CPU_QPISpeed	0   		//0

[scrax]

Hi all, can someone tell me how to convert smbios data to a more readable format? I've tried with pasting them in 0xED and save the file as smbios.aml with isal or smbios.hex with EFI Studio without success.

 

I want to check my MBP smbios and also the one dumped from my hack...

[humph]

Running from the new hack here and sleep is fine. Idle sleep doesn't seem to work though but I was told that this was due to the installed CD/DVD-ROM drive (disconnecting it makes idle sleep work).

 

(Not adding in sleep related quotes from blackosx & DB1, to save space!)

 

I've also discovered that auto-sleep (timed, idle sleep) does not work on "641+" or some earlier version(s) (635?) but does work fine on Chameleon RC5 some-version-or-other, perhaps Valv or trunk cant remember what I use there. Can't recall if auto sleep ever worked with Revo here, like others was not really looking out for it, but I tend to think it must have on some or many versions, else I'd probably have noticed at some point.

 

(On 641+) Tried with full dynamic as well as mostly static data. Using "std" kernel (ATOM hacked) not Prelink. But Prelink pack also did not auto-sleep.

 

I think I took most of the static data via a Chameleon boot, so perhaps it's smth bootloader is setting/not setting that's causing difference. But would have to cross-check all the tables etc as not 100% sure. One difference is however CPU detection, took that data via Revo-Debug. Shows in Revo as Core Solo 1.6GHz (nice) vs some 2.0GHz whatever in Chameleon. Anyway, some lengthy multiple reboot & checks needed I guess to see if can narrow down anything. FACS is showing OK (has data bytes).

 

Forced Sleep (PWRB, Lid or Menu) works, as does wakeup.

(Although my USB-eject error is back, in both Cham and Revo..thought I'd nailed that ages ago! )

[GrootWitBaas]

I have a question about 2 comments in private data

 

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

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

 

Should those not read Change this to 1 to statically set the XXX data.

 

Just asking cause I am using this set on 1 with static data and want to make sure I understood correctly.

[blackosx]

I'll attach a new update for disk.c shortly... And here it is. This should take care of the problems. Verified on two different systems with my USB-stick / SD-card and external USB-drive.

Hi dutchhockeypro

 

Thanks for looking in to this and coming up with a fix. I'll try it tonight and report back.

[Time2Retire]

I have a question about 2 comments in private data

 

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

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

 

Should those not read Change this to 1 to statically set the XXX data.

 

Just asking cause I am using this set on 1 with static data and want to make sure I understood correctly.

Correct. Blackosx also mentioned it. Changed it for the next (template) update into:

 

// Set to 0 by default (dynamic data collection). Change this to 1 to use static data.

 

Thanks. Back to school stuff now...

[blackosx]

Thanks for looking in to this and coming up with a fix. I'll try it tonight and report back.

Hi dutchhockeypro

 

All systems go booting from USB with the new disk.c. Well done with the fix

My /Extra/ACPI/dsdt.aml is now loaded which means my wake from sleep dsdt fix is now back.

The c.a.B.p is correctly loaded and I can boot the kernel in 32-bit mode again.

[DB1]

Correct. Blackosx also mentioned it. Changed it for the next (template) update into:

 

// Set to 0 by default (dynamic data collection). Change this to 1 to use static data.

 

Thanks. Back to school stuff now...

 

this was something else I must have missed, no wonder I could not get static cpu right. It is now. The new Boot.c works ok for me on SDCard, will try on my spare hdd EFi when I sort it out later this evening. No sleep issues.

 

Still a minor issue with ram detection: