Leaderboard

quindi uno che ha una efi, con determinati driver oltretutto corretti poi da altre persone... reinstalla clover selezionando, posso dire a caso, tutti i driver possibili e la colpa sarebbe della "documentazione" che non c'è su clover? mentre installi ogni singolo driver dice a cosa serve, inoltre basterebbe guardare prima la efi come è strutturata e come lo è dopo aver aggiornato clover. Magari farsi un backup prima, di quella funzionante altra cosa sempre riguardo ai driver, Clover configurator ti dice altre info relative... app usata alla fine da tutti Sinceramente in questo caso, lo ripeto, dire a prescindere, da subito senza nemmeno aver visto minimamente una determinata configurazione se fosse corretta o meno, di passare a opencore non mi sembra corretto. Clover di fatto ha servito da anni e lo fa tutt'ora nel suo miglior modo, detto questo che OC abbia suoi "pro" nessuno lo nega ma anzi è un dato di fatto ma in questa specifica situazione clover non c'entrava minimamente nulla, non era la causa dei problemi e per questo non mi sembra idoneo solo pensare a opencore invece di capire e correggere prima le proprie lacune. Di certo OC è molto più tecnico e particolare di clover, quest'ultimo è indubbiamente come dire "più facile".

Allora da tempo, diciamo da sempre uso AMD e OSX, sbattuto la testa per anni a provare kernel, prima che uscissero le Patch Questa cosa da sfatare e che i kernel andavano alla lunga meglio, certo una volta sviluppato il definitivo ora si fa molto presto a dire, (ho un hack AMD) Bè prestazioni? allora vi dico per certo che fino a os Sierra il kernel perfetto creato da Bronya, ci girava tutto e alla perfezione (tutto al 99%) anche se ora ho un Ryzen che gira più del doppio del mio vecchio FX 8350, le prestazioni della video e del dell'hack nel suo complesso erano decisamente migliori, la r9 270x girava alla lunga meglio della mia attuale rx570 su Ryzen, (se ritrovo vi posto) Le Patch sono comunque un derivato di vecchi test. Bronya e compagnia bella Qualcuno si è chiesto mai perché Bronya non si vede più in giro a sviluppare? perché non si sviluppa più lì? su IM Be su IM cera un bagaglio di tante cose ora ferme li da tempo, diciamo che non sono ferme li, tante si trovano da altre parti🙄questo perché? io ho fatto una domanda voi datevi la risposta, è facile prendere meriti per le cose fatte da altri, anche se succede in tutti i Forum e qui ne sappiamo qualcosa. Bè Bronya è stato preso anche per quello che voleva essere pagato, ma vi assicuro che non è cosi, lo ha fatto solo dopo che ha visto marcio(ha fatto bene) io personalmente da 10.7 a 10.12 non mi ricordo di aver cacciato un centesimo. ecco come vedete 8+8 era Fx 8350, Pitcairn (r9 270x) su Sierra con kernel

Per noi AMD arriva dopo 🙂

Premesso che quello che vado spiegare, può essere perseguito in diversi modi, per chi è avvezzo all'uso della shell di Clover o di OpenCore potrebbe essere un gioco da ragazzi ottenere ciò; ma per chi non è uso ai terminali si ottengono buoni risultati servendoci di semplici, ma molto potenti, applicazioni con interfaccia grafica. Quale è lo scopo di questa mini guida, è quello di invogliare i più pigri ad iniziare usare OpenCore contemporaneamente a Clover, sulla EFI del disco e senza che i bootloader si pestino i piedi tra loro. Quindi si continua con il normale uso/utilizzo di Clover e poi se riesce nello scopo, tramite la scelta del tasto funzione (F8, F11 etc..) nella fase di post del BIOS sarà possibile avviare direttamente OpenCore. Una vantaggio molto evidente, è quello che se si hanno 2 bootloader funzionanti e indipendenti per il proprio hack, nel caso di esperimenti, nuovi kext che causano blocchi o kernel panic, macOS è comodamente avviabile dall'altro bootloader (sempre che i kext siano in EFI e non installati in L/E oppure in S/L/E) L'app principe per eseguire ciò è BOOTICE software standalone molto potente quindi maneggiare con attenzione ed evitare di cancellare partizioni, dischi etc... non mi assumo responsabilità se pasticciate a caso. Personalmente BOOTICE lo uso con windowsPE by Strelec, ma nessuno vieta di inserirlo in qualsiasi altra LivePE, come pure se siete in multiboot diusarlo direttamente da Windows. Come un attento utente di hack, sa che il file che avvia Clover è allocato nella partizione di avvio EFI (FAT32 flag boot+esp) in cui all'interno si ha una cartella EFI (nota di colore, qualche anno fa, con tutte queste EFI, ci uscivo matto ) quindi: EFI/ BOOT/BOOTX64.efi il file di avvio ha la medesima allocazione e nome EFI/ BOOT/BOOTX64.efi quindi che ho fatto, l'ho rinominato in BOOTxOC.efi e l'ho affiancato a BOOTX64.efi di Clover EFI/ BOOT/BOOTX64.efi EFI/ BOOT/BOOTxOC.efi EFI_BOOTSchermata 2019-08-24 alle 21.59.59.png tutto questo da macOS naturalmente, ma è fattibile anche da Windows. Poi il prossimo passo è quello di usare BOOTICE ed aggiungere alle entries del BIOS quella del bootloader di OC BOOTICE_01_CHaZNa1elC.png avviato il software si seleziona il TAB UEFI e poi si clicca su Edit boot entries e si va ad aggiungere la entries di OpenCore browsando sino al bootloader. NB: da windows come da macOS la partizione EFI è di sistema e nascosta; mentre su macOS esistono diversi tool o un semplice comando da terminale è possibile montarla, su windows questo è un pelo più complicato, ma di facile soluzione. Tra le varie opzioni esiste un software che anche nella sua versione freeware permette di montare facilmente la EFI, si tratta di Mini Tool Partition Wizard Free: una volta scaricato e installato (attenzione a NON installare altre cose durante il setup) si avvia e dalla sezione gestione partizioni/disci si individua la EFI, le si assegna una lettera e si applicano le operazioni. Fatto questo poi sarà browsabile da BOOTICE. PS: 06-08-2020 Al tempo in cui scrissi questa miniguida, non notai che è possibile montare/smontare molto facilmente la EFI, anche con BOOTICE con il tab Physical disk --> parts manage NB: alla fine delle operazioni, ricordarsi sempre di togliere la lettera assegnata alla EFI ADD_BOOTxOCa5x1XNV16f.png OpenCore_Entries_7tmGF4u5s2.png BOOTICE_IMG_20190824_170827.jpg Poi come nel mio caso, se si hanno diversi OS e magari entries fantasma, se ne può approfittare per fare pulizia ed assegnare nomi alle entries facilmente identificabili; quindi si salva e si esce. Poi quando si riavvierà il sistema, spingenfo l'apposito tasto funzione che permette la scelta con cui avviare, ci troveremo tra le varie voci la possibilità di avviare direttamente OpenCore Z170_hack 4 in firma Z170_ENTRIES_IMG_20190824_225327.jpg Z170_OC_BOOT_IMG_20190824_225430.jpg Z370 --> hack 2 in firma BOOT_OPTIONS_IMG_20190824_171158.jpg Una volta avviato OpenCore poi si sceglie quale macOS avviare se se ne ha più di uno, oppure si avvia il solo che si ha. OpenCore_la_scelta.png Bene direi che abbiamo terminato, spero sia tutto chiaro e abbia invogliato qualche lettore ad applicarsi per avere tra le proprie frecce al suo arco anche l'opzione di impegnarsi per avviare il proprio hack anche con un boot loader diverso... e ricordo che esiste la guida/tutorial ATTENZIONE tutto questo testato e verificato il funzionamento su sistemi recenti da skylake/Z170 in poi in UEFI puro. In sistemi legacy NON è stato testato.

Ciao a tutti ragazzi, deluso dalle prestazioni nei giochi e app OpenGL (e purtroppo anche molti giochi metal) nel mio Ryzentosh rispetto a Hackintosh Intel decisamente meno performanti mi sono messo giù a cercare di capire da dove si originassero questi rallentamenti. Già vi dico che RadeonBoost aiuta sì, ma solo in gran parte i benchmark, e comunque non Cinebench 15 test OpenGL e i giochi. Se installo macOS Catalina in Proxmox, emulando una cpu intel al 100%, non ho bisogno di dette patch, e il gap grafico viene colmato abbondantemente, prova ne è il fatto che Cinebench 15 balza da 100 fps a 130 fps, mostrando un palese 30% in più di prestazioni grafiche, idem Standard Candle test di DaVinci Resolve 16 che con 64 nodi di blur balza da 15 fps a 18 fps... Xonotic balza da 5 miseri fps minimi a 15 fps, in linea con l'esecuzione su macchine Hackintosh intel e mac veri... Allora, c'è da dire indubbiamente che le patch cosiddette Vanilla per OpenCore rallentano e non poco le prestazioni 3D in diversi ambiti nei nostri Ryzentosh. A suffragare questo fatto c'è questo post: https://github.com/AMD-OSX/AMD_Vanilla/issues/27 Allora provo a seguire il consiglio, scambiare cioè le patch applicate: dovremmo comunque applicare quelle delle vecchie generazioni AMD Bulldozer / Jaguar (15h, 16h)... ma sul mio attuale Ryzen 9 3950X osx di bootare non ne vuole sapere... ...si blocca lì... resto a guardare anche mezz'ora... ma non si schioda... A leggere per il web pare che tutti i Ryzen di vecchia generazione (2x00 e 1x00) riescano ad avviarsi con dette patch... fatemi sapere se effettivamente è così: ma chi ci riesce lamenta problemi grossi di sync audio / audio scoppiettante... anche qui fate dei video per smentirmi se non è così 😉 Ovviamente non pago di tutto ciò, mi sono messo a smanettare sui due file di patches (https://github.com/AMD-OSX/AMD_Vanilla/tree/opencore/15h_16h e https://github.com/AMD-OSX/AMD_Vanilla/tree/opencore/17h), riordino il file patches.plist per le 15h/16h che sintatticamente preferisce andare a capo solo tra i tag <data> </data> oltre a mettere su più righe le stringhe da ricercare / rimpiazzare in modo da avere un file conforme a quello per le patch 17h... da terminal lancio diff ed ecco il risultato: 451c451 < <data>uAgAAIAx2zHJMdIPokGJzkUPtvZB/8ZEifFEifBmDx+EAAAAAABmDx+EAAAAAAAPH4QAAAAAAOl8////Dx9EAAA=</data> --- > <data>uAgAAIAx2zHJMdIPokGJzkUPtvZB/8a4HgAAgDHbMckx0g+iD7b3/8ZEifEx0onI9/aJwUSJ8Ol8////Dx9EAAA=</data> 461c461 < <string>algrey - cpuid_set_info - cores and logicals count - part 1 - 10.13</string> --- > <string>algrey - cpuid_set_info - ryzen cores and logicals count - part 1 - 10.13</string> 489c489 < <string>algrey - cpuid_set_info - cores and logicals count - part 1 - 10.14</string> --- > <string>algrey - cpuid_set_info - ryzen cores and logicals count - part 1 - 10.14</string> 517c517 < <string>algrey - cpuid_set_info - cores and logicals count - part 2</string> --- > <string>algrey - cpuid_set_info - ryzen cores and logicals count - part 2</string> 535c535 < <data>ichmDx+EAAAAAABmDx+EAAAAAABmDx+EAAAAAAAPHwA=</data> --- > <data>QYnOuB4AAIAx2zHJMdIPog+29//GRInxMdKJyPf2ZpA=</data> 545c545 < <string>algrey - cpuid_set_info - cores and logicals count - part 3 - 10.13</string> --- > <string>algrey - cpuid_set_info - ryzen cores and logicals count - part 3 - 10.13</string> 573c573 < <string>algrey - cpuid_set_info - cores and logicals count - part 3 - 10.14</string> --- > <string>algrey - cpuid_set_info - ryzen cores and logicals count - part 3 - 10.14</string> 601c601 < <string>algrey - cpuid_set_info - cores and logicals count - part 4 - 10.13</string> --- > <string>algrey - cpuid_set_info - ryzen cores and logicals count - part 4 - 10.13</string> 629c629 < <string>algrey - cpuid_set_info - cores and logicals count - part 4 - 10.14</string> --- > <string>algrey - cpuid_set_info - ryzen cores and logicals count - part 4 - 10.14</string> 741c741 < <string>algrey - tsc_init - grab DID and FID from MSR</string> --- > <string>algrey - tsc_init - grab DID and VID from MSR</string> 759c759 < <data>uXEAAcAPMonASInBSMHpBoPgP0iDwBCA4QdI0+gPH0QAAA==</data> --- > <data>uWQAAcAPMg+2yInGwe4Ig+Y/RTH/MdJIichI9/ZIAcBmkA==</data> Mi armo di pazienza e per poter confrontare visivamente meglio i due file scarico, compilo e installo ProperTree, interessante script / app in Pyton per gestire i file .plist in maniera più leggibile. Le differenze quindi stanno come segue, premetto che i numeri delle patch sono assegnati da ProperTree in automatico partendo da 0 dalla prima all'ultima presenti nei file plist relativi: La patch 15 che recita nel commento "algrey - cpuid_set_info - cores and threads calculations - 10.15" corrisponde alle "righe" 451c451, come vedete le stringhe da rimpiazzare differiscono discretamente; Notate che le differenze a livello di nome del commento sono irrilevanti al fine del corretto boot quindi le trascureremo; la patch 18 recita nei commenti "algrey - cpuid_set_info - (ryzen) cores and logicals count - part 2" e corrisponde alle "righe" 535c535, stringa replace totalmente diversa; infine la patch 26 che recita nei commenti "algrey - tsc_init - grab DID and VID from MSR", nelle patch per 15-16h definita nel commento "algrey - tsc_init - grab DID and FID from MSR", corrisponde alle "righe" 759c759: anche qui cambio sostanziale della stringa replace... Allora inizio a fare l'alchimista: se inserisco le patch 15 e 18 nel mio config.plist riesco a bootare, è la patch 26 che se viene inserita blocca il boot... fidandomi del commento che i creatori delle patch gli hanno affibbiato, deduco che la famiglia 17h di CPU Amd evidentemente inizializza il TSC in maniera differente... chissà se magari è proprio questo il problema per te @fabiosun, magari i nuovi threadripper hanno un tsc ancora diverso rispetto alle 17h "precedenti". Comunque il succo inerente a questo post è: anche avviando con le patch 15 e 18 nel mio Ryzen 9 3950X le performance grafiche non migliorano (la mia cpu viene segnalata come 32 cores / 32 threads), segno che quando applichiamo le 15, 18 e 26 ad un Ryzentosh basato su 2700x o 1800x o cpu zen similari il miglioramento grafico è apparente perché il tsc svalvola, generando le corruzioni e il desync nell'audio (basterebbe riprodurre un video YouTube). Qualcuno con competenze così avanzate del mach_kernel e delle cpu AMD può aiutarci a migliorare la patch 26? O anche a spiegarci cosa fa di preciso... Allego le patches "razionalizzate" per comodità e anche il mio config.plist di test con le patch 15 e 18 della famiglia zen 15h/16h, la 26 è rimasta quella della famiglia 17h altrimenti non si avvia nulla. patches1516h.plist.zip patches17h.plist.zip configtomnic.plist.zip

Z370 Clover 5119

Z370 Clover 5119

beta 2 build 19G46c

perchè non controlli prima di aggiornare clover installando tutti i driver possibili? secondo me dovresti prendere la mano prima con clover invece di pensare a opencore

sino a che non si adopera, non si capisce bene, per darti una idea, vedi qui https://www.macos86.it/topic/1562-opencore-clover-boot-custom-entries/ da BOOTICE si fa tutto, si assegna anche lettera alla EFI

Yeah I'll edit it with password link. Done! Just dont want regulars to see that video!

se è presente una cartella microsoft che prima non vi era, si vede che l'ultima installazione ha piazzato li i suoi file di boot, verifica la cosa dalle date dei file, poi se è così basta che copi questa cartella microsoft nella EFI del disco ove hai windows, al che dopo dalla GUI di Clover, se tutto torna, windows lo potrai avviare da 2 EFI diverse se la cosa disturba, quella che non interessa, comprimila per backup e poi eliminala

Buongiorno, confermo va sostituito il kext di Mojave ed editato con il DEVID della 88e8056 in sostanza non veniva caricato per un problema di permessi del file AppleYukon2.kext. Grazie Mille

si chiama evoluzione macaca 😂 poi non ti fermi più io starei anche un po' più abbondante come spazio, magari quando usciranno le prime beta del prossimo macOS, poi ti piace 😆

ricordo che OC è ancora in beta e per utenti avanzati, quindi lavori in corso... per dire, a me non avvia un windows, ma qualcosa volta in passato lo avviava... quella che non avvi il pinguino è cosa che ho letto di frequente tasto funzione scelta boot mobo, e via, passa la paura

Ho risolto aggiornando le patch AMD Vanilla Opencore !..grazie per il suggerimento !...Catalina aggiornato correttamente alla versione 10.15.5 !

ma con te, non si ha mai pace 😄 posta il config, anzi, la EFI che stai usando

Fondamentalmente abbiamo offset CMOS fino al byte 256. Le patch note(come anche fixRTC) limitano l'intero a 128 byte, il che di solito risolve già il problema. Se nessuna delle patch note (come DSDT o Config Fix) è installata e viene utilizzato RTCMemoryFixUp, viene riutilizzata l'intera larghezza di banda (256 byte) e di conseguenza possono verificarsi nuovamente ripristini CMOS ecc. (Incompatibilità di AppleRTC e firmwareBIOS). Il problema è trovare e definire gli offset problematici. Gli offset corrispondenti vengono quindi bloccati, ma RTCMemoryFixUp continua a simulare la lettura / scrittura su questi offset. Non conosco alcun modo per leggere gli offset problematici da un registro o simili, il che significa testarlo. Se RTCMemoryFixUp è installato e la macchina si reimposta automaticamente dopo la sospensione / riavvio, vuol dire che stiamo ancora scrivendo su quegli offset che creano problemi, il che vuole anche dire che per trovare i settori bisogna andare per tentavi. Gli offset 00-0D (0-13) non sono critici, non è necessario provarli. L'idea è di trovare prima il banco di memoria problematico (il primo va da 00-7F / 0-127(byte) e il secondo da 80-FF / 128-256(byte)) (entrambi hanno un problema nel caso peggiore). Per questo escludiamo 13-127 tramite bootarg, ovvero rtcfx_exclude = 0D-7F e testiamo con sleep, wake e reboot. Se il problema è risolto, dobbiamo trovare più precisamente gli offset problematici tra 0D-7F. Se il problema non viene risolto, testiamo il secondo banco, ovvero rtcfx_exclude = 80-FF . Diciamo che il problema è stato risolto solo ora, ora possiamo continuare i test nell'area 80-FF (128-256byte). Una tattica per evitare di dover testare ciascuna area individualmente è quella di dimezzare l'area per scoprire in quale metà del problema si trova. Ad esempio, ora è possibile utilizzare quanto segue per questo: rtcfx_exclude = 80-C0 . Se il problema non esiste neanche con questi esclusi, possiamo testare ulteriormente nell'intervallo 80-C0 (128-192) (ad es. Di nuovo la metà). Tuttavia, se il problema persiste, possiamo continuare a esaminare l'area C0-FF per trovare l'offset problematico (area). E così via fino a quando non si identificano gli offset problematici. Questo e pressoché il modus operandi da seguire per utilizzare questo kext, almeno per ora, magari in qualche rilascio futuro si troverà un metodo per identificare i settori in maniera automatica. Sto facendo attualmente delle prove, ma nel malaugurato caso che hai errori in più settori la situazione si complica 😭

eh sai com'è apple... delle volte tarda ad aggiornare una cosa... un altra volta...altro 😂

Oppure puoi usare Lenght come del resto anche con clover