Contribute
Register

Revogirl SSDT generation script

Status
Not open for further replies.
do we really need DropSSDT=yes? I cannot boot with this argument in the kernel flag statement in my plist. it stalls on NullCPUPowermanagement. no KP though. Asus p8p67 pro with modified 2103 bios. i have copied the p statements from the generated SSDT to my DSDT as well. no go. just get 16, and 33 frequencies.

I'm not sure what you mean. If you have nullcpupowermanagement.kext still installed then you won't get power management whatever you do......

You need to look into what your board needs to let you take that kext out of S/L/E without KP. This may mean DSDT edits and/or patching the AppleIntelCPUPowermanagement.kext (AICPUPM) only once the board can boot properly without the null kext will you be able to get power management working via AICPUPM.
 
i have both the patched appleintelCPUpowermanagement and no nullCPU and patched dsdt/ssdt. it is now working. the modded bios just never worked for me. what i was saying was.. anytime i used DropSSDT=yes.. my system wouldn't boot. no KP. just stalls. doesn't matter now anyhow. i have full speed stepping with mountain lion.
 
So if I'm reading correctly you are not using a DSDT, but have included the SSDT in the Extra folder - is that correct? I think that the SSDT will only load if you are actually using a DSDT as well as it may need it to be there to operate.

I am not an expert on this though so I am not 100% certain.
 
Check if the SSDT is loading. E.g. use DSDTse and click the "Extract Table" button after selecting "SSDT" and see if it is the one you generated from the script....
 
Okay, so it looks like it loaded, but the system does not understand it, can't use it or is incompatible with it right now.

I have never tried to use a SSDT without a DSDT so what I am doing is guessing a little bit here. I think the DSDT calls the SSDT or at least shares references with it so you should maybe think about using one. In my Mountain Lion build I actually took the power management parts of the DSDT and inserted them into the DSDT. That sounds a bit daunting I know, so maybe the first next thing would be for you to use DSDTse to look at your native DSDT and do some basic checks and edits and then put the DSDT into your extra folder and see if you can get DSDT/SSDT working together from there. Samisnake did an excellent guide on editing a DSDT.

If I were you I would also check the native DSDT and see what is in the processor section (something like "Scope (_PR)") and see if it uses the same terminology as you have in your generated SSDT. For instance, it might name the processors differently e.g. might use PR0 instead of CPU0 or something. In some cases board makers use different layouts that could easily make a generated SSDT such as the Revogirl one incompatible with the native tables so that it doesn't work.

Of course though if you are going this far it might just be more advisable to abandon the Revogirl script and base any edits on the native system. If you want some help I (or others here) would be happy to take a look at your native DSDT and help you fix errors/add hacks.
 
Hi,
A good start point is to follow Samisnakes tutorial and see how it goes.....
However, if you want to simply extract your DSDT using DSDTse and post it up to the forum I'd certainly be happy to take a first look at it and give you my opinion (for what it is worth!). While I don't pretend to be an expert I have read a lot and used DSDTs for my last half dozen or so systems so I can at least give you a start point.
 
Hi,

Happy to help.

Question first though, if the board you have is the GA-Z68MA-D2H-B3 then why aren't you using the pre-edited DSDT from the TonyMac database?
 
Okay - fair enough!

So I guess that there is no DSDT in the TonyMac database for your Uefi version then?

I will get back to you with a DSDT without errors later based on your version before patching and will explain the changes made. I was surprised though when I compared your two DSDT versions that you attached in Text Wrangler as there are a very large number of differences between the two - with lots of changes in detail that didn't really seem usual or understandable.

I'll post again later. Got some work to do first though....
 
Okay, here is your patched DSDT and explanations of what I did to it.

This should at least be a good start point. Check to make sure there are no KPs first and let me know. Don't try and use SSDT yet.
 

Attachments

  • TMBCK2 explanations.txt
    3 KB · Views: 543
  • dsdtTMBCK2.aml.zip
    14.1 KB · Views: 230
Brilliant. That is good news.
It is usual to have different p-states like that and is at the very least a great start and an improvement on what was there before. If working properly the system will look at the intensity of the task you are asking it to do and dynamically decide which p-states to go to.
I presume it is now generating the p-states from the native ACPI tables on the board? What I mean is, I am guessing you have abandoned the "revogirl" generated table and that you do not have "GeneratePstates" or "DropSSDT=Yes" inside your boot plist in the Extra folder. Can you confirm that for me?
If you are working natively and you think you should still have more p-states then as a next step you could perhaps look at the native SSDT tables (there are probably more than one and they will be labelled SSDT.aml, SSDT-1.aml, SSDT-2.aml) and figure out which of these is being referenced by the DSDT to control the power management and check that it has all needed p-states fully described in it. You can look at these native SSDT tables and modify them using DSDTse as it is capable of extracting those too.
The good news now that you have a working DSDT specific to your machine though is that you can now add any extra hacks that you might need if there are any other aspects of your board that you think are not working correctly or to just make things look more like a Mac in System Profiler.
Once you are happy with the DSDT I suggest you simply re-name it as DSDT.aml and put it in the Extra folder and that way you do not need to use boot flags every time you start up.
 
Status
Not open for further replies.
Back
Top