Jump to content

314TeR

Administrators
  • Content Count

    18333
  • Joined

  • Last visited

  • Days Won

    339

Everything posted by 314TeR

  1. Szczerze? Na tym etapie to wg mnie nie ma sensu. Czemu? Bo OpenCore dość dynamicznie się zmienia i każda nowa wersja np 0.5.0, 0.5.1 i obecna 0.5.2 wprowadza zmiany dość istotne i do składni i w ogóle pojawiają się nowe opcje. Poradnik jest z głową opisany i wystarczy użyć tej wkładki między uszami aby w parędziesiąt minut zrobić sobie samemu wsad. Jak przygotujesz gotowca, to zwalniasz z myślenia ludzi. W przyszłości jak składnia się co nieco wyklaruje i ustabilizuje to można będzie przygotować gotowce. Mi samemu nie bardzo się chce przygotowywać pod inne platformy, bo pracy raz że jednak jest sporo, a bez dostępu do sprzętu ciężko weryfikować i dopieszczać. Zresztą zobacz jaki jest odzew w tym wątku. 12 poprań przez 4-ry dni z czego odpisało 2 stałych bywalców.
  2. Powinno dać się odpalić w pełni macOS. Aczkolwiek maks 10.13.6 ze względu na VGA. Karty sieciowej nie znam, na jakim jest chipsecie? Czy ta płyta ma już BIOS UEFI czy jeszcze legacy?
  3. Config jest zrobiony na basie sampla dostarczanego z OpenCore. Najprościej różnice wyłapać otwierając domyślny config i w/w w jakimś programie do porównywania składni i porównać configi. Ja używam do tego BBEdit. Natomiast różnic względem tego co jest opisane w podlinkowanej instrukcji jest niewiele. Głównie są to poprawki do wyświetlania poprawnie trybu tekstowego i graficznego ładowania OpenCore.
  4. Wiem. Wystarczy np dodać tablicę SSDT.aml z konfiguracją portów USB i kabum... wylatuje licencja. Podobnie spoof MAC addressu karty sieciowej - puf i po licencji. Tylko bez paniki - po prostu po odpaleniu Windows z OpenCore pyszczy on, że nie został aktywowany. Odpalenie go bezpośrednio z BIOS jest OK i jest aktywowany.
  5. Rozumiem idee i co masz na myśli, i ją bardzo mocno wyznaję. Z takiego powodu właśnie powstał UniBootX, nie po to aby było skomplikowanie, ale po to aby skomplikowaną czynność jak tworzenie zestawu startowego sprowadzić do paru niezbędnych czynności. Moja wypowiedź jest tożsama tylko do tego szczególnego wypadku OC i OCC. W obu wypadkach i tak aby cokolwiek wprowadzić, musisz wiedzieć co wprowadzasz. W OpenCore jeszcze większy jest na to położony nacisk, ale ułatwia to świetna dokumentacja. Taki konfigurator to front end do jakiegoś configu. Tu aby cokolwiek zrobić i tak musisz mieć bazę i to najlepiej zbliżoną do posiadanego sprzętu wypadku. W obu konfiguratorach NIE da się zbudować configu od zera. D;atego uważam, że te programy są świetne, ale w praktyce ułatwiają głównie początkującym użytkownikom zapoznanie się i wprowadzenie zmian. Zaawansowany użytkownik szybciej okiełzna taki config wspomagając się zwykłym edytorem pilnującym składni XML jak np PlistEdit, niż w CC/OCC. OC i OCC to klikacz, żeby np zdublować jakiś wpis, musisz wpierw dodać wiersz (+), potem wpisać w kolumnę A, potem B, potem C, potem D... ufff następny wiersz, kiedy to w PlistEdit robisz CMD+C-->CMD+V i zmieniasz tylko to co potrzeba. Nie wierzysz, spróbuj wpisać "z ręki" chociaż 3, 4 wiersze w patchach do USB jak wyjdzie nowy system i będziesz musiał dodać wpisy dla nowej wersji kernela. Ale żeby nie tylko narzekać a coś sprawdzić odpaliłem przed chwilą OCC i sprawdziłem co robi. Ogólnie nie jest źle, aczkolwiek niestety są drobne błędy. Najpoważniejszy to samodzielna zamiana wpisu: <key>ConsoleBehaviourOs</key> <string>ForceGraphics</string> na <key>ConsoleBehaviourOs</key> <string>ForceText</string> Druga rzecz - to zrobienie lekkiego bałaganu w sekcji PlatformInfo - Oprócz istniejącej sekcji Generic jak jest pokazane w dokumentacji, OCC pododawał sam z siebie sekcje DataHub, PlatformNVRAM, SMBIOS z zdublowanymi danymi z Generic. Tu zaznaczam, że trzeba się zapoznać z dokumentacją co te sekcje robią, bo są powielone SNy czy MLB, etc... trzeba się dowiedzieć, która sekcja za co odpowiada, bo być może te działanie ma sens którego obecnie ja nie znam. Poza tym nie podoba mi się, że OCC usuwa wszystkie klucze których wartość jest NULL. Ja osobiście wolę mieć klucz i wartość NULL, ponieważ jak będę potrzebował dodać wartość do klucza, to nie muszę wpierw dodawać klucza, szukać gdzie on powinien być, jak się nazywa itp itd. Jak jakiś klucz w configu jest to niech on zostanie. Tu widać, że autor/autorzy OCC stawiają na swoją logikę i do takiego zachowania CC i OCC najbardziej mam zastrzeżenia.
  6. Inaczej - bo faktycznie moja wypowiedź wygląda jakbym siał jakimś defetyzmem. Jeszcze raz od początku. OpenCore i Clover Configurator to narzędzie ułatwiające początkującym użytkownikom ogarnięcie skomplikowanych configów w formacie XML. Zwalniają one przede wszystkim z znajomości składni XML a wiec i popełnienie potencjalnych błędów technicznych składni jak i merytorycznych. Niestety te programy obsługują parametry takie jakie zaprogramuje im autor tej aplikacji. Jeśli składnia jakiegoś parametru się zmieni, zostanie dodana lub usunięta to OCC/CC musi te zmiany uwzględniać. Tu niestety nie jest tak pięknie. Nawet dla znanego od lat Clovera CC nie wspiera wszystkich parametrów. Podobnie może być dla OpenCore o czym uprzedzają autorzy którzy testowali tę aplikację. Nie mniej autor OC Configuratora wciąż nad nim pracuje i jest dynamicznie rozwijany. Jakiś miesiąc temu OC Configurator wspierał wersje 0.0.x kiedy były już 0.5.0 i 0.5.1. Dziś widzę, że wspiera już 0.5.2. Być może już moje słowa i autorów OC dotyczące psucia składni są nieaktualne. Nie mniej OpenCore się dynamicznie rozwija i paradoksalnie bezpieczniej wziąć przykładowy config i go poprawić ręcznie. I to najlepsze wyjście i paradoksalnie takie podejście jest o wiele prostsze niż z Cloverem. Zasadniczą różnicą takiego podejścia jest to, że przykładowy config z clovera jest sieczką, a przykładowy config z OpenCore jest bardzo logicznie poukładany i paradoksalnie dostosowanie do naszych potrzeb sampla OpenCore jest o wiele prostsze niż sampla Clovera. Na dziś najlepiej edycję configu z OpenCore polecam robić jakimś edytorem XML podpierając się dokumentacją dostarczoną z OpenCore. Przed użyciem OCC zrobić kopie, sprawdzać, czy coś nie uciekło. Szybko i wygodnie porównać 2 pliki można w np BBEdit.
  7. A może wpisały Ci się jakieś śmieci do NVRAM/BIOSu gdzie są ustawienia do wybudzania z ACPI. Spróbuj przeflashować BIOS od zera.
  8. OC Configurator nie jest w pełni kompatybilny z aktualnymi wersjami OpenCore - nawet autorzy OpenCore ostrzegają! W większości wypadków psuje config.plist. Uważajcie co robi!
  9. Power Nap wyłączone? Budzenie przy dostępnie przez sieć też?
  10. Pierwsza przymiarka do bazy nowego UniBootX bazującego na OpenCore. Wersja ta bazuje na oficjalnej wersji OpenCore 0.5.2 + AppleSupport 2.1.2 + VirtualSMC 1.0.9 - kexty są aktualne na dzień 6.11.2019r. Z góry proszę o wyrozumiałość i zgłaszanie uwag - tylko z głową - to jest nie dość, że wczesna wersja OpenCore, to też jest to moja pierwsza przymiarka aby dać Wam z grubsza config pozwalający odpalić macOS na Haswellu Z87 Z97 bez względnie doktoryzowania się. Są 2 configi: config HD4600.plist - użyć jak korzystamy tylko z iGPU HD4600 config dGPU plus HD4600.plist - użyć jak korzystamy z dGPU i chcemy odpalić z HD4600 bez wyjść aby działał poprawnie np Quick Sync lub VDADecoder Wybrać stosowny config i zmienić jego nazwę na: config.plist Bez poprawienia nazwy configu NIE odpalimy w ogóle OpenCore. Domyślny Timeout ustawiony na 30s Do zestawu dodatkowo dodane: USBMap - skrypt do generowania tabeli SSDT dla portów USB - do opisania w innym poradniku. macinfo 2.0.8 w wersji na macOS jaki i Windows - jest to pakiet pozwalający wygenerować POPRAWNĄ parę SystemSerialNumber i MLB - to SĄ PARY i potem je dodać do w/w configu! Przed opaleniem należy w configu odnaleźć poniższą sekcję: <key>PlatformInfo</key> <dict> <key>Automatic</key> <true/> <key>Generic</key> <dict> <key>MLB</key> <string>M000000000001</string> <key>ROM</key> <data>ESIzAAAA</data> <key>SpoofVendor</key> <true/> <key>SystemProductName</key> <string>iMac14,2</string> <key>SystemSerialNumber</key> <string>W0000000001</string> <key>SystemUUID</key> <string>00000000-0000-0000-0000-000000000000</string> </dict> <key>UpdateDataHub</key> <true/> <key>UpdateNVRAM</key> <true/> <key>UpdateSMBIOS</key> <true/> <key>UpdateSMBIOSMode</key> <string>Create</string> </dict> I uzupełnić numery generując np w macinfo lub przenosząc z swojego configu clovera. Do uzupełnienia są od góry MLB, ROM, SystemSerialNumber, SystemUUID. Przygotowanie pendrive: sformatować na Fat32 wypakować do głównego folderu tak aby w nim był folder EFI. Działać i pisać wrażenia. UniBootX_OpenCore_Haswell_Z87_Z97_-_pre_Alpha_0.1.zip
  11. Szukam... gdzieś mi się jak na złość zapodział testowy pendrive z OpenCore. EDIT - Znalazłem - dajcie mi z pół godzinki, zaktualizuję do obecnej wersji, abyście mieli najświeższą wersje.
  12. Plusy Bardziej przemyślana konstrukcja. To czy dany sterownik czy kext jest ładowany czy nie decyduje wpis w configu, dzięki temu nie trzeba mieć osobnych katalogów dla kextów, np osobnych w 10.13 i 10.14, tylko wszystko definiuje się w configu. Świetna, wręcz rewelacyjna dokumentacja - naprawdę wystarczy RTFM aby wedzieć co i do czego służy. Każda wersja też ma informacje o zmianach. Prawidłowa obsługa BLESS - wreszcie macOS instalując czy aktualizując NIE trzeba pilnować aby wybierać "Install macOS from XYZ". W Cloverze w ogóle to nie działa prawidłowo już od paru wydań macOS i nie da się zainstalować automatycznie aktualizacji. Aktualizacje i instalacja wymaga wybierania właściwej opcji, tu OC sam to robi, a w Cloverze trzeba pilnować ręcznie. Inaczej zrealizowane ładowani kextów, wg autorów lepiej - są dwa zasadnicze aspekty na plus, pierwszy to jak ładuje się kext do LANu to nie trzeba wymuszać popychać IONetworkFamily, drugi to NIE trzeba wyłączać SIP, oba te aspekty to spory plus. Szybsze ładowanie systemu i mniej sterowników EFI Obsługa prawidłowa wyboru startu przez dysk startowy z preferencji. Obsługa skrótów klawiszowych podczas startu jak na maczku - CMD + V, ALT, CMD + R itd. Ponoć lepsza obsługa FileVault2 - nie wiem nie korzystam, ciężko mi się wypowiedzieć. Wbudowane patche na limit portów - nie trzeba podawać pierdyliarda wpisów, a włącza się tylko 1 opcję. Minusy - to zakładam, że będzie poprawione Dla mnie najistotniejszy to ładowanie poprawek do tabel ACPI, czy też customowych tabel SSDT nie tylko w macOS ale też i w wszystkich pozostałych systemach, w tym i Windows. Dla jednych "future" - tak to autorzy OC przedstawiają - dla mnie potęzny minus, bo wystarczy np załadować tabelę SSDT z funkcją wyłączania kontrolerów EHCI od USB i bum - wylatuje aktywacja Windows i trzeba ponownie aktywować. Sęk w tym, że jak mamy klucz no to OK, można przeboleć i zainstalować, ale jak mamy np licencję elektroniczną już w fabryce przypisaną do komputera (np każdy nowy notebook) to takiej licencji nie popchniemy. Ja bym chciał aby wymuszanie ładowania poprawek do DSDT, SSDT i innych tweaków dla wszystkich systemów było opcjonalne i żeby można było to wyłączyć. Mocno rozbudowany config w XLM i miejscami może być dla wielu konfudujący. Wiele opcji kluczowych, jest na początku "dziwnie" rozlokowanych, np Boot Argsy ukryte pod kluczem UUID odpowiadającego wpisu w NVRAM. Jak się tego nie wie, to można sobie poszukać. Generalnie okiełzanie OpenCore wymaga poświęcenia czasu, nie ma wyjścia i trzeba parę godzin poświęcić na zapoznanie się z dokumentacją. Jak ktoś to zrobi, to wiedza potem procentuje, bo trzeba wyprostować i poukładać sobie logikę OC w głowie. Siermiężny wybór systemu - jak wciśniemy ALT lub wymusimy pokazanie systemów do rozruchu - to pokazuje się lista np 3 - 4 pozycje od góry ponumerowane 1. 2. 3. ale nie ma żadnego znacznika który aktualnie jest wybrany do rozruchu. Tak samo jak ustawiony jest timeout to nie widać ile czasu jest odliczania. Zmiana rozruchu odbywa się wciskając klawisze 1, 2, 3 itd. Mam nadzieję, że to wkrótce zostanie usprawnione - mi osobiście NIE zalezy na kolorowych skórkach, ale niech minimalna obsługa zostanie zachowana. OpenCore preferuje VirtualSMC zamiast FakeSMC - podstawowe funkcje VirtualSMC spełnia - niestety nie ma pluginu do odczytu temperatur, wiatraków, etc z VGA. Dodatkowa uwaga - bo nie mogę tego uznać jako minus, a jako wymóg - OpenCore wymaga poprawnie działającego NVRAM, także np na Z97 z zablokowanym BIOSem lub Z390 ja bym się nie pokusił o stawianie. W teorii można, bo jest emulator, ale emulator NIE załatwi wszystkiego. Dodatkowo mi się zdarzały restarty po wybudzeniu z sleep, których nie miałem w cloverze - ale tego dokładnie nie zdiagnozowałem, krótko testowałem OC na Z97 i była to jedyna bolączka. Poza tym OC działał mi naprawdę zaczie. Gdyby nie problem z wywalającą się licencja elektroniczną na Windows szczerze mówiąc już bym miał OC na co dzień, a tak nie chce mi się walczyć z ponownymi aktywacjami czy reinstalacjami Windows. Mam w nim parę programów aktywowanych które są o wiele droższe niż sam Windows. PS Zaraz wrzucę Config przykładowy dla Z87/Z97.
  13. Na Z390 ani OpenCore ani Clover nie zapewnia nvramu. Config dla Z97 wrzucę wieczorem jak będę mógł - mam przygotowany tak co nieco...
  14. Tych programów 32 bitowych jest masa. Zanim wszystkie autorzy przepiszą do 64 bit minie masa czasu, a część z nich nigdy się tego nie doczeka. Na razie przejście na 10.15 wg mnie jest jednym z bardziej problematycznych. O ile o aplikacje z Mac App Store raczej nie powinniśmy się martwić, to np starsze wersje Microsoft Office jak np wersja 2011 to wersja wyłącznie 32 bit...
  15. Dyskusję na temat OpenCore lepiej przenieść do tego tematu:
  16. No właśnie - przechodzić na OpenCore już czy nie? OpenCore - testowałem go już trochę i generalnie jestem pod dużym wrażeniem. Jeśli chodzi o macOS to jest bardzo dobrze, a nawet lepiej w paru kluczowych aspektach względem Clovera. A jakie są Wasze doświadczenia?
  17. Wątek do dyskusji ogólnej o OpenCore, przemyślenia, przechodzić, nie przechodzić. Do dyskusji na temat konkretnych problemów z własną konfiguracją czy sprzętem najlepiej założyć osobny temat. Tutaj piszmy na tematy ogólne.
  18. To nie musisz zmienić. Jedynie usuń zbędne dane. Pozostaw model, serial i serial płyty oraz SMUUID. Resztę zostaw aby podstawiał clover. Zaktualizuj go tez jak i wszystkie kexty.
  19. A jaki SMBIOS masz obecnie?
  20. Tak, HD4000 odpalisz i będzie działała bardzo przywozicie.
  21. Odpal macOS z pendrive. Pobierz Clover Configurator i nim zamontuj partycje EFI. Windows w swojej bezmyślności często niszczy zawartość partycji EFI formatując ja przy instalacji lub aktualizacji.
  22. Instalator jest podpisany certyfikatem który wygasł. Stąd konieczność zmiany daty. Trzeba pobrać od nowa instalator z Mac App Store.
  23. Załóż termopady i radiatory. Samsungi 970 się mocno grzeją. Naklejki nie powinny przeszkadzać.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.