Jump to content

Chameleon RC5 mode with mem detection enabled and automatic P-States & C-States generation for native power managment


kozlek
 Share

1,214 posts in this topic

Recommended Posts

Great Work mojodo !

 

Thanks especially for fixing the system profiler problem happening on few systems, I couldn't figure that alphas-digits-only-char-allowed problem :)

 

We could improve the memory detection speed as well, by reading only the headers instead of a full spd page and finally read it only when a slot is not empty.

 

I wanted to improve that myself after my first mem detect impl., but found a (great) new job sucking all my development time & energy right now :)

 

Keep on the good work !

 

-Rek

 

Thank you for your work! Mem detect works great on my mobo. I've figured out Sysprofiler problem by chance, looking on mem partno on some boards like P4837H8456 and mine didn't worked with "-" chars in name. And speed improvement would be cool :)

Link to comment
Share on other sites

You need to DropSSDT or not to use GenerateCStates feature.

Hi Mozodojo.. it works - Fantastic :)

 

After reading your post again along with the source code, I realised for all my attempts I hadn't added the GenerateCStates and GeneratePStates boot options to c.a.B.p. Maybe you could update your opening post to mention they are required to activate the functionality?

 

Top job

Link to comment
Share on other sites

@mozodojo

Great work! :thumbsup_anim: I was reading this thread since the beginning and i'll definitely compile and test your mozodojo-chameleon, will report in order to improved it further. Currently I'm booting my system with valv's AnVal chameleon (AnVAL5 pre release) and i report its behavior when there's a new build.

 

I have just one small but important recommendation to all the programmers here: Please take some time to explain and document the new features, boot keys, etc. on how to implement and test the new build, version. It'll be definitely very handy not only for programmers but for rest people -- this way more quality input could be gained, according to me :)

 

@Rekursor

I'm glad to see you here joining forces with the rest again:) It's great you're back :)

 

mozodojo, valv, Rekursor, again top job, guys :thumbsup_anim:

Greets and thanx for your time spending on developing Chameleon

Link to comment
Share on other sites

Hi Mozodojo.. it works - Fantastic :thumbsup_anim:

 

After reading your post again along with the source code, I realised for all my attempts I hadn't added the GenerateCStates and GeneratePStates boot options to c.a.B.p. Maybe you could update your opening post to mention they are required to activate the functionality?

 

Top job

 

Wow! I forget to say about boot options! Thank you, already added short description :thumbsup_anim:

Link to comment
Share on other sites

Wow! I forget to say about boot options! Thank you, already added short description :thumbsup_anim:

Great. That'll hopefully help a few others. You code is working jut fine here now :thumbsup_anim:

 

p.s., Hi Rekursor - good to hear you're still alive and well (I know you've been busy).

Link to comment
Share on other sites

Q: What is usage for DropSSDT ?

If i remove my PStates / Cstates from DSTD.aml to test it, must i add DropSSDT=Yes or can i leave my boot.plist without hat key ? I dont have SSDT.aml files.

(Thanks adding usage of GenerateXYZ keys)

Link to comment
Share on other sites

Q: What is usage for DropSSDT ?

If i remove my PStates / Cstates from DSTD.aml to test it, must i add DropSSDT=Yes or can i leave my boot.plist without hat key ? I dont have SSDT.aml files.

(Thanks adding usage of GenerateXYZ keys)

You need DropSSDT if your motherboard's original SSDT has P/C-States.

Link to comment
Share on other sites

Thanks mozodojo :)

 

testing devices: E2180, 945GCM-S2L, memory DDR2 667

 

added these to com.apple.Boot.plist, no SSDT.aml and so on in /E

 

<key>GeneratePStates</key>

<string>Yes</string>

<key>GenerateCStates</key>

<string>Yes</string>

<key>DropSSDT</key>

<string>Yes</string>

 

cpu section in DSDT;

 

Scope (_PR)

{

Processor (CPU0, 0x00, 0x00000410, 0x06) {}

Processor (CPU1, 0x01, 0x00000410, 0x06) {}

}

 

see the result;

post-93383-1279794989_thumb.jpg

 

Only one problem right now is that reported system memory @ 800 MHz.

 

I will post my other devices tonight.

Link to comment
Share on other sites

cpu section in DSDT;

	Scope (_PR)
{
	Processor (CPU0, 0x00, 0x00000410, 0x06) {}
	Processor (CPU1, 0x01, 0x00000410, 0x06) {}
}

 

tmongol, i was wondering whether this is your whole _PR scope you use with the mozodojo-chameleon? thanx in advance :(

Link to comment
Share on other sites

zef

 

Thanks zef. And one more thing though, "About This Mac" shows my CPU (Quad Core) as UNKNOWN. It was working/detecting before you merge mozodojo's patch.

 

Where is some problems with CPU detection after I've integrated valv's CPU type injection code. Need more testers and reports to fix it. So Quad Core is not detected or information for injection was incorrect. Will check it later.

Link to comment
Share on other sites

Hi mojodojo

 

Still no joy I'm afraid.

Have just tried rev 352 of the trunk. Added GenrateCStates=Yes to boot.plist and tried with and without DropSSDT (There are no _CST data in my SSDT!).

 

Also tried above combinations with and without CPU Alias in Scope _PR.

 

EDIT - CPU still detected as Xeon, same as ever.

 

Cheers

D

Link to comment
Share on other sites

Hi mojodojo

 

Still no joy I'm afraid.

Have just tried rev 352 of the trunk. Added GenrateCStates=Yes to boot.plist and tried with and without DropSSDT (There are no _CST data in my SSDT!).

 

Also tried above combinations with and without CPU Alias in Scope _PR.

 

EDIT - CPU still detected as Xeon, same as ever.

 

Cheers

D

 

try to use "Wait"="Yes" option in boot.plist to check chameleon log. I need some debug information from it. Maybe SSDT patcher didn't found CPUs in DSDT. Where is knowing bug in CPU name detection algo. I'll fix it later.

Link to comment
Share on other sites

tmongol, i was wondering whether this is your whole _PR scope you use with the mozodojo-chameleon? thanx in advance :blink:

Yes, i think so.

 

 

 

@mozodojo

 

My Q9400 was Unknown in "About This Mac."

Chameleon r352.

Link to comment
Share on other sites

One question:

 

To enable native power management you should use proper mac model + HPET enabled.

 

But my BIOS contains no HPET, I manually add HPET, but got probeHPET() failed in kernel log. Can I still use this bootloader to enable native power management?

Link to comment
Share on other sites

Blimey.. I have just downloaded and built r201 and was going to report my success and now r202's out! I'll go and do it again! :thumbsup_anim:

 

Keep up the fast dev work guys.. it's great to see.

 

EDIT: r202 is working wonderfully.

 

EDIT: Question.. When I ran with my DSDT patched with _PSS / _CST data, and followed mm67's help from this post, entering setpci -s 0:1f.0 0xa6.b returned 80, but at the moment that command returns 00?

 

Also VoodooMonitor shows a drop to the lowest multiplier but only occasionally shows a voltage (1.116V) below my lowest P-State (1.132V) which I have been used to seeing often.. Are my C-States working effectively? I'll do some further tests.

 

EDIT: Well, rebooting with my patched DSDT with _PSS / _CST data, with r202, without the GeneratePStates / GenerateCStates boot options allows the above setpci command to return 80 and VoodooMonitor shows the lowest multiplier with a voltage of (1.116V) all the time while typing this. I'll extract the ACPI tables and see what I can find.

 

EDIT: Having looked at the _CST information, there is a difference which will probably explain what I am seeing.

The CST data from my DSDT which was from mm67's code, which returns 80 from the setpci command.

[size=2]Name (CST, Package (0x04)
{
	0x03, 
	Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x000,)},0x01,0x01,0x03E8},
	Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x010,)},0x02,0x01,0x01F4},
	Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x030,)},0x04,0x39,0x064}
})[/size]

The CST data I get from Mozodojo's automated generator, which returns 00 from the setpci command.

[size=2]Name (CST, Package (0x04)
{
	0x03, 
	Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x000,1)},0x01,0x01,0x03E8},
	Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x010,1)},0x02,0x5A,0x01F4},
	Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x020,1)},0x03,0x0384,0x015E}
})[/size]

I see the following data in my FACP which I think is where the auto generator code gets it's data from:

 
C2 Latency : 005A
C3 Latency : 0384

So I guess the CST data I have from the auto generator is correct as far as best determining what can be found on my boards' ACPI tables. And if I remember correctly, I think mm67 got the code shown above from his MSI board and not a Gigabyte board? So in which case there would be no way for that code to be automatically generated..

 

Ah, well. I guess I have answered my own question here.. and anyway, I am happy with the fantastic results I get from the Mozodojo code. So again.. great job :blink:

Link to comment
Share on other sites

This is really cool stuff. I just tried it out but got Memory Allocation error on boot. I built the source with xcode and replaced the boot file in my / directory. Are there other files I need to copy as well?

Link to comment
Share on other sites

This really cool stuff. I just tried it out but got Memory Allocation error on boot. I built the source with xcode and replaced the boot file in my / directory. Are there other files I need to copy as well?

 

What revision gave you the memory allocation error?

Link to comment
Share on other sites

 Share

×
×
  • Create New...