How to boost the OS X boot process...

[Time2Retire]

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.

Good evening Blackosx,

 

All systems go. Phew. Next

[GrootWitBaas]

Can someone PLEASE post the latest they have (fully patched) I have messed up my one drive and need to get it up to date.

[DB1]

Please note that I included two blocks with a call to HFSProbe() in it. When everything works for you, then start by changing the 2048 (two times) into 1024 and later on into 512 respectively (for both lines the same value).

 

And when this works for you, then comment the active block out, and try the second one in function probeBVRef. Which is where I want it to be when you confirmed it to work.

 

Had to add #define EFI_BOOT_PARTITION_SUPPORT 1 in private_dat.h to get a boot from EFI partition, then tried values, 2048, 1024, 512. 2048 is the right value. Commented out the active and activated the probeBVRef and working fine.

 

Can the private_data.h call to EFI come out or does that need to stay?

 

BTW nicely set up for the test DHP - genius

 

Will sort the other stuff now.

 

Can someone PLEASE post the latest they have (fully patched) I have messed up my one drive and need to get it up to date.

 

Here you go mate: Revolution_642_EFImodtodiskc.zip

 

Dont forget to change the private data.h

[GrootWitBaas]

your a star thanx

 

Can we run any .efi application from Revolution ? for example can we run shell.efi seeing if I understand correctly we call "\\System\\Library\\CoreServices\\boot.efi" right ? or are we only mimicking it ?

[blackosx]

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

DHP - You're right here.

I added #define STATIC_FACS_TABLE_INJECTION 1 to private_data.h and doing so causes my machine to fail to wake from sleep.

[scrax]

Hi all,

I divided my post by arguments so it will be more easy to find in future..

 

SMBIOS parser

For the smbios converter I found some SMBIOS.bin from mac that have been parsed and looks like it is done with "dmidecode" on linux.

Attached the parsed.txt:

SMBIOS_parsed.txt

If this works I think that this dmidecode was the program we were looking for, isn't it?

 

EFIString conversion

I don't know how to convert my EFI string in the format for Revolution

To make the conversion for my dev prop plist I used this site but I don't know if could be used with the efi string

 

DSDT Reduction help

In this days after the DHP comment about my DSDT ( ) I made some homeworks and I reduced the original one from 30200bytes to a 2500bytes DSDT moving almost all the injections to an EFI string that works great.

But I can't get rid of ALL the injections because I have not yet figured out how to correctly inject this Method (_DSM:

			Device (EHC2) {Name (_ADR, 0x00060001)
			Name (_PRW, Package (0x02) {0x17,0x03})
			Method (_DSM, 4, NotSerialized) {Store (Package (0x07) {  //EHC2 FIX
						"AAPL,current-available", 0x05DC, 
						"AAPL,current-extra", 0x044C, 
						"AAPL,current-in-sleep", 0x09C4, 
						Buffer ( One) {0x00} }, Local0)
				Return (MCDP (Arg2, RefOf (Local0))) } }

Using this don't works:

	<key>PciRoot(0x0)/Pci(0x6,0x1)</key>
<dict>
	<key>AAPL,current-available</key>
	<integer>1500</integer>
	<key>AAPL,current-extra</key>
	<integer>1100</integer>
	<key>AAPL,current-in-sleep</key>
	<integer>2500</integer>
</dict>

here the ioreg results with the patch applied with dsdt (working)

When also this patch is in EFI the DSDT will be nearly 2200bytes because it will no more need the MCDP method too.

EDIT: I'v done with this method

 

If someone wants to give a quick look at the new "less-than-200-lines-that-make-me-proud" dsdt it's posted here: http://www.insanelymac.com/forum/index.php...t&p=1636599

there are also my c.a.B.p and my smbios.plist for chameleon

 

Revolution State

my c.a.B.p for Revolution now has only -x in it, no UUID needed, without -x can't pass the hang at kernel load.

[humph]

If someone wants to give a quick look at the new "less-than-200-lines-that-make-me-proud" dsdt it's posted here:

Hi scrax,

Well this may be a bot off topic, but I wonder if you would be prepared to provide additional details, either here or on some other post?

 

The best I can understand is that you've used the PCI device merge approach to offload many of the DSDT injections to a kext (EvOReebot in your case, or AndyV's dedicated kext) - which looks somewhat complex but I guess is not too hard to figure out when you actually get into it. But also some other stuff (SATA, LPCB etc) as EFI. Can't get my head around how even start going about the EFI stuff (other than what we've done so far which is to grab the "GFX" EFI from IOReg and remove GFX from DSDT). But the other stuff, HDEF, SATA etc leaves my head buzzing!

[humph]

Should be easy with the examples I've put up here some time ago. Here's a starter; get EFI-Studio

Ermmm, well I see how to handle & convert plist stuff like:

#if STATIC_SSDT_USB_TABLE_INJECTION
#define STATIC_SSDT_USB_TABLE_DATA \
/* 0x0000 */	// Insert your SSDT_USB table data here (optional).

But didn't think that became EFI injected - is this just a terminology thing ("EFI" vs "SSDT").

Anyway, can I in principle use this flag for eg. SATA (I have SSDT for SATA as well as PR - although I know it's possible that I wont need to inject any of the extra details from SSDT or DSDT over a basic Device/Name/Addr in DSDT to get OSX to work, need to test).

But EFI studio does not seem to grab correct info for HDEF (as in the info it generates is not same as I see in IORegExp). OK I should just go test, I guess...

[blackosx]

The revised ACPI patcher sounds interesting, well done. I look forward to seeing it in a future update.

[humph]

I'll also attach what I am using right now. Shouldn't change too much anymore. Gives you an idea of what I have in mind for the future. Let me know what you think.

Hi DHP. Looking interesting! So, one thing new I saw in the private data template was SSDT-SATA thing, also general drop/replace SSDT flags. This goes back to my garbled question above about handling SSDTs that are not explicitly for GPU or PM...edit. Just typed a load more garbage, deleted that.....So I guess I'm asking....how is it intended for Revo to handle SSDT replacement (changes from what's in BIOS), or even addition (if wanting to add something not even in BIOS), or drop, or perhaps even combination of all these scenarios?

 

P.S. Still battling with getting Audio, WiFI etc _DSM injection as EFI working (the working bit, injecting useless numbers is easy!). But thank you for the info. Taking a day off to see if an understanding somehow sunk into my sub-conscious.

[DB1]

I'll also attach what I am using right now. Shouldn't change too much anymore. Gives you an idea of what I have in mind for the future. Let me know what you think.

 

Tried this before work this morning (before the new private data template attached) and it worked fine, have just downloaded and updated the private data file and now get compile error:

 

In file included from cpu.c:23:
cpu/dynamic_data.h: In function ‘initCPUStruct’:
cpu/dynamic_data.h:244: error: ‘CPU_VENDOR_INTEL’ undeclared (first use in this function)
cpu/dynamic_data.h:244: error: (Each undeclared identifier is reported only once
cpu/dynamic_data.h:244: error: for each function it appears in.)
make[2]: *** [cpu.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

 

Setting private_data.h to #define USE_STATIC_CPU_DATA 1 compiles ok. Seems something not right with static data inclusion.

[DB1]

Weird. CPU_VENDOR_INTEL (and CPU_VENDOR_AMD) are defined in cpu/essentials.h like so:

#define CPU_VENDOR_INTEL	0x756E6547
#define CPU_VENDOR_AMD		0x68747541

You don't have this anymore?

 

No it's not with the Experimental you posted

[DB1]

Shouldn't be part of acpi/essentials but cpu/essentials.h Just add it when you don't have it. Have hockey training. Be back later.

 

What I meant was I made up experimental with 642 and it appears I did not have it there either. Checked back and it was in 641, so i don't know what happened there. All right now I added back in.

 

Also made a couple of adjustments in cpu/dynamic_data.h.

 

gPlatform.CPU.Type = 0x201; // db1 changed from 301 for Atom

 

if (gPlatform.CPU.Family == 0x06 && (gPlatform.CPU.Model == CPU_MODEL_NEHALEM || gPlatform.CPU.Model == CPU_MODEL_FIELDS ||

gPlatform.CPU.Model == CPU_MODEL_DALES || gPlatform.CPU.Model == CPU_MODEL_DALES_32NM ||

gPlatform.CPU.Model == CPU_MODEL_WESTMERE || gPlatform.CPU.Model == CPU_MODEL_ATOM )) // db1 added Atom

[blackosx]

I'll also attach what I am using right now. Shouldn't change too much anymore. Gives you an idea of what I have in mind for the future. Let me know what you think.

I've tested with the new experimental files and I can boot successfully with them. Good work DHP

 

You'll find it bootup quicker. It's only like ~750ms quicker, but that's still 3/4 of a second – ran a number of tests after I noticed that the throbber shows up quicker. Me likes it.

mmm I'm not seeing this. At the moment booting from USB, it takes 28.3 seconds before I see the throbber. I'll run some debug and see what i can find.

 

EDIT: - Let me re-check my settings as this could be my error!!

 

EDIT: Here's a debug output of that particular boot. (though not all debug directives enabled).

 

[DB1]

As long as it works.

 

And without your changes it doesn't work for your Atom?

 

Yeah works sweet for me. The adjustments allow about this mac and hardware overview show core solo rather than core 2 which I've not had yet.

 

One odd thing i've noticed is in Platform.c section of private_data.h is if I set to static smbios the ram settings I have set there dont show in system profiler, but if i do dynamic they do is this whats expected?

[blackosx]

Hmm. You have three calls to diskScanGPTBootVolumes. Should be two only.

I think three is correct.

diskScanGPTBootVolumes(128) is for my HFS+ partition on the USB flash drive.

diskScanGPTBootVolumes(129) is for my EFI, HFS+, HFS+ partitions on HDD 1.

diskScanGPTBootVolumes(130) is for my EFI, HFS+, HFS+ partitions on HDD 2.

 

Can be anything of course...

Yeah I know, but i still can't work it out.

Booting from HDD is nice an quick, but I can't seem to get my USB booting quickly.. I've tried my previous boot file before the experimental version, re-copied Extensions.mkext, pre-linked kernel, c.a.B.p, double checked ownership/permissions, and it's still slow, I'm missing something obvious but I'm tired so I'll retry it tomorrow.

 

Bed time for me as I have to be at work early tomorrow. Keep up the good work everybody

[scrax]

But EFI studio does not seem to grab correct info for HDEF (as in the info it generates is not same as I see in IORegExp). OK I should just go test, I guess...

 

I've made this screenshot to try to explain what I did to move the HDEF Method _DSM from DSDT into a Legacy kext (after the EFI way I found more interesting this one so now all the audio patch is done with a dummy kext).

The ioreg is saved with HDEF working with DSDT inj. The blue value are the one we want to merge to ioreg with the legacy kext or EFI string.

Making an EFI string is easiest because you only need the name of the device were you want to put the data ES. Device (HDEF) and then you can use EFIStudio to get the PCI path

SO to have it in a EFI string format only the IOProviderMergeProprieties Dictionary is needed but you need to change the name to the HDEF PCI path

For mine: PciRoot(0x1)/Pci(0x8,0x0) instead of IOProviderMergeProprieties in the default EFI plist

 

(After many test I can't use the DeviceMergeNub method with GFX and SATA so they are still in a EFI format)

[humph]

Making an EFI string is easiest because you only need the name of the device were you want to put the data ES...

Scrax, thank you for the info. Well it got my brain sorted.

And thank you to DHP for earlier encouragement.

 

I've now got EFI DP for GFX, HDEF and ARPT(WiFi) - all the DSM's in my DSDT.

 

My mistake was that of just adding the "additional" hex numbers to the end of the existing DP table. Soon as I remade the new table from a new .plist with all relevant devices and used those numbers, it all worked.

BTW, it'd be nice if Revolution could handle just a long string of EFI DP numbers (or have a little converter app) as it took ages and imminent RSI to reformat the long numbers into 0xAA, 0xBB etc for inclusion in private_data.h!

 

Also, I made slight edit to aml2struct.pl to add the "\" at end of lines for DSDT conversion:

	  if (($index % 32) == 0)
  {
	$str .= "\\\n\t";
  }

 

EDIT: Here's the complete file...aml2struct_mod.pl.zip

[humph]

Would you mind attaching it here? This way more people have access to it (without having to go through tons of posts first). Thanks.

Added to orignal post above..

[GrootWitBaas]

A ok lots of things to download and test ....

[DB1]

I said to be working on this... and so I did. Attached is a proper fix for CPU speed/detection. Please give it a try. Thanks.

 

 

You see; two downloads already. Thanks

 

Works ok for me, cpu reporting correctly in about this mac, and system profiler, can set macbook4.1 or macbookpro6.1. only minor issue is if I do dynamic cpu & smbios I get mac mini 2.1 & core 2 solo but memory (apart from size) comes through as is set in private_data.h, if I do static everything ok except one memory module does not report manufacturer, part no, and serial no. Not overly concerned.

 

My ram always shows in about this mac 2Gb (2 x1Gb) which is correct but in system profiler/memory it is 32mb and always ever has been with Chameleon or Revolution. It's no big deal but for completeness if you can capture memory size why not. I tried adding #define STATIC_RAM_SIZE SMB_MEM_SIZE_1GB in private_data.h and //==============================================================================

 

static int getRAMSize(void)

{

return STATIC_RAM_SIZE;

}

 

in smbios/dynamic_data.h but got the old first use error on compile - don't really know what i'm doing but i thought worth a try.

 

Overall though I'm 10 seconds faster than Chameleon on my EFI partition spare hdd set up so the work you done so far great stuff, thanks for your hard work.

 

Another advantage i've seen over Chameleon is at wake after sleep, I used to have erratic mouse or trackpad activity until the wifi reconnected uo to about 30 seconds to a minute, Revolution connects within 5 seconds with no erratic mouse / trackpad {censored}.

 

Have hacked away further at my dsdt (now 8kb) to get rid of the DSM stuff and have managed to make a hex file so working toward making some more improvements, a few more seconds off maybe!

 

Catch up tomorrow, great work DHP.

[GrootWitBaas]

If there's anything that must be fixed for the next release, then please say so as I want to wrap it up and release a new update later this week end. Now going to bed. See you in a few hours from now...

 

All working for me, looking forward to a full release to have every thing back up to date. Happy to see alot of progress :pirate2:

[blackosx]

I said to be working on this... and so I did. Attached is a proper fix for CPU speed/detection. Please give it a try.

Hi dutchhockeypro

 

Sorry I wasn't around much to test yesterday, but I have caught up here now.

I've taken the three revised files you posted, made the fix to function getCPUtype, and added the declarations for CPU_VENDOR... as DB1 posted which allowed me to successfully compile.

 

Booting using my static data works fine, but I thought I'd test using dynamic CPU and SMBIOS data as this is what's changed. When using the dynamic CPU, the debug info show during boot is correct and is what I have been using for my static data.

and is what I see once booted and type sysctl -a | grep cpu

hw.ncpu = 2
hw.cpufrequency = 898196224
hw.availcpu = 2
hw.ncpu: 2
hw.activecpu: 2
hw.physicalcpu: 2
hw.physicalcpu_max: 2
hw.logicalcpu: 2
hw.logicalcpu_max: 2
hw.cputype: 7
hw.cpusubtype: 4
hw.cpu64bit_capable: 1
hw.cpufamily: 2028621756
hw.cpufrequency: 26668000000
hw.cpufrequency_min: 26668000000
hw.cpufrequency_max: 26668000000
machdep.cpu.max_basic: 10
machdep.cpu.max_ext: 2147483656
machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Intel® Core(tm)2 Duo CPU     E7300  @ 2.66GHz
machdep.cpu.family: 6
machdep.cpu.model: 23
machdep.cpu.extmodel: 1
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 6
machdep.cpu.feature_bits: 3219913727 582557
machdep.cpu.extfeature_bits: 537921536 1
machdep.cpu.signature: 67190
machdep.cpu.brand: 0
machdep.cpu.features:  FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM SSE3 MON DSCPL EST TM2 SSSE3 CX16 TPR PDCM SSE4.1
machdep.cpu.extfeatures:  SYSCALL XD EM64T LAHF
machdep.cpu.logical_per_package: 2
machdep.cpu.cores_per_package: 2
machdep.cpu.microcode_version: 1548
machdep.cpu.mwait.linesize_min: 64
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.sub_Cstates: 139808
machdep.cpu.thermal.sensor: 1
machdep.cpu.thermal.dynamic_acceleration: 0
machdep.cpu.thermal.invariant_APIC_timer: 0
machdep.cpu.thermal.thresholds: 2
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.arch_perf.version: 2
machdep.cpu.arch_perf.number: 2
machdep.cpu.arch_perf.width: 40
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.events: 0
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.fixed_width: 40
machdep.cpu.cache.linesize: 64
machdep.cpu.cache.L2_associativity: 6
machdep.cpu.cache.size: 3072
machdep.cpu.tlb.inst.small: 128
machdep.cpu.tlb.inst.large: 8
machdep.cpu.tlb.data.small: 16
machdep.cpu.tlb.data.small_level1: 256
machdep.cpu.tlb.data.large: 16
machdep.cpu.tlb.data.large_level1: 32
machdep.cpu.address_bits.physical: 36
machdep.cpu.address_bits.virtual: 48
machdep.cpu.core_count: 2
machdep.cpu.thread_count: 2

 

However, System Profiler shows

 

and About This Mac shows:

 

Have I forgotten to make any changes at my end, or is this an issue with the code?

 

p.s. I'll be working for most of today, so I'll check in when I can.

[DB1]

Hi DB1,

 

Seem like your Atom isn't recognized as Mobile CPU. Now the big question is if this was working for you previously. I may have to change something for this to work properly. What brand string do you get with DEBUG_CPU enabled?

 

 

Ah yes. This static memory detection bug was something I planned to fix for this release. Let me give it a try.

 

 

SMB_MEM_SIZE_1GB should show up as undefined. I'll also check if we can add memory size. Would be cool. Yes. This can be done, but we will have to figure out what values to use. The SMBIOS specification only talks about: 0x0000 for when no module is installed, 0x8100 for a 256 KB module and 0x100h for a 256 MB module. Oh and 0xffff for when the size is unknown. FIXED

 

Verified to work with fake values for: 1, 2, 4, 8 and 16 GB modules (32 GB not working on the HP).

 

 

Good to hear that. And I've said this before but I do it once again; We will toggle the load switch in the upcoming release (6.43) and you got to see a jump start from USB-stick and SD cards, as it will improve the load factor by 10-35.

 

 

Wow. So I wasn't dreaming – my keyboard was non-responsive (with Chameleon) the first couple of seconds.

 

 

The smaller the file the better. Static DSDT injection is even better.

 

p.s. Do you have a BIOS setting to enable C4? If yes then please attach a CPU debug dump with C4 enabled and disabled. Otherwise one will do. Need to know what this: msr(n): platform_info shows. Can't do anything without this info.

 

Hi DHP, you're right cpu not recognised as mobile here's the debug.

Brand string looks ok to me.

 

Good you fixed the memory size, expect will be in next release. Look forward to the speed leap on the SD/USB mine seems to lag quite a bit. I have static dsdt alreaady, just playing now with device properties efi to take out DSM's.

 

Dont have a C4 setting, the MSI Wind/Advent 4211 has a very, very, very basic bios. there is an msr output on the cpu debug, not sure if thats what your looking for.

[blackosx]

Hi DHP

 

Just to recap: booting using my static data works great with these new updates you've released, I was just questioning the results of experimenting with dynamic data.

 

Anyway. Im post #924 I said: "When your CPU speed is displayed wrong with this change, then you need to adjust the (static) values in private_data.h" so yes you need to update your static data accordantly. This is what I am using for the HP:

#define STATIC_CPU_TSCFrequency				2266000000ULL

#define STATIC_CPU_FSBFrequency				133300000ULL

#define STATIC_CPU_CPUFrequency				2266000000ULL

A bit shorter so to speak. I'm sure you get it sorted.

I don't understand.. Why do I need to change my static CPU data to correct the result of the dynamic CPU setting?

 

And dynamic data appears to be a factor 10 of what it should be. I'll look into it before releasing a new update. Thanks! FIXED

With the new files in post #945, using the dynamic CPU setting, System Profiler still shows my Processor Speed as 26.67 GHz as reported in post #942