【Help】Asus X99A II works great in win10, but hackintosh couldn't boot. (PCI configuration begin)

[dawenhaozx]

System

• Motherboard: Asus X99A II
• BIOS Version:2101
• GPU: 6600xt
• [ ✓ ] CSM is turned off
• [ ✓ ] 4G decoding is enabled
• [ ✓ ] UEFIPatch is applied BAR size tested 8GB

Description
First of all thanks to xCuri0 for enabling Resizable BAR on my old motherboard !!!

(I didn't use opencore to boot win10)

I successfully modified the bios and it works fine in win10.（follow the instructions exactly）
I think pcibus patch caused the hackintosh boot fail, But x99aii must use the pcibus patch to successfully enable resizable bar.
If i don't use pcibus patch, Enabling resizable bar will result in a black screen (Using USB Flashback can let CMOS reset) and disabling resizable bar can successfully boot macOS&win10.

# PciBus | Don't downgrade 64-bit BARs to 32-bit (by @Mak3rde)
3C1DE39F-D207-408A-AACC-731CFB7F1DD7 10 P:C70605000000833E067506C70604000000BE01000000:909090909090833E067506909090909090BE01000000

Please help me, can this problem be solved by changing the config.plist of opencore or in other ways?

Screenshot of hackintosh use modified bios.

Modified bios files
bios.zip

[xCuri0]

@dawenhaozx Actually I know the fix for this because I booted OpenCore Hackintosh on my system a few weeks ago (still haven't downloaded it but whatever).

You have to set ResizeAppleGpuBars in your plist to 8 (256mb). This is because macOS doesn't support large BARs

If it still doesn't work and you're seeing RBAR is unsupported by device - Device Error you will need to download the latest OpenCore version from GitHub actions and enable ResizeUsePciRbIo. I submitted the patch to add ResizeUsePciRbIo to OpenCore because I was getting that issue acidanthera/OpenCorePkg#418.

[dawenhaozx]

@xCuri0 Thank you, I've tried it and it still doesn't work. May be the reason of opencore 0.8.9 beta.

ResizeAppleGpuBars=8 boot failed
ResizeAppleGpuBars=8 ResizeUsePciRbIo=enable boot failed

[xCuri0]

@dawenhaozx are you on the latest opencore from GitHub actions ? Only that has ResizeUsePciRbIo

You could try sending your boot log with debug build also

[dawenhaozx]

@xCuri0 I'm using the latest opencore from dortania/build-repo

debug log
opencore-2023-02-12-084435.txt

[xCuri0]

@dawenhaozx does it happen when using the pcibus patch without rebar enabled ?

[dawenhaozx]

@xCuri0 Yes, It seems to be the same problem whether rebar is enabled or disabled.(When i use the pcibus patch)

opencore-2023-02-12-094754.txt

[xCuri0]

@dawenhaozx What the PciBus patch does is make 64-bit BARs (like GPU) get allocated in the 64-bit region which firmware doesn't do by default so that CSM works with 4G decode.

Does disabling ResizeAppleGpuBars (-1) with rebar off not work ?

[dawenhaozx]

ReBarState.exe - disabled
ResizeAppleGpuBars (-1)
ResizeUsePciRbIo - disabled
opencore-2023-02-12-101817.txt

[xCuri0]

@dawenhaozx and this doesn't boot right ?

u could try show device manager view -> resources by type -> memory and scroll to the bottom. should show what got allocated in the 64-bit space

also could try and ask about this in hackintosh communities

[dawenhaozx]

Yes, it stuck at [pci configuration begin]

[xCuri0]

@dawenhaozx the PCIe device BARs are getting allocated at a 48 bit address apparently. Maybe that's too high for macOS. See if there's a BIOS setting to limit it

[dawenhaozx]

@xCuri0 Sincerely thank you for your help. X99A doesn't seem to have such an option in the bios.

[xCuri0]

@dawenhaozx no MMIO option or similar ? Should ask about this issue in some Hackintosh/OpenCore communities, maybe there's a fix for this.

Last thing that can be done is disassembling PciRootBrudge/PciHostBridge and modifying the AddMemorySpace call to use a lower maximum address such as 39 bit

[dawenhaozx]

@xCuri0 I found something different in opencore-debug

The same config.plist setting
_1._Bios not used pcibus patch - on the left of the screenshot
Successfully boot to macOS and the log shows "Allocated new table SSDT at BBC***"
_2._Bios used pcibus patch - on the Right of the screenshot
Failed to boot and the log shows "Allocated new table SSDT at DBC***"

I'm not sure if this is the reason, but after trying many times I found the difference here.

[dawenhaozx]

@xCuri0
Or do I need a DSDT patch？

Large Memory
0000380000000000 - 0000383FFFFFFFFFF

Thank you very much for your help !!!

X99AII DSDT
DSDT.zip

[xCuri0]

@dawenhaozx you need to patch both DSDT and PciHostBridge/PciRootBridge to use a lower address that macOS supports.

OpenCore in-fact mentions that there are some issues with macOS and X99/X299 boards with 4G decoding

Use efiSeek plugin with Ghidra on PciHostBridge/PciRootBridge to find the AddMemorySpace call and modify it to use a lower address. I'm not sure what the maximum BAR address macOS can handle is but you can probably find information about that somewhere.

efiSeek with Ghidra is the same method I used to modify the AddMemorySpace call to increase Ivy Bridge BAR space. All the ReBarUEFI patches I made were done using Ghidra + efiSeek

[dawenhaozx]

@xCuri0 This is too difficult for me to understand. But if you have to solve each motherboard issues, it will undoubtedly increase your troubles. Thank you so much anyway, you are a legend!!!

[xCuri0]

@dawenhaozx If you are able to do it then you can then make a patch that works on all X99 motherboards with the issue.

It is hard to do though yes

[xCuri0]

@dawenhaozx You need to set the MMIOHBase setting to a lower value such as 1TB. It seems to be set to 56TB by default

macOS should handle 41-bit (<2TB) addressing fine because Mac Pro can support upto 1.5TB of RAM.

This setting can be found in the Platform module if its not in BIOS settings IntelRCSetup. I think the settings are stored in IntelSetup variable if it's not a visible option so you can use that with the setup_var tool.

If you do get it working with 1TB you could also try higher values to see what the maximum supported by macOS is

[dawenhaozx]

@xCuri0 I've tried various combinations and still can't solve it.

MMIOHBase 1T ~ 56T
MMIO High Size 128G ~ 1024G

0x15351 One Of: MMIOHBase, VarStoreInfo (VarOffset/VarName): 0x10E2, VarStore: 0x1, QuestionId: 0x1A8, Size: 4, Min: 0x0, Max 0x7, Step: 0x0 {05 9A 0C 00 0D 00 A8 01 01 00 E2 10 10 12 00 00 00 00 07 00 00 00 00 00 00 00}
0x1536B One Of Option: 56T, Value (32 bit): 0x0 (default) {09 0A 14 11 32 02 00 00 00 00}
0x15375 One Of Option: 40T, Value (32 bit): 0x1 {09 0A 13 11 02 02 01 00 00 00}
0x1537F One Of Option: 24T, Value (32 bit): 0x2 {09 0A 12 11 02 02 02 00 00 00}
0x15389 One Of Option: 16T, Value (32 bit): 0x3 {09 0A 11 11 02 02 03 00 00 00}
0x15393 One Of Option: 12T, Value (32 bit): 0x4 {09 0A 10 11 02 02 04 00 00 00}
0x1539D One Of Option: 4T, Value (32 bit): 0x5 {09 0A 0F 11 02 02 05 00 00 00}
0x153A7 One Of Option: 2T, Value (32 bit): 0x6 {09 0A 0E 11 02 02 06 00 00 00}
0x153B1 One Of Option: 1T, Value (32 bit): 0x7 {09 0A 0D 11 02 02 07 00 00 00}
0x153BB End One Of {29 02}
0x153BD One Of: MMIO High Size, VarStoreInfo (VarOffset/VarName): 0x10E6, VarStore: 0x1, QuestionId: 0x1A9, Size: 4, Min: 0x0, Max 0x3, Step: 0x0 {05 9A 0E 00 0F 00 A9 01 01 00 E6 10 10 12 00 00 00 00 03 00 00 00 00 00 00 00}
0x153D7 One Of Option: 256G, Value (32 bit): 0x0 (default) {09 0A 0A 11 32 02 00 00 00 00}
0x153E1 One Of Option: 128G, Value (32 bit): 0x1 {09 0A 09 11 02 02 01 00 00 00}
0x153EB One Of Option: 512G, Value (32 bit): 0x2 {09 0A 0B 11 02 02 02 00 00 00}
0x153F5 One Of Option: 1024G, Value (32 bit): 0x3 {09 0A 0C 11 02 02 03 00 00 00}
0x153FF End One Of {29 02}

[xCuri0]

@dawenhaozx if possible could you show a screenshot of device manager memory like before (showing the hd audio device is important) when using these settings 1T and 128G

also send a DSDT dump from windows using those same settings. seems like the DSDT on your board is dynamically generated as the version extracted with UEFITool is different

I found this https://www.insanelymac.com/forum/topic/321326-cant-get-above-4g-decoding-working-on-x99-e-ws/, they were successful by disabling the GPU but of course that's not ideal.

My only guess at what's going on is that even the 1TB MMIO is too high for macOS.

[xCuri0]

@dawenhaozx you could also try npci=0x2000 or npci=0x3000 in kernel command line in addition to using 1T and 128G. I see some reports that it fixes this issue on X99

[dawenhaozx]

When I set to MMIO Base 1T, MMIO High 128G
large memory pcibus [0000380000000000 - 0000383FFFFFFFFF] becomes [0000380000000000 - 0000381FFFFFFFFF]
6600xt....
.......
I forgot to take a screenshot. I remember changing them and the difference was that xxx383FFxx became xxx381FFx

I have always set npci=0x2000
Anyway, thank you very much for your help

[xCuri0]

@dawenhaozx without npci=0x2000 is it the same because I see some people say it's incompatible with 4g decoding (use 1T and 128GB when testing this).

do send a screenshot when you're able to it would be helpful

[xCuri0]

@dawenhaozx hi any update ?

i was messing with my hackintosh install and saw that the opencore wiki mentions that npci should not be set while 4g decode is on.

Ryzen boards properly allocate 64-bit BARs (GPU) into the 64-bit MMIO region, just like our patched BIOS does so I thought it might be similar.

this is probably the cause of it along with the default MMIO Base being too high (which can be fixed by setting to 1T).

[dawenhaozx]

@xCuri0 It works! Fix it all now!

I sincerely appreciate your help!!!
Remove "npci=0x2000" on boot args and set MMIOHBase=1T~12T (the maximum support I tested)

[jwagnervaz]

Had same problem when i port a native bios Rebar option

Solution to boot with rebar enable in MacOS Sonoma was

npci=0x3000 as boot-arg and
ResizeAppleGpuBars = 0

This Will help everyone with this problem in 99 plataform.