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.

Można instalować na tym samym dysku: http://hamac.pl/topic/11249-dualboot-clover-mac-os-x-i-windows-w-uefi-na-jednym-dysku/ O karcie graficznej nic niestety nie powiem, bo nigdy Quadro się nie zajmowałem. Możliwe, że będą potrzebne sterowniki ze strony NVIDII - ale pewny nie jestem.

Powinno się dać zainstalować, łącznie z najnowszą Sierrą. Radeona raczej nie uruchomisz (chyba, że w UEFI możesz wyłączyć przełączanie kart graficznych), zostaje integra HD 4000. I tyle na ten moment mogę powiedzieć, nie podałeś odpowiednio informacji o karcie dźwiękowej/sieciowej LAN/sieciowej WLAN - najlepiej zrób listę sprzętu w 10 punktach wg: http://hamac.pl/topic/1976-jak-zrobi%C4%87-list%C4%99-konfiguracji-sprz%C4%99tu/ Ale z sieciową i dźwiękową raczej problemu nie będzie, z WiFi już może być różnie, dużo zależy od modelu karty.

Przy czym te sterowniki działają do 10.10 Yosemite, na razie nie poradzili sobie z przepisaną obsługą USB w El Capitanie i nowszych.

Kiedyś próbowałem i nie udało mi się zmusić tego do działania, ale z tego co pamiętam, niektórzy pisali na InsanelyMac, że u nich działa. Więc może da się jednak coś tu wykombinować...

Powinno dać się zainstalować, przy czym z kart graficznych do uruchomienia będzie tylko integra HD 4400. O reszcie sprzętu (karta dźwiękowa/sieciowa/WiFi) nie mogę nic powiedzieć, bo nie podałeś listy. Ale zapewne dźwiękowa będzie do uruchomienia (patchowany systemowy AppleHDA.kext albo najnowsza wersja VoodooHDA.kext), sieciowa raczej też, natomiast z WiFi to już dużo zależy od tego, jaką konkretnie masz kartę. Jeżeli Intel - nie zadziała na pewno, musiałbyś wymienić na jakąś kompatybilną.

Do instalacji przyda Ci się pendrive z UniBootX (bootloader Clover + odpowiednie kexty i pliki konfiguracyjne) - poszukaj na forum w odpowiednim dziale.

Cześć, teoretycznie możesz próbować stawiać coś do eksperymentów (najprościej jakąś dystrybucję), ale do stabilnej pracy ten sprzęt się nie nadaje - potrzebna byłaby platforma z procesorem Intela. Na AMD potrzebne jest zmodyfikowane jądro + pewnych rzeczy (zarządzanie energią Quiet'n'Cool, uśpienia, itd.) i tak się nie uruchomi.

Wrzuć jeszcze raz zdjęcie komunikatu, to co wstawiłeś poprzednio, to nie był załącznik, tylko jakiś link, który i tak nie działał.

Wsparcie ma, natomiast artefaktów wykluczyć nie można, z tego co słyszałem mogą wystąpić nawet na Macach - coś jest skopane z obsługą tych kart. Słyszałem kiedyś opinię, że problem artefaktów dotyczy laptopów z ekranem o rozdzielczości wyższej niż 1366x768 i w takim przypadku pomaga wstrzyknięcie (w Cloverze albo w DSDT) odpowiedniego EDID. U siebie mam właśnie 1366x768 i przez cały okres pracy na 10.9 Mavericks rzeczywiście nie przypominam sobie ani jednego artefaktu. Ale już na 10.10 Yosemite i teraz 10.11 El Capitan sporadycznie artefakty się pojawiają, z tym że tylko od czasu do czasu, jakoś bardzo mocno nie uniemożliwiają pracy. Właśnie testuję różne rozwiązania (m. in. zmiany niektórych bitów w EDID), ale na razie nie jestem w stanie potwierdzić skuteczności żadnego z nich. Poza podmianami EDID na artefakty (przynajmniej zmniejszenie ich ilości) rzekomo ma pomagać: -flaga slide=0 -zmiana ilości VRAM karty graficznej (bodajże można to ustawić gdzieś w Cloverze)

Instalowałeś czystego Clovera, czy UniBootX? Jeżeli UniBootX to musisz zastosować się do procedury z wątku podanego przez 314TeR, czyli sprawdzić nazwę OEM płyty głównej i zmienić na nią nazwę katalogu z folderu OEM w Cloverze, który najbardziej odpowiada Twojemu sprzętowi. Jak już to zrobisz, reszta wygląda dla obu przypadków podobnie, próbujesz uruchomić i w razie czego jeżeli coś nie idzie, zmieniasz jakieś konkretne ustawienia, które mogą mieć wg Ciebie znaczenie.