Jump to content
iStig

SSDT dropić czy nie dropić ?

Recommended Posts

Kilka słów wyjaśnień dotyczących SSDT, generowania dodatkowych stanów przez skrypt ssdtPRGen.sh i działaniu funkcji porzucania tabel SSDT przez nasz bootloader. Sprawa jest dość banalna, ale przez brak zrozumienia tematu, wiele osób używa różnych funkcji nie zdając sobie sprawy z konsekwencji. Poniższy opis bazuje na funkcjonowaniu Clovera, ale z obserwacji Chameleon podobnie "podchodzi" do tematu.

 

System operacyjny używa tabel ACPI do "komunikowania się" z urządzeniami - ogólnie ujmując chodzi o zarządzanie energią. Większość urządzeń zdefiniowanych jest w tabeli DSDT, a tabele SSDT z założenia są suplementem i zawierają dodatkowy opis. I tu tkwi szkopuł. Producenci płyt bardzo różnie podchodzą do tematu i w tabelach SSDT zawierają różne rzeczy, ale może po kolei.

Specyfikacja ACPI dopuszcza definiowanie obiektu procesora w zakresie _SB (system bus - magistrala systemowa) lub _PR - ten ostatni obiekt wywodzi się jeszcze ze specyfikacji ACPI 1.0. Oba podejścia są poprawne, ale nie można definiować obiektu procesora w obu ! Dumpy różnych płyt potwierdzają teorię i możemy dowiedzieć się, że niektórzy mają obiekt procka zdefiniowany w tabeli DSDT w zakresie _PR, a w tabelach SSDT tylko dodatkowe funkcje dla tego obiektu. Inni mają podobne podejście tylko, że definicja jest w _SB, zamiast _PR, a w mojej płycie MSI Z68 było z kolei tak, że cała definicja obiektu procka była w jednej z tabel SSDT. Tu dochodzimy to sedna sprawy, czyli używania funkcji bootloaderów zrzucających tabele SSDT.

 

Clover sprawdza tabele RSDT (lub jej wersję 64bitową - XSDT), która zawiera wskaźniki do innych tabel ACPI i jeśli używamy funkcji DropOemSSDT wszystkie tabele SSDT nie są ładowane. Tu warto zatem wiedzieć co nasze tabele SSDT zawierają ! Jak wspomniałem w przypadku mojej płyty MSI Z68 jedna z tabel zawierała definicję obiektu procesora, więc wyrzucenie jej nie jest dobrym pomysłem, no chyba, że ktoś przepisał te obiekty do DSDT/SSDT i takie zmienione tabele ładował. Funkcja upuszczania tabel SSDT stała się popularna, gdy skryptem ssdtPRGen generowaliśmy stany procka. Problem w tym, że skrypt nie zawierał definicji obiektu procesora, a jedynie dodatkowe funkcje wykorzystywane przez OS X, a żeby było ciekawiej to pierwotnie skrypt ssdtPRGen.sh wypluwał definicje funkcji procka ZAWSZE dla zakresu _PR i zawsze o określonej nazwie np. CPU. Jak zatem w powyższego opisu można wywnioskować działało to tym, co nie mieli definicji obiektu procka w porzucanych tabelach SSDT oraz mieli procesor zdefiniowany w sekcji _PR....

Skrypt oczywiście z biegiem czasu ewoluował i zaczęto sprawdzać w jakim zakresie jest zdefiniowany obiekt procesora i pod jakimi nazwami, tak, aby dodatkowe funkcje wygenerowane przez skrypt odnosiły się do naszych definicji. Jak pisałem ten tekst to skrypt dalej błędnie wypluwał definicję funkcji w sekcji _PR mimo, że procesor miałem zdefiniowany w _SB, dlatego należy samemu sprawdzić czy wszystko jest tak jak powinno i ręcznie zmienić, albo poczekać na poprawną wersję skryptu :-)

Pozostała więc decyzja o opuszczaniu tabel - moim zdaniem nigdy tego nie powinniśmy robić. Testowałem płyty Gigabyte, gdzie często jest tam nawet siedem tabel SSDT, a jedna z nich opisuje SATA... Co jeszcze ciekawe, część z tych tabel nie jest wyszczególniona w tabeli RSDT/XSDT, a odnośniki do nich zawarte są w innych tabelach SSDT, więc porzucając tabele SSDT traci się sporo informacji.

 

Jak to wszystko rozwiązać ? - nie porzucać tabel SSDT, a wygenerowanej tabeli skryptem ssdtPRGen zmienić nazwę na kolejną np. SSDT-8.aml (w zależności ile tabel mamy) i taką załadować. Oczywiście tak jak pisałem wcześniej trzeba sprawdzić, czy nazwy (CPU0 - P001) i zakresy (_SB - _PR) wygenerowanych definicji są ok. Żadnych konfliktów nie będzie, bo nowa tabela SSDT zawiera funkcje APSS i ACST, które są ponoć tworami Apple i mimo, że w naszych tabelach ACPI spotkamy ich odpowiedniki w postaci _PSS i _CST, to i tak będą wykorzystywane te pierwsze.

 

I na koniec jeszcze info dla tych co zmieniają coś w tabelach SSDT i DSDT - BARDZO ważne jest odpowiednie dekompilowanie tabel - chodzi o odnosienia do innych tabel, czyli miejsca gdzie mamy wywołanie External. Należy dekomilować ze wskazaniem tych zewnętrznych tabel po parametrze -e. np.

iasl -eSSDT-0.aml,SSDT-1.aml,SSDT-3.aml -d DSDT.aml

Po pierwsze uzyskamy w definicjach poprawne nazwy obiektów, po drugie i najbardziej istotne - zostanie przekazana informacja o ilości argumentów - dekompilowanie każdej tabeli osobno może doprowadzić do sytuacji gdzie funkcja będzie miała tylko jeden argument zamiast np. czterech...

Share this post


Link to post
Share on other sites

Przyklejam.

 

Zawsze najnowszy skrypt do generowania tablli SSDT z stanami APSS i ACST można znaleźć pod tym linkiem:

https://github.com/Piker-Alpha/RevoBoot/blob/clang/i386/libsaio/acpi/Tools/ssdtPRGen.sh

 

Co do nazewnictwa, to akurat sprawdziłem organoleptycznie, że wystarczy tę naszą dodatkową tabelę ssdt nazwać ssdt.aml a i tak i zarówno chameleon jak i clover ją załaduje. Numeracja SSDT-x.aml powstaje podczas zrzucania na dysk, aby nazwy się nie pokrywały.

 

W podsumowaniu - NIC NIE dropimy, generujemy tabelę skryptem, wrzucamy w odpowiedni miejsce i sprawdzamy czy działa PM. Wyjątek niektóre MSI w których kodzie DSDT widziałem w środku sekcje z stanami APSS. Tam trzeba to ręcznie ogarnąć.

Share this post


Link to post
Share on other sites

Dobrze że o tym wspomniałeś. Cover domyślnie dropi tabele SSD, niekiedy na starszych kompach jest OK, ale na nowszych uważam, że dropienie często szkodzi bardziej niż pozostawienie tabel. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.