Ongoing Progress - Big Sur on Gigabyte B550 Vision D - AMD Ryzen 7 3700X - Thunderbolt 3

[DJ4MC]

Reserved

Awesome, How did I know you would dive into this right after Tony Mac announced they would allow AMD! I'm still loving my Z390 build. I will convert to OpenCore by winter. Right now only thing really lacking is PCI4.0 on Intel hardware. Go @CaseySJ !!!!!!

 

[Bansaku]

@CaseySJ
I am curious, have you considered the ITE Device(8595) that is shared with the USB bus is preventing sleep? Over at AMD OS X there had been quite a bit of discussion regarding sleep and the ITE device that seems present on (at least) Gigabyte boards.
Also, have you tried Clover? Check out my build's Clover folder I included in my write-up.

 

[CaseySJ]

@CaseySJ
I am curious, have you considered the ITE Device(8595) that is shared with the USB bus is preventing sleep? Over at AMD OS X there had been quite a bit of discussion regarding sleep and the ITE device that seems present on (at least) Gigabyte boards.
Also, have you tried Clover? Check out my build's Clover folder I included in my write-up.

Hello @Bansaku,

There is an ITE Tech 0x5702 controller for RGB Fusion 2.0. The same controller exists on Gigabyte's Z490 Vision D and Vision G, but on those (Intel) platforms there's no issue with sleep and wake.

This is a good opportunity to provide an update on the wake-from-sleep status:

• The Gigabyte B550 Vision D appears to have IT8795E. Photo attached. I hope I photographed the right chip. This chip is supported in SMCSuperIO.kext (which is available with VirtualSMC) but we don't use that on AMD motherboards (although I've never tried). We use SMCAMDProcessor.kext, which depends on AMDRyzenCPUPowerManagement.kext. However, IT8795E is not supported there at this time.
  
  
• However, on my X570 Taichi, sleep and wake both work under Big Sur and none of the following is used on that system:
  • SMCSuperIO.kext
  • SMCAMDProcessor.kext
  • AMDRyzenCPUPowerManagement.kext

Will check your build report now.

 

[CaseySJ]

CaseySJ,

Disabling the last 4 of MmioWhitelist was on the recommendation of vit9696. If you change anything of note in BIOS, you need to re-run the list in OC debug (such as ± Above 4G, etc).

I've sporadically seen sleep work on my MSI TRX40 Creator, and think that there may be an interaction between MmioWhitelist as well as the kernel patches (and possibly the OS version; no sleep with Big Sur ß6 or ß7).

I've written a few SSDT for the USB devices to re-define XHC and XHC1-4 on the TRX40 (which help with populating Hackintool), but have not noticed any improvements with USBPort.kext files, and have not them. Do you prefer USBPort.kext over SSDTs?

***

You might also check whether the last Patch (algrey - mtrr_update_action - fix PAT) is needed to boot. On the TRX40, it was shown to have a significant impact on GPU function, specifically lowering FPS in Cinebench-15 by 40% when enabled. (Disabling had no other notable effect.)

And a few others were needed to get Big Sur ß7 working on the TRX40 (and likely your build). Attached is a minimum Patch list (fix PAT already removed) that can be copied and pasted into your config file to try. On the TRX40, these patches boot Mojave, Catalina and Big Sur (including the latest ß7 released last week).

-rj510 (aka iGPU)

Hello @rj510,

Thanks for the insights. I tried devirtualizing only the last 4 entries in MMIO White List (i.e. unchecking the box devirtualizes them when DevirtualizeMMIO is checked on). However, the system does not complete the boot process.

So far I can enter sleep every time and with the use of SSDT-SBRG (which changes the Device/Vendor ID of SBRG to an Intel-based LPCB device), then the system begins the wake process, an empty video signal is sent to monitor (which wakes up the monitor), and the system responds to ping.

But then an avalanche of zone_map_exhaustion logs take over. This may be due to a runaway memory leak or due to a process that is asking for way too much memory. These are kalloc calls, which are memory allocation requests at the kernel level (i.e. by the kernel or kernel extensions). Unfortunately, the kernel begins killing all processes in the system in an effort to free up memory, and wake does not occur.

 

[CaseySJ]

@CaseySJ - How do you get such detailed logs? What is the configuration to do that? Can you please explain?

I am also just having one problem with my Hackintosh and that is Wake from Sleep, but I have an Intel Kaby Lake with UHD630 graphics... still trying to debug, but cannot get the type of logs that you are getting. Any advice on how to get such detailed logs would be great!

Thanks!

Great question! It took me a while to figure this out...

• When the system sleeps, I press a key to begin the wake process.
• I give the system 30-60 seconds.
• If it doesn't wake (and it certainly hasn't so far), I press and hold the power button to shutdown the system.
  • If you press the Reset button, you will lose the wake log!
  • If you press the Power button down until the system turns off, it seems the NVMe SSD flushes its buffers and saves the wake log.

Then after powering up the system, I do the following in Terminal:

% log show --last 5m > system-log.txt

• You can replace 5m with as many minutes as you like.
• You can also use h for hours (i.e. --last 1h for last 1 hour).
• Whenever I hit a key to begin the wake process, I note down the current time. When I've booted the system back, I know how much time has elapsed, so I create a log that goes only that far back in time.

When the log file is created, these are the keywords to look for:

• SLEEP_STATE
  • This will be the start of the transition from ON_STATE to SLEEP_STATE.
  • This will take around 30-40 seconds.
    
• PMRD: System Wake
  • This will be the start of the transition from SLEEP_STATE to ON_STATE.
  • This is the really juicy part for troubleshooting wake problems. Here's an example:
    

 

[CaseySJ]

@CaseySJ - How do you get such detailed logs? What is the configuration to do that? Can you please explain?

I am also just having one problem with my Hackintosh and that is Wake from Sleep, but I have an Intel Kaby Lake with UHD630 graphics... still trying to debug, but cannot get the type of logs that you are getting. Any advice on how to get such detailed logs would be great!

Thanks!

Here are some lesser known settings to use (they have improved stability for me):

• AMD CBS --> FCH Options:
  • Disable I2C
  • Disable ESPI
• Disable Trusted Computing
• Platform Power --> Enable Power Loading

 

[CaseySJ]

*** WAKE FROM SLEEP IS WORKING! ***
But there's a catch.​

As mentioned in an earlier post, the wake log was showing the following USB issues:

kernel: (AppleUSBXHCI) 000097.916083 PO9@00900000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.916094 PO9@00900000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0e000e63)
kernel: (AppleUSBXHCI) 000097.917338 PO10@00a00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.917349 PO10@00a00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000e63)
kernel: (AppleUSBXHCI) 000097.918603 PO11@00b00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.918614 PO11@00b00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000663)
kernel: (AppleUSBXHCI) 000097.966204 PO9@00900000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.966211 PO9@00900000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0e000e63)
kernel: (AppleUSBXHCI) 000097.969157 PO10@00a00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.969167 PO10@00a00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000e63)
kernel: (AppleUSBXHCI) 000097.970407 PO11@00b00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.970417 PO11@00b00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000663)

We can see that only USB ports P09, PO10, and PO11 have this problem. These are all dedicated USB 2.0 ports. We know that USB 3.0 ports support both USB 3.0 and USB 2.0 protocols, so those ports are okay.

These three ports are on the PTXH controller. The following was done:

• Created an SSDT that includes all ports on the PTXH controller except PO9, PO10, PO11.
• Created a USBPorts kext that similarly includes all PTXH ports except PO9, PO10, PO11.

After this, the system sleeps and wakes properly!

So what's the catch??

• Port PO9 is the black USB 2.0 port on the top left of the IO panel
• Port P010 is a USB 2.0 hub that includes:
  • The other black USB 2.0 port on the rear IO panel
  • The two internal USB 2.0 headers
  • The Bluetooth module on the M.2 WiFi/BT card
• Port PO11 is the ITE Tech 0x5702 RGB Fusion 2.0 controller

Real-world impact:

• We can live without the two black USB 2.0 ports on the rear IO panel.
• But PO10 includes the two internal USB 2.0 headers and the M.2 WiFi/BT card.
  • For internal USB 2.0 ports, we could purchase a PCIe card
  • For Bluetooth, we could purchase a USB Bluetooth dongle
• Port PO11 is the RGB Fusion 2.0 controller.
  • We won't be able to use liquidctl to control on-board RGB and Addressable RGB headers.

Alternative 1:

• We can enable PO9, PO10, PO11 and decide instead to avoid sleep/wake
• We can configure System Preferences --> Energy Saver to turn off the display after N minutes, but keep the computer running
• Computer will be running in low-power mode thanks to AMDRyzenCPUPowerManagement.kext

Alternative 2:

• Find a way to make sleep work even with PO9, PO10, PO11 turned on.
• Will this require patching the AppleUSB20XHCIPort function in the appropriate kext?

Alternative 3:

• Future update to macOS might handle this case?
• We know macOS has some issues with USB drivers.

P.S. Sleep/Wake also works with AMDRyzenCPUPowerManagement.kext and SMCAMDProcessor.kext. So we don't have to compromise on CPU power management and Fan/Temp monitoring! However, these kexts are buggy/unstable in Bug Sur at this time.

The OpenCore 0.6.1 EFI for this configuration has been posted here:

Ongoing Progress - Big Sur on Gigabyte B550 Vision D - AMD Ryzen 7 3700X - Thunderbolt 3

This thread chronicles on-going progress of installing macOS 11.0 Big Sur on an AMD Ryzen Hackintosh based on Gigabyte B550 Vision D and Ryzen 7 3700X processor. This post composed and posted from B550 Vision D AMD Ryzentosh Why B550 Vision D? The B550 Vision D (Amazon link; Gigabyte link)...

www.tonymacx86.com

 

[scottkendall]

Not sure if your safari issue is AMD related while it does not bring my system down it crashes a few times a day. Messages also crashes and then reopens it self somewhere else near the dock.

 

[CaseySJ]

Not sure if your safari issue is AMD related while it does not bring my system down it crashes a few times a day. Messages also crashes and then reopens it self somewhere else near the dock.

I believe all of my instability issues were stemming from AMDRyzenCPUPowerManagement.kext. With it disabled, I haven't experienced a single crash so far. We'll need to wait for this kext to be more fully debugged with Big Sur.

 

[scottkendall]

I believe all of my instability issues were stemming from AMDRyzenCPUPowerManagement.kext. With it disabled, I haven't experienced a single crash so far. We'll need to wait for this kext to be more fully debugged with Big Sur.

Lots of stuff need to be more fully debugged with Big Sur... Acrobat Pro, Safari, Message!