Jump to content

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

kozlek

By kozlek,
in Chameleon

 Share
1,214 posts in this topic

Recommended Posts

Taruga
Taruga
Posted
Posted
Hi All

 

Re: Audio stutter and C-States

 

Please see d00d's post #283 here

 

D

 

 

Thanks

 

 

After reading for a while and testing I fixed my problem. Now I have GenerateCStates=Yes with no sound stuttering and the only thing I did was to change my dsdt from this:

		Device (TMR)
			{
				Name (_HID, EisaId ("PNP0100"))
				Name (ATT5, ResourceTemplate ()
				{
					IO (Decode16,
						0x0040,			 // Range Minimum
						0x0040,			 // Range Maximum
						0x00,			   // Alignment
						0x04,			   // Length
						)
					IRQNoFlags ()
						{0}
				})
				Name (ATT6, ResourceTemplate ()
				{
					IO (Decode16,
						0x0040,			 // Range Minimum
						0x0040,			 // Range Maximum
						0x00,			   // Alignment
						0x04,			   // Length
						)
				})
				Method (_CRS, 0, NotSerialized)
				{
					If (LGreaterEqual (OSFX, 0x03))
					{
						If (HPTF)
						{
							Return (ATT6)
						}
						Else
						{
							Return (ATT5)
						}
					}
					Else
					{
						Return (ATT5)
					}
				}
			}

 

to this:

				Device (TIMR)
			{
				Name (_HID, EisaId ("PNP0100"))
				Name (_CRS, ResourceTemplate ()
				{
					IO (Decode16,
						0x0040,			 // Range Minimum
						0x0040,			 // Range Maximum
						0x00,			   // Alignment
						0x04,			   // Length
						)
				})
			}

 

 

EDIT: Oh... and Sleep is working fine now.

Link to comment
Share on other sites
edgar87
edgar87
Posted
Posted

Why are my P-States not generated?

 

chameleon.jpg

 

I'm using the following boot.plist and smbios.plist:

	<key>Boot Banner</key>
<string>No</string>
<key>DSDT</key>
<string>/Extra/DSDT.aml</string>
<key>DropSSDT</key>
<string>Yes</string>
<key>GenerateCStates</key>
<string>Yes</string>
<key>GeneratePStates</key>
<string>Yes</string>
<key>Graphics Mode</key>
<string>1680x1050x32</string>
<key>GraphicsEnabler</key>
<string>No</string>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>arch=i386</string>
<key>SMBIOS</key>
<string>/Extra/smbios.plist</string>
<key>SystemId</key>
<string>00000000-0000-1000-8000-REMOVEDBYME</string>
<key>Theme</key>
<string>Default</string>

 

	<key>SMserial</key>
<string>W89REMOVEDBYME</string>

 

I'm using the system in my sig.

Link to comment
Share on other sites
SilentViper
SilentViper
Posted
Posted

I haven't seen this anywhere in this thread yet, yes i have searched and read

 

I am having problems with GraphicsEnabler and my ATI 4850

 

when I boot with GraphicsEnabler=Yes I get a gray screen. I can boot into Safe mode and get a GUI

 

I don't have these problems with other bootloaders or even other versions of this bootloader (RC5 Pre8) [i wanted this bootloader for the speedstepping].

 

Thanks in Advance

 

- SilentViper

Link to comment
Share on other sites
kozlek
kozlek
Posted
  • Author
Posted

Im not sure if P/C-states generation really needed for newer CPUs & Mobos. You always can dump your SSDT and edit, if you wish. You can load SSDT.aml like DSDT. Also, you can add up to 30 custom SSDTs (SSDT.aml, SSDT-1.aml ... SSDT-29.aml). New mobos (with core ix) usually generate all necessary info for OS.

Link to comment
Share on other sites
ErmaC
ErmaC
Posted
Posted
Im not sure if P/C-states generation really needed for newer CPUs & Mobos. You always can dump your SSDT and edit, if you wish. You can load SSDT.aml like DSDT. Also, you can add up to 30 custom SSDTs (SSDT.aml, SSDT-1.aml ... SSDT-29.aml). New mobos (with core ix) usually generate all necessary info for OS.

 

Hi mozodojo

 

I will do some test on my confing.

"repack" the old stuff present in the DSDT (Scope _PR) and make a new SSDT as you suggest...

in my case the "CPU" name is the problem (original is P00x...), I will see if the name match with it changing the name in the SSDT too...

 

Fabio

Link to comment
Share on other sites
Trauma!
Trauma!
Posted
Posted
Im not sure if P/C-states generation really needed for newer CPUs & Mobos. You always can dump your SSDT and edit, if you wish. You can load SSDT.aml like DSDT. Also, you can add up to 30 custom SSDTs (SSDT.aml, SSDT-1.aml ... SSDT-29.aml). New mobos (with core ix) usually generate all necessary info for OS.

 

+1. All we need for those platform is a correct CPU recognition... nothing more.

Link to comment
Share on other sites
ErmaC
ErmaC
Posted
Posted
...

 

I confirm.

works using the extra SSDT tables (propely patched for match with renamed cosmetics name CPU)

 

Anyway thank's all here for this amazing job!

 

Fabio

 

just a suggestion... if is possible to add this info/stuff for smbios_patcher?

[b]// defaults for a Mac Pro 4,1 core i5/i7/Xeon
static const SMStrEntryPair const sm_macpro_defaults[]={
{"SMbiosvendor",	"Apple Computer, Inc."		},
{"SMbiosversion",	"MP41.88Z.0081.B04.0903051113"	},
{"SMbiosdate",		"11/06/2009"			},
{"SMmanufacter",	"Apple Computer, Inc."		},
{"SMproductname",	"MacPro4,1"			},
{"SMsystemversion",	"1.0"				},
{"SMserial",		"SOMESRLNMBR"			},
{"SMfamily",		"MacPro"			},
{"SMboardmanufacter",	"Apple Computer, Inc."		},
{"SMboardproduct",	"Mac-F4208DC8"			},
{ "",""	}
};[/b]

 

Fabio

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

I've extracted RC5 rev 300 from the installer provided earlier in the thread (grazie iFabio!) and installed it manually. I was using AsereBLN 1.1.9 before.

(/Edit - now on rev 318)

 

I removed the P- and C-state code from my DSDT (I had 4 P-states and at least C1E working) and gave the CPU declarations their old names back (I had changed them to CPU0 and CPU1) so as to match the declarations in SSDT. I set DropSSDT, GenerateCStates and GeneratePStates=y.

 

I got these good old messages on boot, it's been a long time since I've seen them :blink: :

 

ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed

ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

 

ICH10R LPC dev ID (3a18 -> 3a16) is patched via DSDT and it loads, look:

LPC.png

This is how SMC_PlatformPlugin looked in ioreg before (note CSTinfo):

ACPI_SMC_Platformplugin_before.png

Now it looks like this:

ACPI_SMC_Platformplugin_after.png

I got 8 P-states - but lost C-states!

Memory detection is flawless and my hardware UUID stayed the same as the one set by AsereBLN 1.1.9.

Performance is like it was before, no audio stuttering and temps are fine, just below 40 degrees celcius at idle and hovers around 50 under full load.

 

Motherboard is Asus P5Q-E (P45/ICH10R), CPU is a stepping E0 Core 2 Duo E8500 that supports up to C4E. The BIOS has two C-state settings, C1E and 'Intel C-State Tech", both are enabled. I use iMac9,1 model identifier. Here's the C-state bits from the FACP table, looks like up to C3E is supported by the motherboard:

 

[05Fh 0095 1] _CST Support : E3

[060h 0096 2] C2 Latency : 0065

[062h 0098 2] C3 Latency : 03E9

 

And here are the two SSDT tables that contain the C-state data: P5QE_E8500_Cstate_SSDT.zip

If anyone can help me get C-states working (or just C1E) with this bootloader that would be great.

Meanwhile I'll try loading those two SSDTs and see what happens.

/EDIT

No, that didn't work - still getting the CST/LPC error messages. I can see the tables get loaded when booting with Wait=y.

I tried adding all 5 SSDT tables but there's no change.

I know I could probably put back the C-state code in DSDT but what's the fun in that.

 

/EDIT

 

I fixed it!! lolwut

 

My motherboard's unmodified DSDT declares four CPU cores. I had taken out the code for the two cores that I don't have (and removed the aliases, couldn't boot with them in) it was easier to work on speedstepping via DSDT that way, less code to worry about.

I simply put back the original processor scope and now C-states are working!

	Scope (_PR)
{
	Processor (P001, 0x01, 0x00000810, 0x06) {}
	Alias (P001, CPU1)
	Processor (P002, 0x02, 0x00000000, 0x00) {}
	Alias (P002, CPU2)
	Processor (P003, 0x03, 0x00000000, 0x00) {}
	Alias (P003, CPU3)
	Processor (P004, 0x04, 0x00000000, 0x00) {}
	Alias (P004, CPU4)
{

I have never been able to boot OS X on this motherboard without removing the aliases - only when using the Voodoo Kernel and a P4 CPU + Hyperthreading disabled.

 

I can't believe it was that simple a fix. And it makes sense since the SSDT tables refer to P001-4.

 

It turns out that if i load all my five SSDT dumps and use the above processor scope I am back to four P-states. If I only load the two C-state SSDTs and the "cpupm" SSDT I get 8 P-states AND C-states working.

 

Random irrational bla bla: I think the 8 P-states have to do with the 'Penryn' CPU profile that OS X loads for my CPU, Penryn is the mobile version of my Wolfdale CPU which is used in the iMac9,1 and it makes sense that it would have twice the P-states. My instincts say that it's probably better to stick with four P-states since that's what I have in Windows and Linux.

Link to comment
Share on other sites
iFIRE
iFIRE
Posted
Posted

Hola GRINGO, eu tive alguns problemas com o ACPIPlatformPluguin.kext e solucione colocando o device id do meu chipset ISA BRIDGE 8086 3b02

no final do infoplist, coloca o device id tambem en el kext LPC, no link abaixo como patch el ACPIPlatformPluguin.kext, sobre o bootloader ainda nao genera CST and Pstates ao mesmo tempo o um o otro,pra min me pass o mesmo, mais para alguns dicen k funciona ok.

 

bash-3.2# ioreg -l | grep 060100

| | | "reg" = <0000060000000000000000000000000000000000100006010000000000$

| | | | "compatible" = <"pci1458,5001","pci8086,3b02","pciclass,060100">

| | | | "class-code" = <01060100>

bash-3.2#

 

http://forum.thinkpads.com/viewtopic.php?f=32&t=85344

 

 

 

Un Saludo

 

 

Osmarbcn

Link to comment
Share on other sites
Trauma!
Trauma!
Posted
Posted

Hy,

 

I've just tested latest commit on the trunk. CPU detection works fine now. But there still need to rework QPI detection.

Actually Core I5 TM are settled to 2800, but mine (i5 760) has a 4800 QPI.

 

I've hardcoded the value to fix it, for now. Would be nice if we find a way to dynamically set it up.

 

Cheers.

Link to comment
Share on other sites
rekursor
rekursor
Posted
Posted

Thanks dgobe for this contrib,

I integrated this detection for ix's cpus in r317,

I also added a round off to match real macs profiler info ^_^

@team: this code uses pci.h code, it should be moved adequately into a new platform cpu busspeed attribute probably in cpu.c ...

 

Rek

I hacked smbios_patcher.c to detect SMbusspeed. Probably should move the nhm_bus business into Platform.CPU and scan_platform. Here's a boot file for anyone with Core i7/i5/i3 if they want to test. Look in System Profiler under Processor Interconnect Speed.

 

 

boot.zip

 

Credit to rek for the bus detection code.

 

include "pci.h"

...

			switch (Platform.CPU.Model)
			{
				case 0x0F: // Intel Core (65nm)
				case 0x17: // Intel Core (45nm)
				case 0x1C: // Intel Atom (45nm)
					return 0; // TODO: populate bus speed for these processors
				case 0x19: // Intel Core i5 650 @3.20 Ghz
				case 0x1A: // Intel Core i7 LGA1366 (45nm)
				case 0x1E: // Intel Core i5, i7 LGA1156 (45nm)
				case 0x1F: // Intel Core i5, i7 LGA1156 (45nm) ???
				case 0x25: // Intel Core i3, i5, i7 LGA1156 (32nm)
				case 0x2C: // Intel Core i7 LGA1366 (32nm) 6 Core
				case 0x2E: // Intel Core i7 LGA1366 (45nm) 6 Core ???
				{
					int nhm_bus = 0x3F;
					static long possible_nhm_bus[] = {0xFF, 0x7F, 0x3F};
					unsigned long did, vid;
					int i;

					// Nehalem supports Scrubbing
					// First, locate the PCI bus where the MCH is located
					for(i = 0; i < sizeof(possible_nhm_bus); i++)
					{
						vid = pci_config_read16(PCIADDR(possible_nhm_bus[i], 3, 4), 0x00);
						did = pci_config_read16(PCIADDR(possible_nhm_bus[i], 3, 4), 0x02);
						vid &= 0xFFFF;
						did &= 0xFF00;

						if(vid == 0x8086 && did >= 0x2C00)
							nhm_bus = possible_nhm_bus[i]; 
					}

					unsigned long qpimult, qpibusspeed;
					qpimult = pci_config_read32(PCIADDR(nhm_bus, 2, 1), 0x50);
					qpimult &= 0x7F;
					DBG("qpimult %d\n", qpimult);
					qpibusspeed = (qpimult * (Platform.CPU.FSBFrequency/1000000)) << 1;
					DBG("qpibusspeed %d\n", qpibusspeed);
					return qpibusspeed;
				}
			}
...

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...