Jump to content

Chameleon bootloader with SSDT and DSDT override

ab___73

By ab___73,
in Developer's Corner

 Share
131 posts in this topic

Recommended Posts

mackerintel
mackerintel
Posted
Posted

I don't really see the point of this version. SSDT can easily be added to DSDT and then you may specify DropSSDT=y and original SSDTs will be ignored. I said this somewhere in the topic dedicated to DSDT patch but that topic is now way too bloated. About 64k limit, extra and so on: it's already done in experimental chameleon. We're work on some nice features now.

Link to comment
Share on other sites
_caine
_caine
Posted
Posted
I don't really see the point of this version. SSDT can easily be added to DSDT and then you may specify DropSSDT=y and original SSDTs will be ignored.

Agree.

It could be much better if someone fixes fsb detection like it done in smbiosresolver or in other injectors.

Link to comment
Share on other sites
OneSman7
OneSman7
Posted
Posted
I don't really see the point of this version. SSDT can easily be added to DSDT and then you may specify DropSSDT=y and original SSDTs will be ignored. I said this somewhere in the topic dedicated to DSDT patch but that topic is now way too bloated. About 64k limit, extra and so on: it's already done in experimental chameleon. We're work on some nice features now.

 

So where can I get this experimental version? :) I do not mind what to use:SSDT or DSDT, as soon as it fixes shutdown/restart.

Link to comment
Share on other sites
  • 2 weeks later...
Signal64
Signal64
Posted
Posted

mackerintel is obviously correct. You can add SSDT to your DSDT and it will override those tables in bios.

Guessing you can add any other ACPI table there as well. Don't see why not (yet).

 

You can also debug by specifying a test DSDT=(put your test dsdt aml filename here) on boot. Very helpful :wacko:

 

I'm interested in solving a "no _PSS table" and "_CST evaluation failed" errors.

kernel[0]: ACPI_SMC_PlatformPlugin::start - no _PSS table
kernel[0]: ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed
kernel[0]: ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

 

I tried to use my MacBook5,1 SSDT as a template and replaced the CST info to what my board was reporting and still got the _CST error. I also dumped all of the ACPI tables from the MacBook5,1 and of course there is no _PSS table there.

 

I did a bit of digging for Linux on MacBook acpi topics and see there was some c-state problems in that arena. It was implied that OS X is ignoring the the FACP _CST Support : 00 entry and doing it's own thing hence reporting 00 to Linux caused C-State problems there.

 

No definitive proof on that, but looking at the Info.plist for ACPI_SMC_PlatformPlugin.kext we see entries for C-States based on MacBook models among other goodies such as iGPU throttling (of course for apple hardware).

 

There is also a Simple_PlatformPlugin.kext which looks interesting just by it's existence.

Both of these are located in the IOPlatformPluginFamily.kext/Contents/PlugIns folder.

 

Soooo. now I'm curious to try a few more things out here and see why some folks can apparently get their CST working in SSDT (model number not being set or found in the ACPI_SMC?) and what happens if we just try to use the Simple platform kext instead.

 

BTW - I wrote this quick and dirty script to dump all of the acpi tables (with disassembly). Yea, it isn't elegant, more ksh'sh and brute force, but it works well and can be adapted. I'm using it to compare the various tables on different platforms.

 

unzip, run the script ./dumpacpitbls, and it will create a acpitbls folder with all of the aml/dsl files.

dumpacpitbls.zip

Link to comment
Share on other sites
ab___73
ab___73
Posted
  • Author
Posted
mackerintel is obviously correct. You can add SSDT to your DSDT and it will override those tables in bios.

Guessing you can add any other ACPI table there as well. Don't see why not (yet).

 

You can also debug by specifying a test DSDT=(put your test dsdt aml filename here) on boot. Very helpful :shock:

BTW - I wrote this quick and dirty script to dump all of the acpi tables (with disassembly). Yea, it isn't elegant, more ksh'sh and brute force, but it works well and can be adapted. I'm using it to compare the various tables on different platforms.

 

unzip, run the script ./dumpacpitbls, and it will create a acpitbls folder with all of the aml/dsl files.

 

Thanks for the script signal64.

 

Mackerintel is correct, you can add all processor functions (pstates, cstates and tstates) inside the _PR scope of the DSDT. I used this method before I modified MackerIntels excellent bootloader.

 

I found it quite hard to follow all of the changes I was making to the dsdt file and thought it would be easier to break it down into smaller tables just like what the oem manufactures do.

 

I wasn't going to release this into public domain, since i didn't think anyone would interested in it. But after reading that someone had power management problems i thought i would so that I could help.

 

Thanks to everyone that uploaded their tables and Mackerintel for the original idea.

Link to comment
Share on other sites
  • 2 months later...
Hugo_bee
Hugo_bee
Posted
Posted

hy

I need your help.

I've created SSDT.aml and DSDT.aml

but the ssdtboot won't work.

 

i've chameleon2 and at boot now it say:

apple boot plist not found

 

then.. if I boot from another drive (external) with chamel2 and I select my hdd it boots fine.

Link to comment
Share on other sites
coconup
coconup
Posted
Posted

chameleon2 supports ssdt override, you just have to put all your ssdt tables into your dsdt and add dropssdt=y as a boot argument. btw, I have all the tables from a mb4,1, which is a kind of a clone of my low-cost laptop :thumbsdown_anim:. I copied and pasted all the c-states in my ssdt because my laptop has the very same processor (t8100), but I still get this on boot:

 

 

17/04/2009 01:36:33 kernel ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed

17/04/2009 01:36:33 kernel ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

 

I tried both with my original cstates and with the ones from the macbook4,1... I also emulate smc in my dsdt but this doesn't seem to help... any idea?

 

btw these are the mb's tables:

mb4_1.zip

Link to comment
Share on other sites
Hugo_bee
Hugo_bee
Posted
Posted
chameleon2 supports ssdt override, you just have to put all your ssdt tables into your dsdt and add dropssdt=y as a boot argument. btw, I have all the tables from a mb4,1, which is a kind of a clone of my low-cost laptop :huh: . I copied and pasted all the c-states in my ssdt because my laptop has the very same processor (t8100), but I still get this on boot:

 

 

17/04/2009 01:36:33 kernel ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed

17/04/2009 01:36:33 kernel ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

 

I tried both with my original cstates and with the ones from the macbook4,1... I also emulate smc in my dsdt but this doesn't seem to help... any idea?

 

btw these are the mb's tables:

 

 

put into dsdt how?

cut and paste ssdt.dsl text file in the queue of dsdt.aml and then compile the only one?

and after.. put it in E/E or / ?

Link to comment
Share on other sites
coconup
coconup
Posted
Posted

as someone stated at the beginning of this post, this should be only for people who are confident with this stuff.. however yes, look at the scopes in your ssdts, cut and paste from there to the proper place in your dsdt, compile it and put it where it usually is. then add dropssdt=y.

 

btw, has anybody succeeded in using appleintelcpupm properly? my laptop has the very same chipset, graphics and processor of a macbook4,1.. the only problem seems to be the smc device that I obviously don't have..

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
how did u manage to get speedstep working with appleintelcpupm?!

I don't know how to explain it, it just....works. I just migrated from hack to retail setup (about a month ago). I was hoping somebody can explain it to me actually. This is the main reason I shared my ssdt file here.

 

Speedstep did not working while I'm using hack (JaS 10.5.4 & iPC 10.5.6) setup even with DSDT override. Geekbench always scored 1600. After I applied VoodooPower, speedstep working & geekbench scored 2300-2400. But I'm experiencing extreme CPU temperature & occasional kernel panic. So, I removed it. Then I changed to retail setup (without installing VoodooPower because past experience). Just recently (this week) I applied DSDT override because I want to add HDEF code for my audio, ALC883, so that I can remove HDAEnabler.kext & legacy HDAController.kext. This afternoon while doing some works, I detect 'abnormal' changes to my CPU temperature. I know that changes is not possible if I don't have speedstep. So I execute geekbench & supprisingly it scored 2200-2300. To confirm it I did a couple of reboot & shutdown. I also installed "MSR Tools" just to make sure.

 

BTW, I installed VMware Fusion 2.0.4. I don't know if it has anything to do with it.

 

kizwan

Link to comment
Share on other sites
coconup
coconup
Posted
Posted

well, have you checked if you have speedstep with cpu-x for example? also, do you get these errors on boot?

 

27/04/2009 01:10:21 kernel ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed 
27/04/2009 01:10:21 kernel ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

 

btw I'm on a retail installation as well, I only load dsmos, VoodooPS2 and HDA kexts from the efi partition and I installed voodoopower and voodoobattery in s/l/e

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
well, have you checked if you have speedstep with cpu-x for example?

Yes, the CPU have speedstep capability.

also, do you get these errors on boot?

 

27/04/2009 01:10:21 kernel ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed 
27/04/2009 01:10:21 kernel ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

No, I did not get that error either on hack or retail.

btw I'm on a retail installation as well, I only load dsmos, VoodooPS2 and HDA kexts from the efi partition and I installed voodoopower and voodoobattery in s/l/e

I only load AppleACPIBatteryManager, HDA, SMBIOSResolver, AppleACPIPlatform.kext (vanilla kext for ApplePS2Controller dependency), AppleDecrypt.kext, ApplePS2Controller.kext, IO80211Family.kext (vanilla kext, just add '4315' in broadcom info.plist) and IONetworkingFamily.kext (vanilla kext for IO80211Family.kext dependency) from the efi partition. I did not install voodoopower.

 

kizwan

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

Hi folks,

 

THIS IS NOT FOR THE CASUAL USER

 

C-States are usually stored in hard coded memory addresses.

 

If one of your SSDT tables contains something similar to the following:

 

    Scope (\)
   {
       Name (SSDT, Package (0x0C)
       {
           "CPU0IST ", 
           0x7F7F4852, 
           0x000001FB, 
           "CPU1IST ", 
           0x7F7F478A, 
           0x000000C8, 
           "CPU0CST ",
           0x7F7F4AD2, 
           0x000004CB, 
           "CPU1CST ", 
           0x7F7F4A4D, 
           0x00000085
       })

 

This indicates that your computer has C-States hard coded in to memory addresses.

 

The above code is an array of the hard coded memory locations and sizes of your C-States. These are usually unique to the oem BIOS version.

 

I've found that for some strange reason the ACPI_SMC....kext only recognises and loads C-States when they are loaded using the above method.

 

I've used acpidump with a ubuntu live CD to dump my C-State tables. (google acpidump dsdt linux).

 

I've also modified them and loaded them by compiling them to a .aml file renamed them to SSDT-X.aml (where X is a number above the last SSDT table you have in your root folder), copied them to the root folder.

For example I have the following files in my root folder:

 

SSDT-0.aml (first oem ssdt table from my laptop)

SSDT-1.aml (second "" "" "" "" )

..

SSDT-4.aml (last oem table from my laptop)

SSDT-5.aml (dump of my first C-State table that i dumped with ubuntu using acpidump)

SSDT-6.aml (dump of my second "" "" "" "")

..

SSDT-8.aml (dump of my last C-State table "" "" "")

 

these C-State tables are now loaded into a memory location different from the oem hard coded tables.

 

You can find the memory location of these by booting with the voodoo kernel in kprintf=1 mode.

 

When you run "sudo dmesg" from terminal you will find something similar to the following:

 

ACPI: SSDT @ 0x18b3000/0x0024 (v001 HP       HPQNLP 0x00000001 INTL 0x20080926)
ACPI: SSDT @ 0x18b4000/0x02E9 (v001 HP       HPQSAT 0x00000001 INTL 0x20080926)
ACPI: SSDT @ 0x18b5000/0x0232 (v001 HP      Cpu0Tst 0x00003000 INTL 0x20080926)
ACPI: SSDT @ 0x18b6000/0x00A0 (v001 HP      Cpu1Tst 0x00003000 INTL 0x20080926)
ACPI: SSDT @ 0x18b7000/0x0024 (v001 HP       HPQNLP 0x00000001 INTL 0x20080926)
ACPI: SSDT @ 0x18b8000/0x0024 (v001 HP       HPQNLP 0x00000001 INTL 0x20080926)
ACPI: SSDT @ 0x18b9000/0x0064 (v001 HP CPU0IST 0x00000001 INTL 0x20080926)
ACPI: SSDT @ 0x18ba000/0x0056 (v001 HP CPU1IST 0x00000001 INTL 0x20080926)
ACPI: SSDT @ 0x18bb000/0x0034 (v001 HP CPU0CST  0x00000001 INTL 0x20080926)
ACPI: SSDT @ 0x18bc000/0x0064 (v001 HP       CPU1CST 0x00000001 INTL 0x20080926)

 

The code above indicates the location of the C-State tables that have been modified and have been loaded into a lower memory location.

 

these are the lines to look for:

 

ACPI: SSDT @ 0x18b9000/0x0064 (v001 HP CPU0IST 0x00000001 INTL 0x20080926)

ACPI: SSDT @ 0x18ba000/0x0056 (v001 HP CPU1IST 0x00000001 INTL 0x20080926)

ACPI: SSDT @ 0x18bb000/0x0034 (v001 HP CPU0CST 0x00000001 INTL 0x20080926)

ACPI: SSDT @ 0x18bc000/0x0064 (v001 HP CPU1CST 0x00000001 INTL 0x20080926)

 

Then modify the SSDT table that contained the array to the hardcoded location of the C-States to the following to suit the memory locations above: (for example)

Scope (\)
{
Name (SSDT, Package (0x0C)
{
"CPU0IST ",
0x18b9000,
0x0000064,
"CPU1IST ",
0x18ba000,
0x0000056,
"CPU0CST ",
0x18bb000,
0x0000034,
"CPU1CST ",
0x18bc000,
0x0000064
})

 

Recompile this modified SSDT table to an aml file and copy it into the root folder.

 

When you reboot ACPI_SMC....kext will now load the modified C-State tables.

 

I've attached my C-States dumped with acpidump using the ubuntu live CD

 

hp530_cstates_orig.zip

 

I hope this helps someone.

 

 

Cheers

ab

Link to comment
Share on other sites
coconup
coconup
Posted
Posted

thankyou I'll try this tomorrow hopefully, but how do you modify your c-states? I mean, how do you get the correct values that are meant to be injected? It would be great to have a macbook4,1 c-state dump 'cos I have the very same processor.. but I know this is a quite difficult request :(

 

also, from what I know the c-states are 'only' useful to control the power management, will this enable vailla speedstep as well?

 

finally, would you mean to tell me what should I write in the linux terminal to dump my c-states? I'm now downloading ubuntu live 'cos I keep on losing the cds every time :)

Link to comment
Share on other sites
coconup
coconup
Posted
Posted

so this is what I did: in my ssdt I have for example

 

"CPU0IST ",

0xBF6D501D,

0x027A,

 

so, in linux, acpidump --addr 0xBF6D501D --length 0x027A

 

but it seems that the addresses and the lengths are all messed up cos none of the output I get can be decompiled. I always get an error like TableHeader length [0x5F314348] greater than the input file size [0x27A] in iasl. This is probably the reason why my c-states are not loading in os x. is there any way to get the correct addresses from linux?

Link to comment
Share on other sites
ab___73
ab___73
Posted
  • Author
Posted
so this is what I did: in my ssdt I have for example

 

"CPU0IST ",

0xBF6D501D,

0x027A,

 

so, in linux, acpidump --addr 0xBF6D501D --length 0x027A

 

but it seems that the addresses and the lengths are all messed up cos none of the output I get can be decompiled. I always get an error like TableHeader length [0x5F314348] greater than the input file size [0x27A] in iasl. This is probably the reason why my c-states are not loading in os x. is there any way to get the correct addresses from linux?

 

Sorry i missed a step. You need to decompile them before modifying them.

 

in linux:

 

acpidump -a 0xBF6D501D -l 0x027A -o CPU0IST.aml

 

iasl -d CPU0IST.aml

 

(this shoud create CPU0IST.dsl or CPU0IST.dat)

 

check this by:

 

pico CPU0IST.dsl (or dat)

 

Repeat this for all the other memory addresses, change the output file name to match the string from the table e.g. CPU1IST.aml CPU0CST.aml etc. (this is not required it just keeps things tidy).

 

Copy these files onto a memory stick or other removable media for use in mac.

 

--

 

AB

Link to comment
Share on other sites
coconup
coconup
Posted
Posted
Sorry i missed a step. You need to decompile them before modifying them.

 

in linux:

 

acpidump -a 0xBF6D501D -l 0x027A -o CPU0IST.aml

 

iasl -d CPU0IST.aml

 

(this shoud create CPU0IST.dsl or CPU0IST.dat)

 

check this by:

 

pico CPU0IST.dsl (or dat)

 

Repeat this for all the other memory addresses, change the output file name to match the string from the table e.g. CPU1IST.aml CPU0CST.aml etc. (this is not required it just keeps things tidy).

 

Copy these files onto a memory stick or other removable media for use in mac.

 

--

 

AB

 

 

yes of course I tried to decompile them, but iasl gives an error and doesn't create the dsl file. In fact, I found out that in linux the cst addresses are different and they don't decompile as well... I'm starting to think that there are not cst tables in my bios. Here's my whole acpi memory section dumped from linux (dsdt+ssdt and everything else): 1.dat.zip

 

It's not possible to decompile it 'cos it includes everything and it must be splitted first, if you could have a look at it however it would be cool :)

 

edit: I decompiled everything and there's no trace of cst tables :thumbsup_anim: . I already have pstates from a macbook4,1 ioreg (same processor as my laptop), do you know if I can extract the cst from the ioreg as well?

 

finally, I have this in linux: states.zip

so I could try to inject them maybe, bu they seem to be a bit 'dirty'

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