SSDT-ALL

[kaoskinkae]

I have seen the topic on several sites about how to merge our SSDTs into one. I am not really into doing this but I am curious to know if it is effective to unify our SSDT into one, but the most important thing that I have not found information about is the correct order of placement of these SSDTs. An example would be the Coffee Lake SSDT, what would be the correct order?

 

 

[cankiulascmnfye]

SSDTs only need a specific order, if one references devices/paramters defined in the other one.

 

Here's a guide: https://github.com/5T33Z0/OC-Little-Translated/tree/main/N_SSDT-ALL

 

I have to say that there is really no benefit in doing this since you lose all the modularity you have when using seperate SSDTs.

Edited February 29, 2024 by cankiulascmnfye

[kaoskinkae]

19 hours ago, cankiulascmnfye said:

Los SSDT solo necesitan un orden específico, si uno hace referencia a dispositivos/parámetros definidos en el otro.

 

Aquí hay una guía: https://github.com/5T33Z0/OC-Little-Translated/tree/main/N_SSDT-ALL

 

Debo decir que realmente no hay ningún beneficio al hacer esto ya que se pierde toda la modularidad que tiene al usar SSDT separados.

I know the page precisely when it publishes I thought they had taken it away from me for publishing the page. The issue is complex and no one knows anything.

 

The information found is how the patched DSDT requires a specific order when it comes to modularizing and creating the SSDT is not worth the information provided in Dortania, how the loose SSDTs are placed.

 

I have information on how to place it there but I want to consolidate that information in other places on the hacintosh forums

[Allan]

The ones who can help you, is @MaLd0n or @Slice 😉

[Slice]

I think with new IASL compiler the order of SSDT has no matter.

[Baio77]

Example of an SSDT-Full Hack https://github.com/Baio1977/Lenovo-ThinkPad-X1-Tablet-Gen3-Kabylake-r/blob/main/0.9.9/EFI/OC/ACPI/SSDT-Thinkpad_X1Tablet_3Gen.dsl

Here as you can see I have integrated functional patches and aesthetic patches to make it similar to the ACPI of a real Macbookair 8.1 SMBios in use.

 

Edited March 2, 2024 by Baio77

[miliuco]

@Baio77

 

Your link goes to 0.9.8 EFI:

https://github.com/Baio1977/Lenovo-ThinkPad-X1-Tablet-Gen3-Kabylake-r/blob/main/0.9.8/EFI/OC/ACPI/SSDT-Thinkpad_X1Tablet_3Gen.dsl

 

But now you have only 0.9.9 EFI:

https://github.com/Baio1977/Lenovo-ThinkPad-X1-Tablet-Gen3-Kabylake-r/blob/main/0.9.9/EFI/OC/ACPI/SSDT-Thinkpad_X1Tablet_3Gen.dsl

[cankiulascmnfye]

4 hours ago, miliuco said:

@Baio77

 

Your link goes to 0.9.8 EFI:

https://github.com/Baio1977/Lenovo-ThinkPad-X1-Tablet-Gen3-Kabylake-r/blob/main/0.9.8/EFI/OC/ACPI/SSDT-Thinkpad_X1Tablet_3Gen.dsl

 

But now you have only 0.9.9 EFI:

https://github.com/Baio1977/Lenovo-ThinkPad-X1-Tablet-Gen3-Kabylake-r/blob/main/0.9.9/EFI/OC/ACPI/SSDT-Thinkpad_X1Tablet_3Gen.dsl

 

Well, ACPI tables usually don't change when working. Because the hardware doesn't change just because an OC update is released

Edited March 2, 2024 by cankiulascmnfye

[kaoskinkae]

The topic is super interesting for those who want to merge their generic and complementary SSDT into one.

An example is the different order of separate placement of the SSDT-EC-USBX.aml (SSDT-EC.aml and SSDT-USBX)

In some included the MaLd0n.aml ssdt appears in a different place than if it were merged

 

 

[MaLd0n]

You can include it separately and if you prefer to separate it by Scope/Devices bla bla bla.

MaLd0n. All Inside Same Scope.zip

It doesn't make any difference and you already have just one file which is what you really want in this case.

[cankiulascmnfye]

On 3/3/2024 at 2:03 PM, kaoskinkae said:

The topic is super interesting for those who want to merge their generic and complementary SSDT into one.

An example is the different order of separate placement of the SSDT-EC-USBX.aml (SSDT-EC.aml and SSDT-USBX)

In some included the MaLd0n.aml ssdt appears in a different place than if it were merged

 

 

I don't see anything interesting about it except that certain users misuse this table to place their branding via injecting fake devices onto user's system without their consent!

Edited March 7, 2024 by cankiulascmnfye

[MaLd0n]

Like RTC inside ARTC to load nothing.

The Hackintosh Masters of 2020 Are Terrible (In a Good Way, If There Is One)

People use these patches from long long time ago since Chameleon and Clover and the creators aren't even here anymore, so a newbie like you can't even talk much about it due to lack of experience in the subject. 

Just respect all InsanelyMac members and don't post anything that you have no idea what it's for or where it comes from just for half a dozen friends to clap.

It's a forum with rules and not your home! Remeber that!

 

[chris1111]

OFF Topic maybe controverse

 

To me a SSDT Full Hack will never be up to a full patch DSDT 

I speak from experience on all the HP laptops that I have had and believe me that I have had many

We will never know the real reason why Rehabman switched to SSDT when he brilliantly used the DSDT Full patch to its full potential; like @MaLd0n DSDT patch

I have my own idea as to why but I'll keep it to myself.

People who have never used DSDT full patch on their laptop cannot understand but the day you do it and get there you will understand.

Edited March 4, 2024 by chris1111

[cankiulascmnfye]

Since patching DSDTs is comming up again, I'd like to remind people what the problems with patching DSDTs actually are. And don't take my word for it – take it from someone who actually knows:

 

https://www.insanelymac.com/forum/topic/352881-when-is-rebaseregions-necessary/?do=findComment&comment=2790875

 

Edited March 7, 2024 by cankiulascmnfye

[kaoskinkae]

The topic of this post is not to talk about the "to be or not to be" of the use of DSDT, that is another question and impossible to reach an agreement.

 

The issue is the use of fusion of the mandatory and complementary SSDTs and the hierarchy in the order of placement, whether it is a strict question or the order of placement of the SSDTs can be placed as a basis on the Dortania guide.

 

I have seen a list of the correct order that should be carried out there but I needed other opinions and I have been and am here from Maverisk

[miliuco]

@kaoskinkae

Dear friend, merging all SSDTs into a single file is not an easy task. Often you get a non functional SSDT. 
I my opinion, keeping separate SSDTs is a better practice. 
I know this is not the answer to your question. 

[Slice]

You can join several SSDT and even DSDT+SSDT just keep in mind that a Name or a Method should be declared before using.

[mhaeuser]

AML files are probably closest to object files when comparing them to traditional compiler terminology. They are linked at runtime by ACPI driver. While different OSes can in theory have different requirements, I don’t think the order realistically matters anywhere.

 

As for merging, of course it’s possible - the compiler basically does this at the level of dynamic representations. However, there is no benefit. If you believe there will be a magic performance boost or drop in RAM usage - no. At best, you will gain an unmeasurable performance boost at the ACPI linking stage. You will clutter your setup for no reason.

 

On 3/5/2024 at 11:23 AM, kaoskinkae said:

The topic of this post is not to talk about the "to be or not to be" of the use of DSDT, that is another question and impossible to reach an agreement.

It depends - if you stick to factual evaluation, there is only one valid answer. If you are into esoteric stuff, there indeed are no limits as to what you can claim as “controversial opinion”.

 

 

[kaoskinkae]

1 hour ago, mhaeuser said:

Los archivos AML probablemente sean los más cercanos a los archivos objeto cuando se los compara con la terminología tradicional del compilador. Están vinculados en tiempo de ejecución mediante el controlador ACPI. Si bien, en teoría, diferentes sistemas operativos pueden tener diferentes requisitos, no creo que el orden importe de manera realista en ninguna parte.

 

En cuanto a la fusión, por supuesto que es posible: el compilador básicamente lo hace en el nivel de representaciones dinámicas. Sin embargo, no hay ningún beneficio. Si cree que habrá un aumento mágico del rendimiento o una disminución en el uso de RAM, no. En el mejor de los casos, obtendrá un aumento de rendimiento inconmensurable en la etapa de vinculación ACPI. Abarrotarás tu configuración sin ningún motivo.

 

Depende: si nos atenemos a la evaluación objetiva, sólo hay una respuesta válida. Si te gustan las cosas esotéricas, de hecho no hay límites en cuanto a lo que puedes reclamar como “opinión controvertida”.

 

 

When I started this with Maverist chameleon MyHack and then moved on to Clover, the use of the DSDTs on my board was implemented in MaciASL.

With the use of opencore my mentality changed and I stopped using DSDTs for SSDTs but as you said it all depends on each person's mentality.

[Slice]

Don't switch to opencore and have no headache.

[kaoskinkae]

13 hours ago, Slice said:

No cambie a opencore y no tenga dolor de cabeza.

It's the same as saying don't write on a computer, still in your handwriting. Topic closed for me

[mhaeuser]

On 3/7/2024 at 9:17 PM, Slice said:

Don't switch to opencore and have no headache.

Yeah, I heard Clover is a lot more stable since it leverages OC libraries for some critical things.