Contribute
Register

Documentation for Chimera's DropSSDT

Status
Not open for further replies.

RehabMan

Moderator
Joined
May 2, 2012
Messages
181,111
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
Is there any documentation for DropSSDT. I'm wondering what exactly it does and when it should or shouldn't be used. About the best description I found through searching is from this thread:

http://forum.voodooprojects.org/index.php?topic=351.0

DropSSDT=Yes Skip the SSDT tables while relocating the ACPI tables.

I'm not sure how to interpret "the SSDT" and "the ACPI" tables... Is "the" referring to those in BIOS or to those in the /Extra/DSDT.AML?

And if you use DropSSDT it will still use /Extra/SSDT.AML or will it use /Extra/SSDT.AML no matter the state of DropSSDT?

Just trying to understand...
 
I'm going to answer my own question here.

I've been reading the Chimera source code to get an answer here and this is how I read it:

DropSSDT=Yes. Will cause Chimera to effectively strip any SSDT information in the DSDT. In the case of the ProBook there is no SSDT info directly in the DSDT so I don't think this option matters for us. From my reading of the code, it does not affect whether or not the information in your /Extra/ssdt*.aml is used.

GeneratePStates. When Yes, this causes Chimera to look at the CPU type and its min/max frequency through various MSRs at startup. It then generates a _PSS section of SSDT on the fly (think of it like building pstate (_PSS/APSS) part of SSDT.aml in memory during startup). The code there doesn't deal with more complex issues like TurboBoost which is why you need SSDT for chips w/ TurboBoost. These SSDT sections are added to the end of whatever SSDTs you already have loaded by virtue of having SSDT*.AML files in /Extra.

GenerateCStates. When Yes, this causes Chimera to look at the various flags for C1, C2, etc. from the boot.plist. It then generates a _CST section of SSDT on the fly similar to the _PSS section discussed above. Again, these SSDT sections are added to the end of whatever SSDTs you already had loaded from your SSDT.AML.

My guess is that if you have complete pstate/cstate information in your SSDT.AML, you do not need to have GeneratePStates or GenerateCStates. No need to generate them, if they are already there. My guess is that by having them in addition to complete information in your SSDT they will just be ignored, as they won't be the first entries in the DSDT that the OS sees through Chimera's simulation of smbios.

That said, I do not believe that the SSDTs we have been using are 100% complete, so don't go trying it yet. I will report back on what I learn after I test these theories...
 
Trying to learn something here. Keep going! thanks!
 
I haven't really had time to update the thoughts here because I've been focused on helping with the v4 Installer update (and painting the bathroom and bedroom for my wife), but so far what I wrote on the first post is true as far as I can tell.

I've got a complete SSDT which has complete APSS, ACST, and APSN methods for each CPU, and I'm able to boot with DropSSDT=Yes or No (doesn't matter), GeneratePstates=No, GenerateCstates=No. And the result is the same with Pstates=yes, Cstates=yes, as the system is only looking at the first instance of cstate/pstate info. It kind of makes sense that if you have this info in your ssdt.aml, that there is little reason to have the boot loader "generate" it. And if you do generate it, which one does the system use??... well, it seems it uses the first one it finds, which is the one from the ssdt.aml because the Chimera boot loader loads ssdt.aml stuff before generating the other ones.

I still have to double check this perhaps by building my own Chimera w/ some debug output/logs so I can be sure, but I don't have time for that right now.

At any rate, it is cool that it is open source, as even we are little light on the documentation, we can always read the code and understand more...
 
I have an HP elitebook 8560p. Should I use DropSSDt=Yes or No? I'm booting in EUFI mode trying to install Sierra. Has anyone gotten their Radeon video card to work in Sierra/ I see the HP probook installer works up to Yosemite, and that's it.

I somehow accidentally got the Radeon HD 6470M to work in Mavericks but have not been able to figure it out in Sierra. I see you guys have similar hardware on your machines including same CPU and a similar video card..
 
I have an HP elitebook 8560p. Should I use DropSSDt=Yes or No? I'm booting in EUFI mode trying to install Sierra. Has anyone gotten their Radeon video card to work in Sierra/ I see the HP probook installer works up to Yosemite, and that's it.

I somehow accidentally got the Radeon HD 6470M to work in Mavericks but have not been able to figure it out in Sierra. I see you guys have similar hardware on your machines including same CPU and a similar video card..

Your laptop has a guide:
https://www.tonymacx86.com/threads/...book-using-clover-uefi-hotpatch-10-11.189416/
 
I'm going to answer my own question here.

I've been reading the Chimera source code to get an answer here and this is how I read it:

DropSSDT=Yes. Will cause Chimera to effectively strip any SSDT information in the DSDT. In the case of the ProBook there is no SSDT info directly in the DSDT so I don't think this option matters for us. From my reading of the code, it does not affect whether or not the information in your /Extra/ssdt*.aml is used.

GeneratePStates. When Yes, this causes Chimera to look at the CPU type and its min/max frequency through various MSRs at startup. It then generates a _PSS section of SSDT on the fly (think of it like building pstate (_PSS/APSS) part of SSDT.aml in memory during startup). The code there doesn't deal with more complex issues like TurboBoost which is why you need SSDT for chips w/ TurboBoost. These SSDT sections are added to the end of whatever SSDTs you already have loaded by virtue of having SSDT*.AML files in /Extra.

GenerateCStates. When Yes, this causes Chimera to look at the various flags for C1, C2, etc. from the boot.plist. It then generates a _CST section of SSDT on the fly similar to the _PSS section discussed above. Again, these SSDT sections are added to the end of whatever SSDTs you already had loaded from your SSDT.AML.

My guess is that if you have complete pstate/cstate information in your SSDT.AML, you do not need to have GeneratePStates or GenerateCStates. No need to generate them, if they are already there. My guess is that by having them in addition to complete information in your SSDT they will just be ignored, as they won't be the first entries in the DSDT that the OS sees through Chimera's simulation of smbios.

That said, I do not believe that the SSDTs we have been using are 100% complete, so don't go trying it yet. I will report back on what I learn after I test these theories...
I'm going to answer my own question here.

I've been reading the Chimera source code to get an answer here and this is how I read it:

DropSSDT=Yes. Will cause Chimera to effectively strip any SSDT information in the DSDT. In the case of the ProBook there is no SSDT info directly in the DSDT so I don't think this option matters for us. From my reading of the code, it does not affect whether or not the information in your /Extra/ssdt*.aml is used.

GeneratePStates. When Yes, this causes Chimera to look at the CPU type and its min/max frequency through various MSRs at startup. It then generates a _PSS section of SSDT on the fly (think of it like building pstate (_PSS/APSS) part of SSDT.aml in memory during startup). The code there doesn't deal with more complex issues like TurboBoost which is why you need SSDT for chips w/ TurboBoost. These SSDT sections are added to the end of whatever SSDTs you already have loaded by virtue of having SSDT*.AML files in /Extra.

GenerateCStates. When Yes, this causes Chimera to look at the various flags for C1, C2, etc. from the boot.plist. It then generates a _CST section of SSDT on the fly similar to the _PSS section discussed above. Again, these SSDT sections are added to the end of whatever SSDTs you already had loaded from your SSDT.AML.

My guess is that if you have complete pstate/cstate information in your SSDT.AML, you do not need to have GeneratePStates or GenerateCStates. No need to generate them, if they are already there. My guess is that by having them in addition to complete information in your SSDT they will just be ignored, as they won't be the first entries in the DSDT that the OS sees through Chimera's simulation of smbios.

That said, I do not believe that the SSDTs we have been using are 100% complete, so don't go trying it yet. I will report back on what I learn after I test these theories...

Thanks for helping the Peeps Rehab Man. Do you know if the Elitebook Series also does not use a SSDT in the BIOS for UEFI booting? I see the Elitebook has a Legacy Boot Option, and a EUFI (recommended). If you strip the SSDT/Drop the SSDT. Is that information gone forever from the BIOS?

Say for instance If you wanted to install Linux, even worse another OS or an older version of OS X (like Lion, or earlier), would legacy boot be inoperable due to the SSDT being stripped?

Thank You, Nick/Mister Photon
 
Thanks for helping the Peeps Rehab Man. Do you know if the Elitebook Series also does not use a SSDT in the BIOS for UEFI booting? I see the Elitebook has a Legacy Boot Option, and a EUFI (recommended). If you strip the SSDT/Drop the SSDT. Is that information gone forever from the BIOS?

Say for instance If you wanted to install Linux, even worse another OS or an older version of OS X (like Lion, or earlier), would legacy boot be inoperable due to the SSDT being stripped?

Thank You, Nick/Mister Photon

What are you really asking?
All ProBook/EliteBook/etc use SSDTs.

Hackintosh bootloader (Clover/Chameleon/Chimera/etc) do not permanently affect BIOS.
 
Status
Not open for further replies.
Back
Top