Can not get DevirtualiseMmio to output MMIO with OC debug

JohnFante

Member
AMD OS X Member
Nov 18, 2023
59
5
8
Copenhagen, Denmark
CPU:
AMD Ryzen 7 7800X3D
I am trying to revive an old Sonoma install with a new EFI using this: https://github.com/mikigal/ryzen-hackintosh as base.

It does not work atm. Crashes very rapidly after trying to boot Sonoma. See picture of crash. As a solution I was recommend to setup MMIO with DevirtualiseMmio using debug version of OpenCore.

The procedure (using OC 1.03) and the instructions here produces the attached logfile but no MMIO info in it :unsure:

Anyone seeing anything wrong in the config.plist for MMIO logging? I am pretty sure I followed the instructions but can have done something wrong :sneaky:. Just edited the config.plist and replaced OpenCore.efi with the debug version. Only that. (Should I copy the complete package?)

My hardware is the as described in my signature. That should be supported out of the box for that example EFI.

Thank you in advance!
 

Attachments

Last edited:
Try this revised Debug version of OC 1.0.3, see if this gets you any further with your MmioWhitelist query.
 

Attachments

Try this revised Debug version of OC 1.0.3, see if this gets you any further with your MmioWhitelist query.

Thank you very much :).

The EFI generates the attached logfile. Does not seem that there are any MMIO in that either.

This is getting rather strange ....
 

Attachments

It sure why, but definitely no Mmio entries in that log file.

I’ll have a think and see what we are missing from the debug EFI.
 
i think you missed some efi drivrs (not from a debug opencore version i mean)
your EFI only adjusted with them
 

Attachments

i think you missed some efi drivrs (not from a debug opencore version i mean)
your EFI only adjusted with them
Thank you for helping out :)

Unfortunately it did not help. Still no MMIO in the logfile. :unsure:

Completly the same as before. Half a screen of debug on the screen (did not got the time to take a picture). Then the screen goes black but does not turn off. After a minute or so the machine restarts to windows.
 

Attachments

Try this EFI, similar to last one but with debug kexts added to see if this helps. As the EFI contains all the necessary debug quirks and boot settings for the Mmio entries to be generated in the OpenCore log.

Do you have Above 4G Decode enabled in your Bios? If yes, you will need to remove the npci=0x3000 boot argument from the config.plist, before using this EFI.

Don't forget to use the ResetNvram option before booting with the revised EFI.
 

Attachments

@JohnFante sonoma efi was working with hardware system you are using by now?
 
Try this EFI, similar to last one but with debug kexts added to see if this helps. As the EFI contains all the necessary debug quirks and boot settings for the Mmio entries to be generated in the OpenCore log.

Do you have Above 4G Decode enabled in your Bios? If yes, you will need to remove the npci=0x3000 boot argument from the config.plist, before using this EFI.

Don't forget to use the ResetNvram option before booting with the revised EFI.
Thank you. Will try tonight. However, i do not even get to the picker. When I boot from the USB stick. It just gives me "Half a screen of debug on the screen (did not got the time to take a picture). Then the screen goes black but does not turn off. After a minute or so the machine restarts to windows."

I thought this was normal with this debug setting?

I have "Above 4G Decode enabled" as suggested in the bios settings at mikigals repo: https://github.com/mikigal/ryzen-hackintosh. I will remove npci=0x3000.

@JohnFante sonoma efi was working with hardware system you are using by now?
Yes, it was. I have not been using my Hackintosh for a very long time (busy in real life), so I completely destroyed when I tried to update OC and a lot kexts and afterwards I mistook it for a Sequoia install. It is Sonoma. I decided to try to rebuild a new and better suited EFI for my motherboard.

See post here with original, working EFI. https://forum.amd-osx.com/threads/b...ver-after-upgrade-to-oc-1-03.5767/#post-39250

Everything but bluetooth worked - with is to be expected since it is an not supported AMD AMD Wi-Fi 6E RZ616.
 
Try this EFI, similar to last one but with debug kexts added to see if this helps. As the EFI contains all the necessary debug quirks and boot settings for the Mmio entries to be generated in the OpenCore log.

Do you have Above 4G Decode enabled in your Bios? If yes, you will need to remove the npci=0x3000 boot argument from the config.plist, before using this EFI.

Don't forget to use the ResetNvram option before booting with the revised EFI.

Success. That brougt me to the picker :) and created the MMIO:

119:045 00:674 OCABC: MMIO devirt start
119:145 00:100 OCABC: MMIO devirt 0xE0000000 (0x10000 pages, 0x800000000000100D) skip 0
119:242 00:097 OCABC: MMIO devirt 0xF7000000 (0x7E00 pages, 0x800000000000100D) skip 0
119:339 00:097 OCABC: MMIO devirt 0xFEE00000 (0x1 pages, 0x8000000000000001) skip 0
119:438 00:098 OCABC: MMIO devirt 0xFEE01000 (0x11FF pages, 0x800000000000100D) skip 0
119:536 00:098 OCABC: MMIO devirt 0x860000000 (0x20200 pages, 0x800000000000100D) skip 0
119:633 00:096 OCABC: MMIO devirt end, saved 935936 KB
120:305 00:672 OCABC: Only 168/256 slide values are usable!

It halts during booting (see picture) but that can be due to the fact that I forgot to ResetNvram. Will try that next!

Thank you!
 

Attachments

  • Like
Reactions: Edhawk
@JohnFante if you had a previous working EFi with sonoma you have only to update your kernel patches for AMD
Efi proposed has some typo in Nvram section (bootarg like E1000=0 not useful with ethernet kext i see in your kext folder)
Probably in your previous (and working sonoma EFI) you add also some ACPI patches. these patches are mandatory to boot see in your verbose first ACPI error)Screenshot 2025-02-16 at 9.45.15 am.png

You can solve this error with SSDTtime or copying your previous acpi patch set in a working config

then set also this to skip one adding in your MMIO whitelist:
MMIO devirt 0xF7000000 (0x7E00 pages, 0x800000000000100D) skip 0

edit : reading your op and seeing well your signature, motherboard has an intel 2.5 ethernet card, so realtek811 is unesed in your case
you can use and old bifsur/monterey kext with e1000=bootarg or a new kext without bootarg (appleIGC)
 
Last edited:
  • Like
Reactions: JohnFante
Post a copy of your system DSDT.aml table, as you obviously need some changes made to the SSDTs you are currently using to remove the ACPI errors shown in the screenshot above.
 
  • Like
Reactions: JohnFante
Efi proposed has some typo in Nvram section (bootarg like E1000=0 not useful with ethernet kext i see in your kext folder)
Probably in your previous (and working sonoma EFI) you add also some ACPI patches. these patches are mandatory to boot see in your verbose first ACPI error)View attachment 16375

You can solve this error with SSDTtime or copying your previous acpi patch set in a working config

then set also this to skip one adding in your MMIO whitelist:
MMIO devirt 0xF7000000 (0x7E00 pages, 0x800000000000100D) skip 0

edit : reading your op and seeing well your signature, motherboard has an intel 2.5 ethernet card, so realtek811 is unesed in your case
you can use and old bifsur/monterey kext with e1000=bootarg or a new kext without bootarg (appleIGC)
Thank you! I have disabled the Realtek811.kext and enabled the AppleIGC and removed the faulty bootarg. Will remove Realtek completely when I am booting.

I have an old UTBMap.kext from when I mapped the USB-ports using USBToolBox. I had planned to add that again, when I was up and running in MacOS but should I do that allready now? Can it cause issues from the start?

I have also tried to add the MMIO whitelist you suggested. I am however not sure if I have done it correctly. I can not see what address I have to add? See attached config.plist. I am using ProperTree.

I have not tested this config.plist since the whitelist is not correct.

I have also not implemented clear NVRAM. It is not in the picker atm., but maybe there is a keyboard shortcut for that.

Post a copy of your system DSDT.aml table, as you obviously need some changes made to the SSDTs you are currently using to remove the ACPI errors shown in the screenshot above.
I have used SSDTTime-Master to extract the aml files. They are attached. Hope this this helps. Bit unsure how to implement.

Thank you both for all your help! :)
 

Attachments

@JohnFante
attached is your config.plist.
i added a proper converted from hex to number MMIO area from your debug log
and i added also ACPI patch done using your DSDT and SSDTime script

this should allow you to by pass Gigabyte mistake on acpi and also MMIO hang
I have no checked at my best the other parts of your config.plist (also if you change some bios option or you add some nvme drive MMIO are could change
so if you like to try this config use the same option in your bios you had when you did your opencore debug log
 

Attachments

  • Like
Reactions: Edhawk
Here is a copy of the Results folder I created using the DSDT.aml and SSDT-2.aml table from the OEM folder containing the ACPI tables from your system. I used both of these tables in Corpnewt's SSDTTime script to generate these SSDT's, the DSDT-Patched.aml table and the associated ACPI patches in the patches_OC.plist.

You need to take a copy of the tables shown below and add them to your /EFI/OC/ACPI folder. Replacing any SSDTs or Patched-DSDT you are currently using. As at least one of the current tables plus your system DSDT.aml contains an error.

Screenshot 2025-02-16 at 16.20.53.png

You then need to open the patches_OC.plist and copy the ACPI patches to your config.plist.

MmioWhitelist:

I have taken the 5 x MmioWhitelist entries you found in your OpneCore Log and converted all 5 to an appropriate patch that needs to go in your config.plist, as shown below.

Screenshot 2025-02-16 at 16.36.49.png

Only the first entry has been Enabled. As you need to boot your system with only one patch at a time. You need to test all 5 x patches individually to see which one (or more than one) is needed to work with your system. Tedious yes, but necessary.

Don't forget to use the ResetNvram option between each test, so the previous patch is cleared before the next is used.

I have attached a copy of the document I used to create the MmioWhitelist patches, which is specific to your system. But it shows how I went from the Mmio Log entries, to create the Patch Comments and finally the Hex to Decimal conversion to create the Mmio Address (Number).

I have also attached a copy of the config.plist containing the ACPI SSDTs, the ACPI patches and the MmioWhitelist entries. You can use this once you have added the named SSDTs and the Patched-DSDT.aml tables to your /EFI/OC/ACPI folder.

You need to add you SMBIOS data as well before using it.
 

Attachments

  • Like
Reactions: JohnFante
Here is a copy of the Results folder I created using the DSDT.aml and SSDT-2.aml table from the OEM folder containing the ACPI tables from your system. I used both of these tables in Corpnewt's SSDTTime script to generate these SSDT's, the DSDT-Patched.aml table and the associated ACPI patches in the patches_OC.plist.

You need to take a copy of the tables shown below and add them to your /EFI/OC/ACPI folder. Replacing any SSDTs or Patched-DSDT you are currently using. As at least one of the current tables plus your system DSDT.aml contains an error.

View attachment 16380

You then need to open the patches_OC.plist and copy the ACPI patches to your config.plist.

MmioWhitelist:

I have taken the 5 x MmioWhitelist entries you found in your OpneCore Log and converted all 5 to an appropriate patch that needs to go in your config.plist, as shown below.

View attachment 16382

Only the first entry has been Enabled. As you need to boot your system with only one patch at a time. You need to test all 5 x patches individually to see which one (or more than one) is needed to work with your system. Tedious yes, but necessary.

Don't forget to use the ResetNvram option between each test, so the previous patch is cleared before the next is used.

I have attached a copy of the document I used to create the MmioWhitelist patches, which is specific to your system. But it shows how I went from the Mmio Log entries, to create the Patch Comments and finally the Hex to Decimal conversion to create the Mmio Address (Number).

I have also attached a copy of the config.plist containing the ACPI SSDTs, the ACPI patches and the MmioWhitelist entries. You can use this once you have added the named SSDTs and the Patched-DSDT.aml tables to your /EFI/OC/ACPI folder.

You need to add you SMBIOS data as well before using it.
Thank you very much!

I added the .aml files and tried both your config.plist and one that I edited. I got a bit further in the boot but still no succes. Added the log and a picture of where it got to.

I have not been able to reset NVRAM. Nothing happens when I press space to get the option.

Will check more tomorrow.
 

Attachments

Thank you very much!

I added the .aml files and tried both your config.plist and one that I edited. I got a bit further in the boot but still no succes. Added the log and a picture of where it got to.

I have not been able to reset NVRAM. Nothing happens when I press space to get the option.

Will check more tomorrow.
attached config is based from Edhawk's one
a bit simplified till you achieve a working boot
if you like to try (first backup yours)
 

Attachments

  • Like
Reactions: JohnFante
attached config is based from Edhawk's one
a bit simplified till you achieve a working boot
if you like to try (first backup yours)
Thank you very much. As @Edhawk suggested I am going through the different MMIO whitelist settings. Will take a day or two ...

Managed to enable clear NVRAM. Turned off HideAuxiliary and there it was :)
 
Have you tried my config.plist?🥹
 
  • Like
Reactions: JohnFante
  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.