Skocz do zawartości

haMac.pl używa cookie. Przeczytaj Privacy Policy aby dowiedzieć się więcej. Aby usunąć tę wiadomość, proszę kliknąć w przycisk po prawej:    Akceptuję użycie cookie

Zdjęcie

SSDT dropić czy nie dropić ?


  • Zaloguj się, aby dodać odpowiedź
3 odpowiedzi w tym temacie

#1 iStig

iStig
  • R.E.D.
  • 647 postów

Napisano 08 kwiecień 2013 - 14:23

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...
  • music lubi to

ASUS MAXIMUS VI GENE | i7-4770K | Corsair H80i + 2x Noctua NF-F12 PWM | 16GB (2x8GB) DDR3 Patriot PV316G240C0KRD | 2x Samsung 840 PRO 256GB + Samsung 1TB F3 + WD 2TB WD20EVDS | Sony AD-7690H | GeForce GTX 780 | Seasonic SS-760XP | Silverstone FT03 Black + 2x Noctua NF-S12A PWM | ACD 27" | Apple 802.11ac WiFi + BT 4.0 | Sierra & Windows 10

 

ASUS Z170 PRO GAMING | i5-6500 | 16GB (2x8GB) DDR4 Kingston HX421C14FBK2/16 | Intel 750 400GB SSDPEDMW400G4X1 | GeForce GTX 750Ti | Apple 802.11ac WiFi + BT 4.0 | Sierra


#2 314TeR

314TeR

    Administrator

  • Administrators
  • 16259 postów
  • LocationWarszawa

Napisano 08 kwiecień 2013 - 15:13

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

ASUS MAXIMUS VII IMPACT | Core i7-4790K | 16GB DDR3 2400 CL10 | GTX 980 Ti | FiiO E10 | OS X Retail via UniBootX Clover

ASUS Z87M-PLUS | Core i5-4590T | 8GB DDR3L 1333 | HD4600 | OS X Retail via UniBootX Cloverbyłe haMac'i: ASUS P5W DH DeluxeASUS P7P55 WS Supercomputer | ASUS P8Z68 Deluxe/GEN3 | ASUS P8Z77-V PRO THUNDERBOLTJak uruchomić na wypasie ALC 882/888/889/1200 | STOP Gigafail | P5W DH Deluxe - perfekcyjny hackintosh | Piszę poprawnie po polsku!

Co daje kalibracja monitora - zobacz jak można poprawić jakość obrazu.

 

Najszybszy hackintosh na świecie za procesorem 12C identyfikujący się jako Mac Pro (Late 2013) wg rankingu Geekbench: 37000 pkt

 

Pomogliśmy Tobie - pomóż nam - przekaż darowiznę na utrzymanie forum.

 


#3 wujek_bogdan

wujek_bogdan
  • Members
  • 837 postów

Napisano 02 sierpień 2015 - 11:02

Warto dodać do tematu, że Clover domyślnie (tak przynajmniej wnioskuję z dokumentacji) ma ustawione DropOem na true. 


Obecny:  10.11.5, Asrock Z87 Pro4, i7-4790k, 16GB DDR3@1600, MSI GTX 960, Audigy 2 ZS

Poprzedni: 10.10.4, ASUS P7P55D-E LX, i7-870, 8GB DDR3@1600, Saphire HD5770 1GB


#4 314TeR

314TeR

    Administrator

  • Administrators
  • 16259 postów
  • LocationWarszawa

Napisano 02 sierpień 2015 - 18:29

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. 


ASUS MAXIMUS VII IMPACT | Core i7-4790K | 16GB DDR3 2400 CL10 | GTX 980 Ti | FiiO E10 | OS X Retail via UniBootX Clover

ASUS Z87M-PLUS | Core i5-4590T | 8GB DDR3L 1333 | HD4600 | OS X Retail via UniBootX Cloverbyłe haMac'i: ASUS P5W DH DeluxeASUS P7P55 WS Supercomputer | ASUS P8Z68 Deluxe/GEN3 | ASUS P8Z77-V PRO THUNDERBOLTJak uruchomić na wypasie ALC 882/888/889/1200 | STOP Gigafail | P5W DH Deluxe - perfekcyjny hackintosh | Piszę poprawnie po polsku!

Co daje kalibracja monitora - zobacz jak można poprawić jakość obrazu.

 

Najszybszy hackintosh na świecie za procesorem 12C identyfikujący się jako Mac Pro (Late 2013) wg rankingu Geekbench: 37000 pkt

 

Pomogliśmy Tobie - pomóż nam - przekaż darowiznę na utrzymanie forum.

 





Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych