fabiosun

Questo capita se sposti magari la applicazione cmq con tasto dx scegli di nuovo dalla posizione corretta e dovresti risolvere aggiorna prima tutto il database di ocat prima di aggiornare la tua efi

Capita a tutti 🙂 su Windows. Ora non ho piu' windows sul mio sistema ma quella e' la schermata standard per poi montare la partizione EFI Se hai un config.plist prova ad aprirlo e dovrebbe venire l'interfaccia standard di OCAT (per montare la EFI e' un po' diverso dalla versione di OSX) PS. prova a controllare se uno dei 4 dischi che si vedono oltre C sono in realtà le EFI montate

Hi @yandong31, I saw that you also asked the question on Discord to get CorpNewt (aka CorpGhost) involved in this topic. I'm happy about that and would like him to participate as well to shed some light on this topic, even though it may not be his area of expertise 🙂 (sorry) Getting back to us, you're not considering the fact that when these discussions first started, the DevirtualizeMMIO quirk wasn't so “famous” and the version of OpenCore (0.6.x) was much less refined than the one we use today (see, for example, the quirk section and the bootloader's memory manager itself). I and other users who had bought an AMD trx40 (top of the range at the time) clashed over the fact that OSX would not start on these machines. The first consideration that came up was that AMD's kernel patches needed to be updated (but this was not the case with subsequent tests). From here, the questions I asked vit9696 on Insanelymac at the time also consider the fact that DevirtualizeMMIO was used exclusively to run old OSes on Intel and for little else. So, with my obvious shortcomings on the subject, I started doing some debugging to understand why OSX wasn't working on my PC and those of other unfortunate colleagues (TRX40 users). Vit9696 and DownloadFritz (chief developers of the OpenCore project) tried to explain to me in a cryptic way (at the time) how to debug, and you can find these tests on InsanelyMac. It wasn't easy to talk to them for two reasons... the first is that I'm not a technician on these topics, and the second is that they consider the kernel patches we use to be junk. That said, after running all the tests (and there were 19 MMIO areas for my system at the time), they said that the AMD patches for the kernel were “borked.” * Here I'll open a small parenthesis for further explanation. None of us could understand at the time whether this statement was correct or not, so we devoted ourselves completely to virtualizing OSX with ProxMox. and it was a wonderful experience for all of us 🙂 Some time later, without any changes to the AMD kernel patches, in a more recent version of opencore (with new quirks and openruntime), the TRX40 systems began to overcome the initial hang due to lack of memory space, but any attempt to start OSX failed miserably.* So we started reviewing the various combinations of quirks and MMIO areas, and one user (Pavo) announced that he had managed to run the OSX of the time (perhaps Mojave or Catalina) in “bare metal” (without virtualizing in ProxMox). There were several problems, but the system worked 🙂 From there, further questions arose about how to optimize our systems. Some restarted instead of shutting down, others gave KP errors under certain conditions (sleep/wake). And much more. And so began the story that more is better! 😛 We started trying all the combinations and got to the point where, by reassigning all the MMIO areas (skip 1) except the last three of each motherboard manufacturer at the time, we were able to get OSX working perfectly in all its parts Now, I don't want to bore you and any other readers with other studies and tests carried out at the time, but we achieved a system of exceptional usability for all users. Some time later, a user who had studied some patches for Adobe products (XLNC) posted a new method on the trx40 thread. Without making the MMIO declaration in the whitelist but activating the DisableWriteVariable quirk, the same results were achieved! Personally, I never applied it on TRX40 except to verify what he said about his method, but it worked. Now I often use it with new users who are unable to do things themselves to get the correct MMIO for their machines, just to get them started and make them enthusiastic that the money they spent on their PC wasn't wasted 🙂 I hope that with this long explanation, you have a better understanding of my point of view, and I reiterate my happiness that others today (which is easier than it was then) are showing interest in this topic 🙂 Ah, another topic we tried to understand was associating these MMIO areas with parts of the BIOS of motherboards and controlled devices (USB, SATA, NVMe, NVRAM, PCIe slots, and so on). We didn't succeed, and no one has ever done so to date 🙂

Thread was created to have a place to discuss freely on this subject, so also your opinion is important and will be useful to other In your test (if you like try to disable MMIO whitelist and use the quirks i said In my opinion your system will be working in the same way! PS: you platform (if it is x670E/X870 E) need only that second area Skipped to 1 (you can check many EFI you see in international forum) Trx40 was different

this is an extract of a my conversation with DF (in 2022) You can try if your platform is an X870E to reassign first four and see if you have problem (Nvram, reboot, boot and so on) Or you can disable MMIO whitelist and use only two quirks i said I am pretty sure your system beahviour will be the same! In the past DF said me MMIO areas are not OSx related but Uefi firmware related (and i respected his words) Ps, i do not have to convince you more or less is better..i have only proposed my experience in a platform that initially was not supported by opencore 😉

on TRX40 more was better. on AM5 this is not valid On am5 i can reassign 4 of 5 MMIO areas, in this way my system loose its stability I only reassign 1 area and system is perfect, or i use DevirtualizeMMIO and DisableWritevariable quirks without whitelisting any MMIO areas (not adviced but on AM5 it works as wit only a MMIO area reassigned. No skill to understand if from 2022 opencore devs or motherboard Uefi firmware creators have changed something

No it is because i DisableWrite variable I have a question for you: Devirtualize quirk ON you have, let say ,5 MMIO area Skip to 0 in your opencore log you reassign all of them and you see then all MMIO areas to skip 1 What does this mean? (related to DevirtualizeMMIO quirk)

@yandong31in my current platform you can see in my signature i skipped totally to build a correct MMIO withelist. on AM5 there are few area compared to trx40 platform and also using MMIO whitelist is pretty simple to have it working (only one must be reassigned to UEFI bios needs) Only to my purposes and funny tests i use DisableWrite Variable quirks without building a MMIO Whitelist area and system is perfect in all its function (sleep, wake, reboot and so on) with trx40 in the past we had to reassign more we can because we had many problem if we thought "less is better" (sleep, restart on shutdown and Nvram problems) Devs documentation in this subject were initially few and cripticed (for non devs users) then (maybe) they clarified better also in opencore documentation (see where and when (Year 2020/1/2) this thread was born and see also their documentation in that time) I had some chit chat (because i have zero skills to understand his friendly lecture) with Download Fritz about MMIO areas in others forum and he explained and clarified stuff about UEFI Bios and how this subjetct was involved in MMIO areas Said this, thank you to renewing this old thread and i renew also the ask if you like to improve your finding in a detailed way i will very happy to add your experience in OP 😉

No purtroppo non ne ho Di solito vanno tutte le porte sia per la Rx 6600 che 6900 discorso diverso per le 6650 e 6950 Ho su un secondo PC in casa con una rx 6600 di powercolor e gestisce due monitor attraverso le sue porte senza weg

ma con la 6600 che hai in firma? Se si stranissimo non ti dovrebbe servire WEG ne per uno ne per 3 monitor o piu'

Se stacchi weg ed il sistema funziona… per cosa ti serve?

Se sono identici anche a livello di bios si collega le stesse usb che a te vanno e non dovresti avere problemi

@Madsex continua qui se serve ancora risolvere

Ciao, il buon Anto non ha modificato il kext ma lo ha riportato da noi dando anche le indicazioni di chi lo sta modificando Diventerà ufficiale quando sarà approvato da vit9696 (curatore di opencore e di quei kext), e lo diventerà solo quando avranno testato lo stesso con vecchi sistemi e piu' pc/mac possibili..pero' come ho fatto io..se ne trovi uno che ti va bene e non ti da problemi per te...lo utilizzerei (io lo faccio con uno ancora piu' vecchio di questo di loabmac (lo sviluppatore cinese) Detto cio' non credo che sia il kext modificato a crearti il problema del riavvio o del doppio monitor che si aggancia o meno con gli altri kext...

ho usato il kext Whatevergreen solito (di royalgraphX). Aspetto che i dev di opencore validino una soluzione corretta dal loro punto di vista Comunque vit sta dando retta al ragazzo..quindi e' sulla buona strada 🙂

@nobodycanhackmymindse non sbaglio tu stai aggiornando un mac originale ma non ricordo il modello probabilmente per farlo andare in alcune sue parti e' stato utilizzato OCLP (OpenCore Legacy Patcher) per far funzionare le sue componenti al meglio (GPU,WIFI,Ethernet, USB) Purtroppo la forzatura di aggiornarlo a Tahoe non e' recuperabile se non hai la vecchia icona del vecchio OS funzionante HAi solo tahoe su quel PC? se si forse ti conviene installare un sistema suportato su un disco nuovo Oppure aspettare che esca OCLP per tahoe..ma nn e' previsto a breve

Sì sì scusa

@bros la firma con l'hardware e' stto uno spoiler hai un intel 10900k e asus z490 Dal config vedo che hai la mappatura usb via kext, e' aggiornato per sequoia? se quando utilizzi Sequoia togli whatevergreen kext il sistema ti funziona ugualmente?

usando il kext di cui sopra (a me serve whatevergreen kext e quello modificato consente di aggiornare a Tahoe senza fare cambi al volo) delta update di 4.2 Gb da Tahoe 26.01 un riavvio con macOS Installer 2 riavvii con la mia solita icona di boot 🙂 Non ha riattivato il filevault e non ha chiesto nulla al riguardo!

RC…

Sì puó mettere dall’inizio se la propria gpu necessita di whatevergreen per funzionare Poi non é il mio kext 😅 si trova sul GitHub di royalgraphx

non hai forse pulito Nvram? questo e' corretto ma dovresti pulire nvram in quanto ti da un valore diverso nel messaggio che posti Verifica che parti dalla efi corretta 🙂

si si deve cambiare l'ordine dei bytes mi sono dimenticato di dirtelo 🙂

Se sono stringhe non dovrebbero influire forse le prime due peró non so per le vecchie schede

dovrebbe essere il device id della 6900xt che e' ufficialemnte supportata