fabiosun

Monterey 12.2.1 (21D62)

non e' nel developer seed o almeno io sono in quello standard

per audio interno devi trovare alcid utile per te nel caso ora e' impostato su 1 ah, disattiva il debug in quanto quello che ti fa ora non e' utile perche' non stai usando un opencore debug metti in Misc/debug il valore 3 al posto di 67

Non serve ricambiare 🙂 Felice per te che abbia funzionato Mi permetto di consigliarti di dare un'occhiata al config e togliere tutti i kext che hai e che ho disabilitato Poi verifica se ti va l'audio e la rete ma li devi rifinire un po' controllando i pezzi che hai nell piastra madre (Wifi, BT etc)

poi se parte fai vedere come ti vede ora il tutto e per la ram credo devi abilitare il profilo XMP nel bios se presente o forzarle a mano alla frequenza che hai Non conosco bene la tua CPU e non so cosa supporta per le ram

Archive.zip sostituisci il config e copia il kext dentro la cartella kext

ok un attimo e proviamo a sistemare

con che config sei partito? se ultimo avevo disabilitato la video io

nel bios hai disabilitato la porta seriale o parallela? se le hai ovviamente

si sempre li ma la base della EFI da cui partire e' questa config.plist.zip sempre se vuoi prova questo config

adesso bisogna personalizzarla per la nuova scheda intanto prova questo config e vedi se s ferma sempre li config.plist.zip ho disattivato diversi kext e messo Dummypowermanagement al posto del vecchio kext

ricordati che la tua Vega interna non va e che la 710 ha perso il supporto in Monterey vediamo se comunque t parte il nuovo sistema

EFI.zip Guarda questa si basa sulla tua vecchia efi con le nuove patches Secondo me hai dei kext che oggi sono superati come il nullCPUPowermanagement cmq se vuoi prova a partire con questa qui poi al limite se si blocca vediamo dove

ecco questa e' diversa e usa tutte le vecchie patches nella nuova versione le patches sono di meno e vanno personalizzate

Ciao jury se mi passi la battuta...se davvero con questa EFI ti partiva Big Sur sei campione del mondo dei miracoli Devi configurare la patch core count per la tua CPU ora sono impostate di default e non vanno bene e poi devi attivare il quirk in kernel /ProvvideCurrentCPU info di seguito invece le patches che devi adattare al tuo numero di core count Se posti la configurzione che ti andava con l'altra motherboard (basta solo il config.plist) possiamo provare a vedere di farla andare

Ok e grazie problema differente qui non era una EFI corrotta ma qualcosa dì più profondo

E' piu' grande se parti da 12.2 da beta 1 di 12.3 e' come ti dice

https://github.com/AMD-OSX/AMD_Vanilla/pull/185 useful for all AMD users not only for us (trx40 users)

Ti ricordi che errore ti dava? ieri mi è successa una cosa strana con opencore dopo la scansione dei dischi del bios prima dì arrivare al menu mi dava un errore sb nvram ed errore critico clover invece partiva sono riuscito a far ripartire opencore dì nuovo solo facendo un clear cmos. devo dire che sto facendo molte prove al limite e che non credo sia colpa dì OCAT

In this thread we will try to explain the function of this very interesting quirk and above all of the related section of MMIO Whitelist which is even more fundamental for different systems. The topic has been recently documented in a more exhaustive way in the OpenCore configuration pdf, but nowadays it has assumed more and more value to have a Hackintosh at its maximum potential also in light of the new CPU architectures in use. By default the quirk is not active and for many systems it is not essential to make your hack work and start. In December 2019 with the release of the third generation AMD ThreadRipper CPUs (sTRX4), many users, despite themselves, were forced to take an interest in the functioning of the quirk in question. At that time the OpenCore documentation on the subject was not very exhaustive also because it was a quirk useful only for old systems. With the sometimes cryptic help of the OpenCore developers (to whom thanks are always due for their work) they started to take the first steps to understand how to use it to debug on a platform like the one described above ( sTRX4) in conjunction with the MMIO Whitelist functionality. link By activating the quirk and only using a debug version of OpenCore with the Misc / Debug / Target option set to 67, it is possible, even with a machine that does not start, a debug in which the MMIO areas of your PC are highlighted (number of areas and values may vary): 08:808 00:001 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0 08:809 00:001 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0 08:810 00:001 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0 08:811 00:001 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0 08:812 00:001 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0 08:813 00:001 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0 08:814 00:001 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0 08:816 00:001 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0 08:817 00:001 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0 08:818 00:001 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0 08:819 00:001 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0 08:820 00:001 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0 08:821 00:001 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0 08:822 00:001 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0 08:823 00:001 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0 08:825 00:001 OCABC: MMIO devirt 0x4040000000 (0x10400 pages, 0x8000000000000001) skip 0 08:826 00:001 OCABC: MMIO devirt 0x8BB0000000 (0x10400 pages, 0x8000000000000001) skip 0 08:827 00:001 OCABC: MMIO devirt 0x8BE0000000 (0x10400 pages, 0x8000000000000001) skip 0 08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 0 It is of particular importance that these areas can be different even under conditions of the same BIOS and manufacturer, but only by swapping options in the BIOS or filling the nvme and pciexpress slots differently. Note: a common mistake is to take this list from any configuration and put it in your config.plist It must always be taken and calculated in the system in use and rechecked if you change options in the BIOS or add hardware! Activating the quirk involves having devirtualized memory areas and in some cases freed several megabytes of memory (typically from 64 to 256 Mb) which allows some problematic systems to start without having the notorious error at boot (memory allocation errors), and this right in the initial stages of the boot. skip 0 means devirtualized area and if during its internal operations UEFI bios needed that area, not having it at its disposal, malfunctions or Kernel Panic would be created. On the indications of the Opencore devs we concentrated on the last 4 areas which are the most substantial at the level of pages to possibly devirtualize and with 16 combinations (4!) It was established that the Kernel patches in use at the time were malfunctioning for sTRX4 systems. Let's now neglect this statement which turned out to be not exactly correct, but then it was practically a fact that led many sTRX4 users with the desire to use OSX on their machines to explore the fascinating world of ProXmox virtualisation. Now the tests made at the time were to report the last 4 areas to full use of OSX (skip 1) in various combinations (16). How? By adding these areas in the Booter / MmioWhitelist section of our config.plist. To do this we are helped by the scientific calculator or the excellent app in the download area HackCheck (visible in the photo) for download it click below: https://www.macos86.it/files/file/95-hack-check/ now let's just focus on the area: 08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 0 and take the hexadecimal value 0xD750000000, this will be converted into a number as shown in the figure below: and must be reported precisely in the appropriate area of the config.plist by activating it: After saving the config.plist and restarting we will have this situation in our next debug log: 08:808 00:001 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0 08:809 00:001 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0 08:810 00:001 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0 08:811 00:001 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0 08:812 00:001 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0 08:813 00:001 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0 08:814 00:001 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0 08:816 00:001 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0 08:817 00:001 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0 08:818 00:001 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0 08:819 00:001 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0 08:820 00:001 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0 08:821 00:001 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0 08:822 00:001 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0 08:823 00:001 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0 08:825 00:001 OCABC: MMIO devirt 0x4040000000 (0x10400 pages, 0x8000000000000001) skip 0 08:826 00:001 OCABC: MMIO devirt 0x8BB0000000 (0x10400 pages, 0x8000000000000001) skip 0 08:827 00:001 OCABC: MMIO devirt 0x8BE0000000 (0x10400 pages, 0x8000000000000001) skip 0 08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 1 So the area we converted and inserted into the config by activating YES is now listed in the config as skip 1. What does it mean? It means that now this area is again available to UEFI Bios as if we hadn't activated the quirk..but only this MMIO area. If in the lucky hypothesis that our system starts anyway and arrives at login, it is possible to proceed to insert and activate all the other areas in MMIOWhitelist until we find the one that is harmful in our system. What is a useful goal for the user who needs to use this procedure? Get back as many skip 1s as possible! If I activate the DevirtualizeMMIO quirk and whitelist all areas by activating them, what happens? First option: - system starts properly! Well you wasted a lot of time because you don't need this procedure! having all areas declared and activated in the config plist section Booter / MmmioWhitelist is like leaving the DevirtualiseMMIO quirk set to OFF. Second option: - system does not start properly! Very well that's why you activated the quirk, if it were possible for us to keep everything unchanged we would not have activated the quirk. So, with holy patience, they try to convert all the values one by one and insert them in MMIOWhitelist (skip 1) until they find those that cannot be inserted and that block your system. At this point, if your ideas aren't more tangled up than when you started reading, you should ask yourself: why do this operation of re-making available to UEFI Firmware as many areas as possible? Simple, even if your PC starts and seems to work correctly only by activating the DevirtualiseMMIO quirk, during daily operation you could (certainly have) KP, Reboot problems or simply malfunctions of the Nvram and the sleep / wake cycle. So it's a good thing to waste some time re-assigning them to free use of UEFI Bios until you find or find the ones that are impossible to reassign! you can also find useful tip here: https://www.macos86.it/topic/3307-trx40-bare-metal-vanilla-patches-yes-it-worksbutproxmox-is-better/?do=findComment&comment=85469

Updated to 12.3 beta 2 with Clover boot loader and MacPro7.1 Smbios without problem

ci sei riuscito mi sembra comunque dal profilo impostazioni account Firma/signature

No non completamente e mantenere un sistema ProxMoxSolo per quello non varrebbe il tempo perso per configurarlo