Skocz do zawartości

SSDT dropić czy nie dropić ?


 Udostępnij

Rekomendowane odpowiedzi

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...

Odnośnik do komentarza
Udostępnij na innych stronach

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ąć.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 lata później...

Dołącz do dyskusji

Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Usuń formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

Ładowanie
 Udostępnij

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystanie z tej witryny, wymaga zakceptowanie naszych warunków Warunki użytkowania.