Closed fabiosun closed 2 years ago
@fabiosun quando puoi potresti creare una "bozza" su tutto questo? Così in caso fra tutti valutiamo come integrarla o anche correggere alcune parti?
Non ho il dono della sintesi come puoi vedere..ma ho scritto a @tiziodcaio che avendo fatto un ottimo lavoro se ha tempo farà una sintesi da pubblicare..sono a disposizione per aiutare a verificarla :)
Purtroppo al momento non sono preso benissimo, non contare su di me... Prova comunque a fare una bozza qua, magari un draft pull request, e quando ho tempo revisiono e sintetizzo 🙂
Non ho il dono della sintesi come puoi vedere..ma ho scritto a @tiziodcaio che avendo fatto un ottimo lavoro se ha tempo farà una sintesi da pubblicare..sono a disposizione per aiutare a verificarla :)
Proporrei di sintetizzare il tutto con:
"Inizialmente era quasi impossibile avviare macOS su processori TRx40 a causa dei driver responsabili della gestione della memoria di OpenCore. Con l'introduzione di DevirtualiseMmio invece, la situazione è nettamente migliorata. E' bene notare che senza questo quirk attivo molti sistemi TRx40 neanche si avviano. Abilitandolo, e configurando propriamente la MmioWhitelist invece, è possibile ottenere risultati discreti".
Non ho il dono della sintesi come puoi vedere..ma ho scritto a @tiziodcaio che avendo fatto un ottimo lavoro se ha tempo farà una sintesi da pubblicare..sono a disposizione per aiutare a verificarla :)
Proporrei di sintetizzare il tutto con:
"Inizialmente era quasi impossibile avviare macOS su processori TRx40 a causa dei driver responsabili della gestione della memoria di OpenCore. Con l'introduzione di DevirtualiseMmio invece, la situazione è nettamente migliorata. E' bene notare che senza questo quirk attivo molti sistemi TRx40 neanche si avviano. Abilitandolo, e configurando propriamente la MmioWhitelist invece, è possibile ottenere risultati discreti".
azzarola pensavo di aver fatto chiarezza 📦
1) inizialmente era impossibile far partire OSX su trx40
2) DevirtualizeMMIO già c'era
3) tutti i sistemi trx40 anche oggi se disattiviamo quel quirk non partono
4) risultati discreti? :) :)
la migliore macchina in commercio per OSX per te e' discreta?
Non ho il dono della sintesi come puoi vedere..ma ho scritto a @tiziodcaio che avendo fatto un ottimo lavoro se ha tempo farà una sintesi da pubblicare..sono a disposizione per aiutare a verificarla :)
Proporrei di sintetizzare il tutto con: "Inizialmente era quasi impossibile avviare macOS su processori TRx40 a causa dei driver responsabili della gestione della memoria di OpenCore. Con l'introduzione di DevirtualiseMmio invece, la situazione è nettamente migliorata. E' bene notare che senza questo quirk attivo molti sistemi TRx40 neanche si avviano. Abilitandolo, e configurando propriamente la MmioWhitelist invece, è possibile ottenere risultati discreti".
azzarola pensavo di aver fatto chiarezza 📦
1. inizialmente era impossibile far partire OSX su trx40 2. DevirtualizeMMIO già c'era 3. tutti i sistemi trx40 anche oggi se disattiviamo quel quirk non partono
Ok claro
4. risultati discreti? :) :)
la migliore macchina in commercio per OSX per te e' discreta?
Beh considerato che stiamo pur sempre parlando di un sistema operativo che richiede patch kernel (on-the-fly grazie ad AMD-OSX), direi proprio di si: è comunque una macchina discreta.
Motivi? Basti pensare alle patch per qualsiasi applicazione che sfrutta le librerie MKL (dw ho già letto il thread relativo alla fakedlyb)
Non ho il dono della sintesi come puoi vedere...
@fabiosun mi permetto di dire come la penso sull'argomento, qualora la guida di dortania già presente non sia appunto il massimo in termini di quello che hai potuto sperimentare tu in prima persona
Putroppo solo chi ha potuto toccare con mano la situazione può sapere cos'è che non va con quella guida sul DevirtualizeMMIO: poiché non possiamo travasare le informazioni da una mente all'altra se non facendo 8000 domande su come si fa che cosa e che cos'è che non va, l'ipotetico revisionatore della guida è costretto o a rifarsi da capo la sua esperienza in merito (come è successo a te su TRX40) o essere assistito da te su come scrivere che cosa.
Io affronterei la cosa in questo modo:
Le rifiniture ci sono dopo, scriverla come guida vera e propria, quello si fa dopo, ma come minimo serve almeno sapere di che cosa si sta parlando, cosa fare, quando come ed in che modo
Altrimenti si lascia così, @dreamwhite seguendo quella guida ha fatto il devirtualizeMMIO delle sue regioni sul Dell 5370 disattivando EnableWriteUnprotector
di conseguenza, cosa più che corretta per il fatto che ha MAT = 1
Prova comunque a fare una bozza qua, magari un draft pull request, e quando ho tempo revisiono e sintetizzo
Secondo me questa è la cosa migliore, approssimare una bozza e poi integrare
Ciao io non ho la competenza per dire cose assolute in questo campo.. posso dirti quello che ho imparato quando dal 6 dicembre 2019 ho cercato di fare funzionare il mio TRX40 Faccio presente che la cpu usci' ufficialmente il 3 Dicembre 2019 Personalmente non ho altre piattaforme oggi e per tutte le precedenti non avevo mai usato DevirtualizeMMIo..al massimo mi ero calcolato il mio valore di slide come documentato da noi ed in rete.
Il discorso di Dortania e' complesso, su MMIO e relativi statement su Trx40 sbagliano Scopiazzano ed ascoltano pareri qua e la, ma poi riportano cose inesatte. Lo dico in sincerità..non me ne frega nemmeno fargliele capire ;) Combatteresti con una serie di "leccaxxlo)" che difenderebbero a spada tratta i creatori di cotanto riassunto globale..e non uso la parola riassunto a caso. Questo succede anche, ad esempio, con le patches del Kernel utili per gli utenti AMD. Si disquisisce molto su come tradurle da OpenCore a Clover, ma non si fanno le domande per arrivare al nocciolo del problema e della sua risoluzione Name, Procedure...kernel... Gente che dice a me non vanno le patches..e si certo se il bootloader non riconosce la parola kernel o simile e tu hai solo messo Procedure al posto di Name..si hai formalmente la cosa giusta..ma Opencore scrive Name: kernel e capisce cosa si intende Clover scrive Procedure:kernel...e ti da un warning ora tornado ad MMIO Su trx40 e' un discorso non complesso ma variegato, non a tutti gli utenti che ho aiutato negli anni a far partire la macchina hanno le stesse necessità Le patches che usiamo sono prodotte negli anni da troppe persone, ed ognuno si tiene stretta la sua piccola parte di gloria Sai che molti le usano tutte non capendo una "ceppa" di cosa facciano? Sia su OC che con Clover.. Molte patchano le stesse parti e parti diverse del kernel in doppia mandata, spesso su tre patches ne basta una Solo a chi lo vai a dire? a chi si definisce guru?
Vedi Alessandro..tu ora scrivi MAT=1..io sono proprio ignorante e non capisco un'acca di ACPI ad esempio Ma negli anni ho fatto sempre funzionare il mio hardware (che, non per vantarmi, e' sempre all'avanguardia per mia passione). Perche'? perche' ho avuto la capacità di farmi ascoltare negli anni dai vari veri guru dell'epoca, come poteva essere tanti anni fa netkas o pikeralpha per dirne un paio o gli ultimi devs di Opencore che pur essendo abbastanza stringati hanno aiutato me (e si sono aiutati anche loro con i miei debug log) a far funzionare trx40... Le patches di allora definite "Borked" o junk o altre parole non belle con il nuovo gestore di memoria avrebbero funzionato anche allora..quindi hanno rilasciato un prodotto che ora ci fa funzionare..e bene
vedi mi sono allungato e pure andato fuori tema? :) :) scusate
È da capire
Chiunque sappia come sistemare... Perché io non sono un drago in questo argomento specifico
Ritengo che sia importante risolvere la questione, dato che non ho capito ancora se persiste qualche problema o no ...
@fabiosun perchè chiudi?
Mi sembra che non ci sia tutto questo interesse Sul forum ho creato due thread che credo sia il massimo oggi che si possa trovare in giro
La guida che e' in traduzione in questa parte non e' chiara ad essere buoni..sbaglia ad essere corretti. Soprattutto quando si parla di TRX40, ma in alcuni casi anche per altri sistemi. Questo ha generato nel tempo diversa confusione. Il quirk DevirtualizeMMIO e' diventato famoso quando alcuni possessori di CPU TRX40 si sono incaponiti per avere il loro sistema funzionante con OSX Dopo parecchie prove di notevole difficoltà per l'epoca, in primis per la mia scarsa conoscenza dellì'argomento e poi soprattutto per il modo criptico di rispondere dei devs di Opencore, si capi' che le patches erano le colpevoli.."borked" a dirla come dissero i devs. Oggi possiamo dire che non e' cosi' e che le patches erano già buone allora..appena sistemata la gestione di memoria (driver di opencore) i sistemi TRX40 ihanno iniziato a "bootare" felicemente in OSX. Prima di allora avevamo aperto una strada nuova con la virtualizzazione ed il passthrough che ci ha dato tanta soddisfazione..ma questa e' un'altra storia! ;) Tornando agli MMIO. La situazione ottimale per la maggior parte dei sistemi e' avere il quirk DevirtualizeMMIO disabilitato. Cosa significa questo? Significa lasciare tutte le aree di memoria a disposizione del BIOS che puo' scriverci soppra in una qualsiasi delle sue operazioni o necessità. Lasciarlo disabilitato non e' possibile per gli utenti TRX40, il sistema in questo modo non parte , abilitandolo si devirtualizzano tutti gli MMIO trasportando la loro zona di memoria in altre, questo produce un effetto molto positivo per TRX40..il sistema parte, poi pero' durante l'utilizzo accade che non si riavvia correttamente, non si spegne o banalmente va in KP quando si tenta di andare in stop o di risvegliare il sistema. Fate attenzione , questa e' solo una minima parte evidente delle problematiche che ci sono utilizzando quel quirk..o meglio attivandolo. Dopo tante prove si e' capito che per avere un sistema ottimale bisognava provare a liberare dal "Devirtualize" piu' aree MMIO possibili, liberarle per consentirne l'utilizzo ad osx nei suoi compiti.(MMIOWhitelist) Non e' argomento di questa issue sul come si calcolano ed inseriscono gli MMIO in un config.plist, ci sono molte guide ben fatte ed una la trovate in inglese nel thread che posto alla fine di questo messaggio. Faccio un piccolo ritorno indietro il mio sistema produce in debug 18 MMIO Mettere DevirtualizeMMIO su abilitato e poi mettere tutti gli MMIO su skip 1 e' come se lasciassimo DevirtualizeMMIO su disabiltato..e questo spero ora diventi chiaro in questo caso TRX 40 non parte quindi attivare il DevirtualizeMMIO e riassegnare tutte le aree MMIO al BIOS e' come avere DevirtualizaMMIO su disabilitato. Ora, cosa si e' provato a fare? A ridare uno ad uno attivandoli i vari MMIO scoprendone con difficoltà le varie (ed incerte zone di competenza) Si e' scoperto ad esempio che i primi due MMIO se riassegnati al BIOS (skip=1) aiutavano i sistemi a spegnersi e riavviarsi correttamente. Altri erano necessari per la NVRAM e altri per altre funzionalità ancora Ora , per non dilungarmi piu' di tanto, sulle 18 aree MMIO che produceva il mio debug n sono riuscito ad riassegnare ad OSX 15, poi ho lasciato una ulteriore Devirtualizzata ed ora ho un config con 14 MMIO ridati al Bios E, il mio sistema e' perfetto ;)
link utili: Discutere di patches ed MMIO con i Devs di opencore https://www.insanelymac.com/forum/topic/338516-opencore-discussion/page/135/#:~:text=Guests-,Posted%20March%204%2C%202020,-(edited)
risolvere i problemi causati dalla DevirualizeMMIO abilitato: https://www.macos86.it/topic/3307-trx40-bare-metal-vanilla-patches-yes-it-worksbutis-proxmox-better/page/33/?tab=comments#comment-85469
Poi faremo chiarezza su alcune altre sezioni di Dortania riguardo TRX40... all'epoca alcune correzioni furono fatte dopo mia richiesta sul discord di AMD OSX, ma altre sono rimaste inevase