MKjanek32

Ewentualnie druga opcja - odpalić na jakimś ARM (do tego czasu może być większy wybór) i próbować emulować w sofcie te specjalizowane układy, jak teraz SMC... Pod warunkiem, że w Macintoshach cały czas będą stosowane układy graficzne choćby od AMD + że pojawią się jakieś inne platformy łączące ARM z dedykowaną grafiką (tego się nie obejdzie, bo stosu graficznego z macOS nie ma nawet porządnie udokumentowanego). I to jest ten moment, kiedy uświadamiam sobie, że na dobrą sprawę te wszystkie kombinacje potrzebne byłyby mi w praktyce tylko do utrzymania swojego środowiska do roboty z dźwiękiem live - które spokojnie mogę też zmigrować na Linuxa, jeden tylko program uruchamiając przez Wine + całą resztę natywnie ?

Mnie zastanawia, czy nie byłoby w takim razie jakiegoś patentu na szybkie wykonywanie kodu dla ARM na x86, który wystartowałby i pociągnął cały OS. Taka trochę hybryda Xena, Clovera i sam nie wiem czego jeszcze W gruncie rzeczy, instrukcje architektur RISC w obrębie CISC się w sporej mierze zawierają - przesłania, działania arytmetyczne i logiczne, itp., do tego x86 ma tyle samo rejestrów ogólnego przeznaczenia (16), a de facto nawet ciut więcej, bo w ARM zalicza się do ogólnego przeznaczenia też licznik programu (Program Counter) i nie wiem, czy nie jakiś jeszcze jeden specjalizowany (nie liczę link register, bo jego i tak trzeba by za pomocą któregoś x86 odwzorować). Główny problem byłby chyba z: -rejestrami stanu i operacjami na nich (każda architektura ma to po swojemu) -kodami warunkowymi (w ARM w zasadzie każdą instrukcję asemblera można wykonać warunkowo - w x86 prawie w każdym przypadku trzeba by to przetłumaczyć na skoki) Chyba najlogiczniejsza byłaby jakaś warstwa abstrakcji, która przy wczytywaniu programu z dysku do RAMu zmapuje raz cały kod maszynowy na x86 i dalej pozwoli to już wykonywać bez interwencji (w przypadku macOS to pewnie musiałoby być kextem). Najpierw jeszcze analogiczna operacja byłaby potrzebna dla samego jądra i to w takim razie musiałoby być rozwiązane gdzieś na poziomie bootloadera. Gdyby to zadziałało, ładowanie wszystkiego trwałoby sporo czasu, ale później praca z softem nie powinna się wiązać ze szczególnymi spadkami wydajności. Tylko pozostawałaby kwestia sterowników do sprzętu...

Witam wszystkich po przerwie (trochę tego zeszło, prawie cały semestr...) - i od razu zamieszczam krótki poradnik. Otóż jak może wiecie, w wersji macOS Sierra 10.12.4 przestały działać dwa często stosowane na laptopach ze zintegrowanymi układami graficznymi Intela sposoby "popychania" regulacji podświetlenia ekranu - pierwszy wykorzystujący ACPIBacklight.kext, a drugi IntelBacklight.kext. Za to działa oczywiście w pełni natywna metoda, bazująca na systemowym sterowniku AppleBacklight.kext - tyle, że do jego prawidłowej pracy potrzebna jest odpowiednie skonfigurowanie systemu. I tym właśnie zajmiemy się w tym poradniku. 1. Modyfikacja DSDT Pierwszą potrzebną rzeczą jest specjalna wersja poprawki PNLF w DSDT. Z klasyczną wersją wprawdzie regulacja też działa, ale w pełnym dostępnym zakresie dopiero po wybudzeniu z uśpienia - wcześniej ekran jest lekko przyciemniony, mimo ustawienia jasności na maksimum. Otwieramy więc w ulubionym edytorze nasze DSDT i zaczynamy od zmiany nazwy zintegrowanego układu graficznego (i wszystkich odwołań do niego) na IGPU. Sekcja integry znajduje się wewnątrz Device (PCI0) i posiada adres 0x00020000. W zależności od laptopa może się nazywać różnie, najczęściej Device (GFX0) albo Device (VID). Czasami (na przykład na moim ThinkPadzie) urządzenie VID może występować dwa razy: jedno dla zintegrowanej karty, drugie pod portem dla ewentualnej dedykowanej - nawet w modelu z samą zintegrowaną. Wtedy oczywiście wystarczy zmienić nazwę tylko tego pierwszego. Następnie wewnątrz sekcji IGPU (na przykład przed zamykającym nawiasem klamrowym) dodajemy taki fragment kodu: OperationRegion (RMPC, PCI_Config, 0x10, 4) Field (RMPC, AnyAcc, NoLock, Preserve) { BAR1,32, } Device (PNLF) { // normal PNLF declares (note some of this probably not necessary) Name (_ADR, Zero) Name (_HID, EisaId ("APP0002")) Name (_CID, "backlight") Name (_UID, 10) Name (_STA, 0x0B) //define hardware register access for brightness // you can see BAR1 value in RW-Everything under Bus00,02 Intel VGA controler PCI // Note: Not sure which one is right here... for now, going with BAR1 masked //OperationRegion (BRIT, SystemMemory, Subtract(^BAR1, 4), 0xe1184) OperationRegion (BRIT, SystemMemory, And(^BAR1, Not(0xF)), 0xe1184) Field (BRIT, AnyAcc, Lock, Preserve) { Offset(0x48250), LEV2, 32, LEVL, 32, Offset(0x70040), P0BL, 32, Offset(0xc8250), LEVW, 32, LEVX, 32, Offset(0xe1180), PCHL, 32, } // _INI deals with differences between native setting and desired Method (_INI, 0, NotSerialized) { Store(ShiftRight(LEVX,16), Local1) if (LNotEqual(0x710, Local1)) { Divide(Multiply(LEVL, 0x710), Local1,, Local0) //Store(P0BL, Local1) //While(LEqual (P0BL, Local1)) {} Store(Local0, LEVL) Store(0x7100000, LEVX) } } } UWAGA: jeżeli wcześniej dopisywaliśmy inną wersję poprawki PNLF, klasyczną lub dla ACPIBacklight.kext - należy ją oczywiście najpierw usunąć Kompilujemy i wrzucamy plik DSDT.aml do odpowiedniego katalogu Clovera. 2. Binpatch AppleBacklight.kext w Cloverze W kolejnym kroku dodajemy do naszego config.plist w sekcji KernelAndKextPatches -> KextsToPatch następujący binpatch: <dict> <key>Comment</key> <string>change F%uT%04x to F%uTxxxx in AppleBacklightInjector.kext (credit RehabMan)</string> <key>Name</key> <string>com.apple.driver.AppleBacklight</string> <key>Find</key> <data>RiV1VCUwNHgA</data> <key>Replace</key> <data>RiV1VHh4eHgA</data> </dict> 3. AppleBacklightInjector.kext Na koniec pobieramy z załącznika i instalujemy AppleBacklightInjector.kext w katalogu Clovera z kextami lub w /S/L/E. Jeżeli mamy któryś z poprzednich kextów (ACPIBacklight.kext lub IntelBacklight.kext) - musimy go oczywiście usunąć. Restartujemy system - i regulacja podświetlenia powinna działać. Pomiędzy kolejnymi uruchomieniami systemu ustawienia podświetlenia są przechowywane NVRAM - więc jeżeli mają być pamiętane, odczyt i zapis do NVRAM musi działać u nas prawidłowo. W razie wątpliwości czy problemów, pomocne może okazać się przejrzenie wątku z oryginalnym tutorialem RehabMana, na wszelki wypadek podaję link: https://www.tonymacx86.com/threads/guide-laptop-backlight-control-using-applebacklightinjector-kext.218222/ AppleBacklightInjector.kext.zip

OK, już wiem o co chodzi. Windows przy okazji operacji na partycjach poustawiał wszędzie (oprócz partycji EFI i swojej Microsoft reserved) flagę msftdata - dzięki czemu macOS w ogóle nie sprawdza, jaki system plików znajduje się na partycji, tylko z automatu uznaje ją za windowsową. Wystarczyło za pomocą GParted wyrzucić flagę z tych partycji, gdzie być jej nie powinno - i wszystko zaczęło działać. Później jeszcze trzeba było ukryć z powrotem partycję recovery, ustawiając jako Apple_Boot - komenda: sudo asr adjust --target /dev/diskXsX -settype Apple_Boot gdzie diskXsX to numer naszej partycji (możemy sprawdzić za pomocą polecenia diskutil list).

Ponieważ będę instalował na moim ThinkPadzie trzeci system, musiałem przeorganizować trochę podział na partycje. Generalnie: do tej pory miałem EFI, HFS+ system, HFS+ recovery i 2x NTFS. W miejsce ostatniej partycji NTFS potrzebowałem utworzyć 3: swap, partycję pod Linuksa i mniejszą partycję NTFS. Najpierw spróbowałem zrobić wszystko z poziomu macOS - na tyle, na ile da się w nowym Narzędziu dyskowym, tzn. sformatowałem partycję NTFS jako HFS+, po czym podzieliłem ją na 3, również HFS+ (w tej chwili z tego co widzę, nie można zostawić wolnego miejsca, niezbyt rozumiem ideę) coby nie tworzyć FAT32 i nie założyć przypadkiem hybrydowych tabeli. Po tych operacjach okazało się, że z poziomu Windowsa nie mogę jednej z nowo utworzonych partycji sformatować jako NTFS - więc usunąłem wszystkie 3 i dla testu zrobiłem restart do OS Xowego Recovery - normalnie się uruchomił i wyświetliłem w Narzędziu dyskowym obecny podział. Po czym spróbowałem uruchomić macOS - przy starcie dostałem Still waiting i od tego momentu nie mogę uruchomić ani systemu, ani recovery. Pod Windowsem partycja systemowa macOS prawidłowo jest rozpoznawana (mam zainstalowane sterowniki do HFS z Boot Campa), także na wszelki wypadek zrobiłem z niej backup ważniejszych danych i dokończyłem podział na partycje (założyłem opisane wcześniej 3, ale z poziomu Windowsa). Na koniec, żeby zobaczyć co jest grane, odpaliłem instalator 10.9 (akurat pendrive z tym miałem pod ręką) - i co ciekawe, wygląda na to, że OS X nie rozpoznaje prawidłowo systemu plików na partycjach HFS+ - Narzędzie dyskowe wyświetla je bez nazwy, jako FAT32. Macie pomysł co się dzieje i czy można coś z tym zrobić bez instalacji macOS od nowa? Tak jak pisałem, w razie czego mogę bez problemu backup z poziomu Windowsa zrobić i stawiać od nowa, ale nie chce mi się - a wygląda na to, że sam system plików jest w porządku, tylko gdzieś indziej coś się schrzaniło. Edycja: W załączniku: jak partycje są rozpoznawane przez Mac OS X, a jak przez Linuksa już po sformatowaniu swapa i przyszłej systemowej. Wygląda na to, że Linux widzi wszystko prawidłowo (to samo wyświetla gdisk).

Na podanej przez Ciebie stronie jest link do Bitbucketa, gdzie publikowane są wersje skompilowane. Ale widzę, że w tej chwili coś na Bitbuckecie nie działa i pojawia się błąd 404, chociaż do plików można się dostać z kopii Google - wrzucam najnowszą wersję w załącznik. Sprawdź jeszcze, czy w odpowiednim katalogu Clovera na pewno nie masz kextów. RehabMan-Voodoo-2016-1208.zip

Masz kexty do PS2 (VoodooPS2)?

Jak to właściwie działa, wtedy karta AMD jest i tak wykorzystywana do renderowania grafiki 3D?

Partycja EFI nie jest tworzona przy instalacji Clovera, tylko zawsze przy zakładaniu na dysku schematu partycji GPT. Narzędzie dyskowe jej nie pokazuje, ale jak uruchomisz Terminal i wpiszesz komendę diskutil list powinieneś ją zobaczyć. Montujesz za pomocą komendy: diskutil mount /dev/rdiskXsX Gdzie zamiast X wpisujesz liczby, które przy partycji EFI wyświetla poprzednia komenda - u mnie to jest np. /dev/rdisk0s1. Żeby zainstalować na dysku Clovera, najprościej będzie skopiować katalog CLOVER z katalogu /EFI na pendrive do katalogu /EFI na partycji EFI oraz plik /EFI/BOOTX64.efi z pendrive do katalogu /EFI/BOOT na partycji EFI. Problemy z iMessage to już raczej kwestia niewłaściwych numerów seryjnych w sekcji SMBIOS w config.plist Clovera..

Masz problem ze Still waiting for root device. Spróbuj na początek zmienić port USB i zobacz, czy z któregoś nie ruszy.

Swoją AR5BXB72 występuje też w wersji brandowanej przez Lenovo, którą do tej serii ThinkPadów można włożyć przy oryginalnym BIOSie, ale pewnie trudniej byłoby ją dostać.

Tak: http://hamac.pl/topic/11249-dualboot-clover-mac-os-x-i-windows-w-uefi-na-jednym-dysku/

Ad 1. Spokojnie powinien działać, to po prostu zwyczajny chip Broadcoma stosowany też na innych kartach + w ostateczności zawsze można wykorzystać sterowniki z Boot Campa. Ad 2. Z tego co kojarzę generalnie powinny normalnie działać, ale nie wiem, jak np. jest z konfiguracją gestów Magic Mouse pod Windowsem.

Raczej dokup, karty na USB sensownie nie odpalisz. O ile w ogóle są do niej sterowniki, do łączenia będzie potrzebny oddzielny program. A karty wewnętrzne na PCI i PCI-Express są obsługiwane natywnie przez system jako AirPort.

NVRAM jest też potrzebny w procesie instalacji albo aktualizacji wydania macOS, więc jeżeli nie działa natywny, potrzebny jest emulowany (sterownik EmuVariableUefi-64.efi dla Clovera). Ale na płytach głównych z UEFI nie powinno być problemu z odczytem/zapisem do natywnego NVRAM, emulacja jest zawsze potrzebna w przypadku płyt z BIOSem.