Dell OptiPlex 7040 płyta 0JCTF8

[DKnoto]

@Alpha01

Zaaplikowałem config.plist do .../UNIBOOTX/EFI/CLOVER/OEM/0JCTF8/ i pierwszy etap
przeszedł. Niestety chwilę po "Waiting for DSMOS" zaliczam KP. Wrócę do pierwotnego
ustawienia z instalatora...

[Alpha01]

"Waiting DMOS" czy waiting for DSMOS?
UNIBOOTX???? Po co to?

Czemu nie OptiPlex-7040-Clover-EFI-master? Wydaje się być OK.

[DKnoto]

Już poprawiłem na DSMOS.

UNIBOOTX kiedyś przygotowałem i mam jeden klucz startowy dla czterech maszyn.

Wynik testu ustawienia tylko opcji AAPL,ig-platform-id (desktop): 0x19120000 (default) powoduje mi panikę w AppleIntelSKLGraphicsFramebuffer.

Nie testowałem jeszcze tego Clovera dla OptiPlex bo tam jest wymagana jakaś zmiana w BIOS. Nie chcę tego robić, póki co.

@Alpha01 martwi mnie to, że muszę odpalić bootx64.efi z jego strony.

[DKnoto]

@Alpha01 odpaliłem ten bootx64.efi, to GRUB

[DKnoto]

Zmieniłem zmienną. Przygotowałem Clovera tego z githuba. Bootooje z klucza.
Dochodzę do połowy z paskiem postępu pod jabłkiem i mam WIELKI WYBUCH

A potem restart...

[Alpha01]

Pstryknij foto z Verbose.
Waiting for DSMOS powoduje jakiś, może stary FakeSMC.kext.

W Apple podejrzewali, że po przeniesieniu Mac OSX na x86 pojawimy się my z naszymi hackintoshami i oczywiście chcieli tego uniknąć.
W związku z tym wykombinowali sobie szyfrowanie pewnych elementów MacOS X algorytmem AES z użyciem pewnego klucza, który to jest zapisany w SMC.
Przy starcie systemu na Macintoshu Dont Steal Mac OS X.kext pobierze klucz i rozszyfruje zabezpieczone binarki, a przy starcie na PC to nie funkcjonuje, bo nie ma tam układu SMC.
Pomysł niezły, ale w praktyce odczytanie klucza nie było takim dużym problemem, brzmi on:
ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc
Mając już klucz do dyspozycji, powstały takie rozwiązania jak DSMOS.kext albo AppleDecrypt.kext. Oryginalnego kexta wrzucało się na blacklistę, a one zajmowały się rozszyfrowaniem - z tym, że miały one zamknięty kod źródłowy, w niektórych krajach były niezgodne z prawem jako łamiące zabezpieczenia, a poza tym wymagały ingerencji w system, co zawsze może powodować jakieś problemy.
Tak było do czasu opracowania przez netkas FakeSMC.kext, czyli otwarto-źródłowego programowego emulatora układu SMC.
Przy jego użyciu rozszyfrowanie jest realizowane przez oryginalny kext Apple, który z emulowanego SMC odczytuje klucz. Takie jest najważniejsze zastosowanie FakeSMC.

[DKnoto]

No tak. Czytałem już o tym ale dobrze, że przypomniałeś, utrwali się.

Mam fotkę tylko z operacji zmiany zmiennej, zaraz ją wygrzebię i opublikuję. Co do bootowania z opcją -v
to musisz poczekać do jutra, nie mam dostępu teraz do tej maszyny.

Ja w swoim podejściu instalacyjnym zastosowałem VirtualSMC.

Możliwe, że system się restartuje bo nie wykrywa monitora, gościu napisał w readme, że

Know issue

Just one DP port work

you need to switch to an other DP port and reboot, if no DP signal after you see the "white apple" startup logo.

Może wetknąłem nie w ten port.

[DKnoto]

Zmiana wartości zmiennej odbyła się tak:

GRUB-SetupVar0x350.jpg (169.23 KiB) Przejrzano 1599 razy

[DKnoto]

@Alpha01

Faktycznie poprawka „setup_var 0x350 0x2” powoduje, że działa tylko jedno wyjście DP i akurat nie to co dotychczas.

Dodałem opcję „-v” i obejrzałem proces bootowania, niestety przy próbie zainicjowania docelowego karty w trybie
z akceleracją moduł dostaje KP i system się restartuje. W tej chwili nie jestem w stanie zrobić jakiegoś filmu, który
mógłby to pokazać.

Wczoraj na mojej konfiguracji po dodaniu właściwości 00001219 też zaobserwowałem KP ale system stanął i zapisałem
jaki to moduł: AppleIntelSKLGraphicsFramebuffer.

Wracam do wartości 0x1 dla zmiennej 0x350.

[Alpha01]

Wtrąciłem to bo może ktoś jeszcze to przeczyta.
Większość nie wie co właściwie robi dokładnie ten FakeSMC.kext.