Search the Community

BIG news (not verified by me, in my case it is not working) It boots 🙂 see video below 😂 It seems @Pavobooted with big Sur in A vanilla mode some problems to solve but for him it is booting now 🙂 for me no... You creators users could try 🙂 ops only you @iGPU others users are Asrock 🙂 fabiosun's EFI and ioreg System Description: Ploddles's EFI and ioreg System Description: Arrakis's EFI and ioreg System Description: mSedek's EFI and ioreg System Description: Rox67er's EFI and ioreg System Description: UPDATE 17-07-2021:

Hello fabiosun, Trying to get my MMIO Whitelist info for my X870 MSI. When I use the Opencore Release OC 1.0.3 I get to the Opencore boot menu with no issue. Starts to boot but then boot loop as there is no MMIO Whitelist included in the config. So when I use OC 1.0.3 Opencore.efi debug I get the boot menu as in the attached pic, but then a boot loop. I never get to the Opencore boot menu. Any idea?

Added on 01-08-2021 AMD Clover Vanilla patches Github: https://github.com/AMD-OSX/AMD_Vanilla/tree/clover I have converted only patches mandatory for my chipset and cpu.. you can follow the same schema in nomenclature definitions By the way ,some definitions in clover 5137 are not described well and I think must be update their nomenclature Also MAtchOs need some check and I hope devs will solve a very annoying bug for AMD users 🙂 MAtchOS is not perfect by now in my definition of this plist..but was useful to boot with a clean and also to update from 11.5 beta 4 I used the attached patch plist to install from scratch and then to update Only GoldFish64 patch has some definition problem in CLoverBootloader due Empty Find value (in verbose it prints out a not destructive error) I have also attached two debug log to see problem I have said before and also others job to do. 1)installation debug (GetOS Empty all patches applied.....😇 2) after installation is completed....GetOS detection works as it must do Thanks to patches-manager and creator 🙂 debug_pre inst_inst.zip opencore-2021-07-01-161751.txt.zip for lryzen friend (17h19h) pay attention on patch 43..I commented limit there 😉 thanks @iGPUfor Goldfish64 2F tip! 😉 ------ UPDATE 18-07-2021 https://www.macos86.it/topic/4913-amd-clover-bootloader-monterey-beta-1-installation-patches/?do=findComment&comment=116586 Clover-Kernel_Patches_Quirks.plist.zip

Case: ThermalTake Core X9 Alimentatore: Enermax epm1700egt Piastra Madre: MSI TRX40 Pro 10G CPU: AMD Threadripper 3970x Dissipatore AIO: Enermax Liqtech TR4 II Memorie: Patriot Viper Blackout (4kit) 32Gbx8 NVME1: Sabrent Rocket NVME 1 Tb NVME2: Samsung 960 Pro 1Tb GPU: AMD 6900 XT Masterizzatore BD LG: HD vari: 2 x Seagate Surveillance HDD SkyHawk 6TB 2 x Seagate ST10000VX0004 HDD 10 tb Parametri Bios: 1) Load default 2) 4G abilitato 3) ERP abilitato questo e' valido per tutti i bios prodotti sino ad oggi (21-6-2021) MMIO in questa EFI sono dell'ultimo BIOS: Versione 7C60v174(Beta version) Data di Rilascio 2021-01-11 Anche con i precedenti BIOS ci sono minime differenze su alcuni di essi: EFI ottimizzata per Big Sur con mappatura delle mie memorie e MacPro 7.1 come SMBios 14 patches per il Kernel 1 patch per Aquantia 10 G (Kext patch) EFI.zip EFI_clover5137_14KernelPatches_Big_Sur_11.4_release_.zip 2021-06-27_13-13_BOOTX64.EFI.txt 2.zip

@CaseySJ created some patches to add in our config plist and maybe in a near future OC Devs will insert in their ForceAquantia quirk this is in macOS Ventura, but it should works also in latest Monterey! Thanks to CaseySJ for his great job casey_sj_Aquantia patches.plist.zip

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

TB3 Device: GC Titan Ridge https://www.amazon.it/gp/product/B07K6PW4M1/ Eprom programmer: https://www.amazon.it/gp/product/B07SNTL5V6/ Digital Multimeter: https://www.amazon.it/gp/product/B0872RY4CC/ in this thread we can talk about progress with this latest important goal to achieve. useful link: https://github.com/ameyrupji/thunderbolt-macpro-5-1/blob/master/GC-TitanRidge.md guide to flashing programming from CaseySJ DISCLAIMER: this is a very risky procedure also for experienced users. TAKE NOTE OF THIS. DO AT YOUR OWN RISK

In this thread we can talk about any subject related to AMD 3970x Proxmox VE guide published here:

Hello Fabio, Have you got any tutorial on how to make a threadripper 3970x with proxmox ? Is it better than using the OpenCore way ?

Thanks to iGPU I was able to get shutdown to work using MMIO whitelist, but now when you shutdown it restarts.