A23SS4NDRO

Avevo sistemato anche ssdt EC e vega_navi, mi mancava solo provare la mappatura, pensavo di trovare qualche ssdt tra le ACPI, poi mi son ritrovato in questa situazione... Spero di risolvere presto, comunque niente di eccessivamente critico ecco Allego tutto, grazie per l'aiuto, sto uscendo fuori pazzo 😅 origin.zip EFI-3600X-precedente.zip

Usando 0.5.7 o 0.5.6 non va?

Sistemati le opzioni seguendo la guida - Per creare la USB da windows / linux / macOS : per sapere quali driver e kext potrebbero servirti: Per sistemare il config.plist: https://khronokernel-2.gitbook.io/opencore-vanilla-desktop-guide/amd-config.plist/amd-config

Può essere forse questo? https://github.com/acidanthera/bugtracker/issues/516

Utilizza Propetree per Windows (propertree.bat) e riparti da Sample.plist

Ciao a tutti ragazzi, posto qui un'esperienza avuta cercando di aiutare un ragazzo online con hardware AMD -CPU Ryzen 5 3600X -GPU Sapphire RX5700XT -Motherboard Asus Prime X470 Pro Ho configurato correttamente Opencore per l'avvio, impostazioni del BIOS corrette ecc. Ecc. Tutto è andato bene fino a quando non ho avviato una usb con nulla tranne una generica EFI di clover solo per estrarre le ACPI usando F4, estraendo l'audio con audiodxe.efi e usando F8, quindi resettando nvram con F11 per pulire l'ipotetica residuo lasciato dal lavoro fatto con quella usb e poi ho spento la macchina. Ho provato ad avviarlo da disco interno dove ho sempre avviato, ora posso raggiungere la GUI di opencore ma non riesco piu ad acciare, si blocca (screenshot di sotto) Ho cercato di ripristinare le impostazioni del BIOS, di aggiornare il BIOS, di eseguire l'avvio da USB con la prima versione della EFI che sono riuscito a far avviare, ma macOS si inchioda su questa schermata qui (parliamo di OC 0.5.6 e 10.15.3, niente beta) Cosa potrebbe essere? Intanto provo ad aggiornare le patch kernel

Ci ho parlato tempo fa (7 marzo) su telegram, la Kingston è una USB avviabile, penso che abbia bisogno di un Mac vero per fare la USB con il .pkg oppure dovrà usare dd per scrivere su MBR, dal momento che se disabilita la CSM mettendo Windows 8 mode gli sparisce la USB e gli compare una entry fasulla "Mac OS X" Dovrebbe entrare da EFI Shell per sistemare, ma dal momento che appunto ha problemi essendo una Motherboard in po' ibrida, gli ho chiesto di documentare tutto qui sul forum Inoltre VT-d non è disattivabile purtroppo, forse disattivando VT-x (Intel Virtualization Technology Normale) potrebbe cadere anche la voce per ora non disattivabile (Virtualization Technology for Direct I/O) Comunque se non fosse possibile si risolve con Drop DMAR

Attenzione per aggiornamenti di hack AMD a 10.15.4 Beta 6, alcuni riportano che Algrey debba aggiornare le patch P.S. con 10.15.4 Beta 6 hanno aggiunto supporto per ice lake

Ciao, ottimo che hai riportato il post qui... Sono contento che ora hai una configurazione più stabile e affidabile di come era prima, (il lettore deve sapere che la prima volta che abbiamo provato a mappare le USB 3.0 non spuntavano proprio su IOreg, sebbene la Port patch limit fosse corretta e ci fosse Usbinjectall - kext che ho scelto di non usare più alla prossima e in tutte le prossime mappature poiché la/le Port patch limit fanno il loro lavoretto indipendentemente da quel kext deleterio cit @Gengik84 😄 ) @vulcano sì è dovuto mettere con la santa pazienza a reinstallare da capo, sebbene avessi già sistemato l'ssdt della mappatura con il metodo di Gengik - anche se non apparivano su ioreg avevo intuito che si poteva usare questo metodo: Per dedurre le porte SSxx corrispondenti che dovevano spuntare sulla suo ioreg, sebbene tutto fosse fatto a dovere, è di dirgli di staccare tutti i device usb, aprivo io ioreg da TeamViewer, pennetta (usb3) andava a inserirsi su tutte le porte (solo blu) in modo da vedere quali device spuntavano sotto HSxx e in tal modo avrei capito che le stesse porte HSxx sarebbero state con lo stesso numero xx quando in modalità 3.0 Ad esempio se lui si collega su una USB 3.0 dietro e mi appare come HS01, so per esperienza quando mappavo con la mia build che il numeretto permane e cambia solo la velocità quindi la porta corrispondente 3.0 che sarebbe dovuta spuntare era SS01 Quindi ho fatto l'ssdt xh_rvp08 prima di riavere la conferma che quelle porte spuntassero su ioreg (cosa che è successa solo dopo una installazione pulita per via del fatto che aveva incasinato la partizione di sistema con Kext Utility eccetera) Invito @vulcano a tenere il thread aggiornato in merito ai progressi bluetooth, agli eventuali aggiornamenti per quanto riguarda una probabile soluzione alternativa al posto della DW1707 (lo invito a sostituirla con una scheda wifi nativa) e soprattutto per gli aggiornamenti di catalina di clover o delle kext che grossomodo escono una volta al mese... Abbiamo poi tolto tutti i rename e seguito la guida per ssdt_hack sempre di Gengik, come sempre tutto ciò non poteva essere fatto se non con l'ausilio di tutti gli strumenti che forniva il forum, grande preziosità per tutti, per la condivisione della conoscenza che appunto ognuno di noi nel suo piccolo riporta 🙂

Piccola curiosità, sarà che questo passaggio o è superfluo oppure viene applicato solo alle Gigabyte? Perché per lo sblocco msr della seconda build in firma con D3400 ho dovuto solo spegnere il pc dopo essere uscito dalla shell di Grub, l'ho spento premendo solo una volta sul pulsante di accensione, infatti quando si è nel menu di opencore, clover o GRUB il pc si spegne senza tener premuto il tasto per 5 secondi proprio perché non c'è alcun OS avviato ma solo un umilissimo menu bootloader. quindi ho dovuto solo fare un avvio a freddo (passando quindi per macchina spenta e poi ripremere il pulsante) senza dover staccare la corrente né la batteria del bios né scaricare i condensatori... Peccato per il caffé però, quello l'avrei preso volentieri nell'attesa, invece il pc è subito ripartito senza patch AppleXCPM di Opencore o KernelPM per quanto riguarda clover... Con il tempo magari se altri eseguiranno la stessa procedura potremo avere aggiornamenti, comunque secondo la mia esperienza serve solo un avvio cold boot... 😃

@KvL Ho aggiornamenti in merito all'utilizzo del tool. Richiede innanzitutto python3 installato, quindi se si va ad eseguire il file .command senza python3 darà errore. Inoltre il comando diff che avevo segnalato è totalmente indipendente dallo script di corpnewt, si può utilizzare da terminale però non è carino come quello di corpnewt il comando "diff" Ho trovato invece un programma ancora più carino che invece si chiama "Beyond Compare" (trad. lett. oltre/non solo confronti) che sembra fare ancora meglio il lavoro, ho deciso di utlizzare entrambi gli script anche per config.plist di Clover (di vecchie build o dove ancora lo uso) qualora qualche settaggio manchi e ho solo linux a disposizione (beyondcompare esiste per macos/win/Linux - per lo script di corpnewt ci sta il .bat oppure tramite esecuzione diretta del .py con python3 installato)

Aggiornato a Clover v5 5105, al primo avvio schermo nero (dopo aver visto solo la prima fase di avvio) poi ho sistemato rimettendo la versione precente utilizzando una live di linux per intervenire sulla EFI e sostuire Cloverx64.efi (v5105) con la 5104 per vedere cosa non andava. Sono rientrato quindi su macos con clover 2.5k 5104 e non c'erano problemi, ho provato a rinominare la cartella delle kext da 10.14 a Other per vedere se era un problema di caricamento kext o simili, rimesso v5105 e ha riavviato con successo. Ho preso l'occasione per rimuovere la cartella /EFI/CLOVER/drivers/UEFI lasciando solo /EFI/CLOVER/drivers/BIOS con all'interno solo ApfsDriverLoader.efi, tutti gli altri non servivano, neanche Apfsdriverloader.efi nella cartella UEFI. La EFI quindi è la stessa, (solo senza la folder UEFI e con clover aggiornato) alla fine ho provveduto a ricambiare la cartella Other in 10.14 e al riavvio successivo tutto ok.

Come promesso, ecco qui la EFI caricata con SMBIOS rimossi, ma tutto funzionante come sopra descritto EFI_D3400U_i5_7400.zip

@KvL questo è servito per questo problema https://github.com/acidanthera/bugtracker/issues/684 Infatti conclude con Dear @vit9696, I've found the location ProtectUefiServices quirk in 0.5.7 OpenCore Pre-release build by @williambj1. It looks like ProtectUefiServices quirk in combination with DevirtualiseMmio solves the problem. Now I'm able to boot with iGPU enabled! Purtroppo le Gigabyte mi ispirano sempre meno fiducia, in particolare Z390

Sì, gli update sono pianificati ed escono il primo lunedì di ogni mese, per rivederti che cosa uscirà vedi l'issue fissato su acidanthera bugtracker. Lista issues: https://github.com/acidanthera/bugtracker/issues Fissato di questo mese che stabilisce cosa uscirà per Aprile: https://github.com/acidanthera/bugtracker/issues/749

Update: Un nuovo tool dal repository Di Corpnewt, è semplicissimo da utilizzare: scarichi il nuovo Sample.Plist dal master di OpenCorePkg, e scrivi il seguente comando al terminale mentre hai il nuovo "Sample.plist" ed il precedente "config.plist" nella stessa directory (oppure in directory differenti ma devi specificare il Path). Apri quindi OCconfigCompare.command ed esegui diff path/to/Sample.plist path/to/config.plist

Allora la funzione di quel bootarg (shikigva) è di cambiare il "Board-id" infatti il bootarg successivo richiama il board-id di un iMacPro (o di altre macchine dentro Info.plist di AppleVPA.framework - vedi foto) che non usa il framework AppleVPA per aprire le jpeg, quindi se in primis metti un SMBIOS iMacPro1,1 non dovresti necessitare di quel bootarg. (per info vedi qui) Di qui provengono tre scelte per aggiustare il problema con Final Cut: 1) riesci ad attivare la integrata senza problemi (in effetti Z370 e UHD630 non hanno mai bisticciato, a meno di motherboard capricciose) 2) mantieni il tuo SMBIOS corrente disattivi la integrata da BIOS e aggiungi NoVPAJpeg per togliere i problemi di playback DRM (vedi qui) 3) Come ultima opzione e con i necessari test metterei l'SMBIOS del iMacPro1,1 disattivando la integrata da BIOS sempre come diceva appunto iCanaro ma potresti avere i problemi che la soluzione 2. risolve (es. DRM) Come sempre servono diversi test per arrivare alla soluzione ottimale, facci sapere che è sempre un piacere da parte nostra🙂

BuonSalve a tutti, oggi ho potuto completare la EFI di OpenCore di questa build con ultime rifiniture, ma partiamo dall'inizio: Come è possibile vedere da questo topic ho trovato qual era il problema che non mi permetteva di avviare con OC. Infatti si bloccava su: [PCI Configuration End] proprio perché non era un avvio UEFI puro (ottenibile solo con CSM disabilitata) Ma con la GT710, disabilitando la CSM non avevo output video, la scheda quindi necessitava di quel settaggio abilitato, prima ho pensato ad un flash del bios della GPU con uno UEFI compatibile da TechPowerUp, che diceva che il bios caricato nel loro sito web aveva Quindi ho preferito investirci un centinaio di euro (precisamente 103€) per comprare una Asus RX560) - questo mi dava la possibilità di vedere la schermata del bios finalmente. Al momento dell'arrivo ho quindi smontato il PC, tolto la polvere stratificatasi in un anno di attività (circa) e oltre a mettere la RX560 a cui basta l'alimentazione della porta PCI Express, ho anche cambiato la pasta termica di quella povera CPU quad core, così si farà un altro annetto al fresco con la MX4 😉 Preparo la EFI con OpenCore 0.5.6 ma avevo forse sbagliato qualche settaggio quindi ne ho provata un altra al volo (con OC 0.5.4) e andava. Oggi mi sono preoccupato quindi di fare l'upgrade a 0.5.6, nessun problema riscontrato... SMBIOS 18.2 e iGPU funzionante (calcolo, ig-platform 19120000 e device id 19128086 convertiti rispettivamente in 00001219 e 12190000). Poi mi è balzato in mente di metterci su questa build anche Final Cut Pro X se mi dovesse capitare di sistemare qualche video, e quando ho installato appunto il pacchetto, FCP crashava molto probabilmente per gli smanettamenti dovuti al FakeID della iGPU, a cui dovevo accorrere necessariamente, altrimenti Kernel Panic 🥶 Quindi ho deciso di prender due piccioni con una fava, sistemare sia l'accelerazione Hardware H265 di videoproc (vedi qua) e disabilitare la iGPU. Ho quindi provveduto a disabilitare da BIOS la integrata che dava tanti problemi se macOS non aveva tutto Skylake sotto (quindi videoproc aveva entrambe le accelerazioni con FakeCPUID lilucpu=8 e g-platform 19120000 e device id 19128086 convertiti rispettivamente in 00001219 e 12190000). Fatto ciò ora ho entrambe le accelerazioni con iMacPro1,1, riducendo i tempi di avvio non essendo presente la iGPU, accontentando FinalCut che ora funziona, e videoproc che utilizza entrambi i device per comprimere un H264 in H265/HEVC e ci mette pochissimo, oltretutto con un uso CPU del 15% e GPU del 30%-45% E poi perché no, ho estratto il BIOS della motherboard e sbloccato il registro MSR 0xE2 in modo da ridurre ancora di più i tempi di avvio e togliere la patch AppleXcpmCfgLock. Finalmente sono riuscito a rendere la build più snella a livello di configurazione, rimuovendo patch, sistemando delle noie varie eccetera... allegherò appena posso la EFI senza i seriali, ma ci tenevo a tenere aggiornato questo topic 😁

Mia opinione personale... Io lascio la GUI cosi' come sta, sia per la semplicita', sia perche' le icone rappresentano degli dischi da 3,5" che non uso (avendo solo M.2) Bene a sapersi che hanno implementato una GUI grafica comunque, proprio come avevo intuito dai commit

Piccolo tip: siccome ci ho sbattuto la testa anche io, su una Fujitsu D3400: l'offset del CFG Lock dipende solo dalla motherboard e non dalla versione del bios. Ho controllato 3 vendor diversi e 3 versioni bios diverse rispettivamente per ogni vendor, e ogni motherboard di ogni vendor (gigabyte msi e Asrock) non ha mai rilasciato update bios in cui quell'offset cambiava Da Opencore si puo' utilizzare VerifyMSRE2.efi (sezione Tools) per controllare se la patch e' avvenuta con successo, non saprei pero' dirti come caricare quel driver da clover, solo dal config di Opencore so come caricare quel driver nel menu di avvio

Buongiorno a tutti, stamattina con grande soddisfazione sono riuscito ad estrarre il BIOS UEFI dal file .exe di un laptop Dell di un mio amico, l'ho aiutato per quanto riguarda la rimozione della patch dell CFG Lock, e ho pensato di fare una guida riassuntiva che descrivesse in maniera chiara come procedere... Per ora e' in inglese, qualora vogliate inserirla in qualche guida gitbook e' possibile tradurla senza problemi, poi e' gia' in formato markdown, quindi il testo e' abbastanza leggibile Fatemi sapere se vi piace o se vi va di proporre miglioramenti/aggiunte/modifiche prima di esporla al pubblico Extract_BIOS_from_EXE.md.zip

Ahahah già, la modalità testo è immediata, molto simile a quella di GRUB, "with nothing fancy" direbbero gli inglesi - con nulla di artificioso... Comunque penso che quella feature sarà possibile tramite un driver .efi come appunto l'aveva pensata DF

Novità: dall'ultimo commit sembra che abbiano integrato il lavoro che ha fatto Download-Fritz in merito alla GUI di OpenCore... "This file is part of BootLiquor, OpenCore GUI." Spero soltanto che la mettano facoltativa con un settaggio True/False per attivarla, perché sono affezionato alla semplicità originaria...

Grazie Gengik per le delucidazioni, e Grazie a Ciro per averlo segnalato, e a foskvs per averlo rimosso 😃

Per quanto mi riguarda preferisco un prodotto venduto e spedito da amazon, in quanto spesso compro li' e il servizio da loro fatto e' impeccabile anche per le politiche di reso, inoltre avendo Prime mi conveniva andare con la seconda tra queste due scelte Ho finalmente disabilitato la CSM e tutto va a meraviglia con Opencore e la seconda build in firma (i5 7400) Aggiornero' il post appena posso Cosa aveva il link di amazon per curiosita'?