Contribute
Register

Upgraded to RX580, screen goes black during startup

Status
Not open for further replies.
I couldn't see anything wrong in your Bootlog.txt, for a system of this age.

As your CPU doesn’t have an IGPU, you don't need to use the Intel Framebuffer settings.

Patching an AMD framebuffer for the RX5800 is a lot more work and a lot more complicated.

This is the System Information > Graphics report for my iMac1 system in my signature below, which uses an RX580 to drive two displays:

Screenshot 2021-01-30 at 20.32.58.png

As you can see the two images are pretty similar with regards the RX580 device, the main difference is I have higher resolution at 2560x1440@60Hz (pair of Dell U2515H monitors) and the Connection Type is shown, as Thunderbolt\DisplayPort. So it is not an issue with macOS not recognising your RX580.

According to your Bootlog.txt, the RX580 is being initialised as part of the boot process, see the screenshot below from near the end of the bootlog:

Screenshot 2021-01-30 at 21.08.24.png RX580 Deinited.

Don't worry about the line above that says ATI injection not set, both of my systems using RX580 dGPU's have the same entry.

Your Acer V173 monitor has a native resolution of 1280 x 1024, but only has a VGA connection and this VGA connector is possibly the reason for the Black Screen issue on this monitor. I assume you are using a HDMI to VGA adapter. Apple don't support the use of VGA connectors. Some people are lucky and the VGA connection on their system is identified as a DisplayPort. This can result in the VGA working under macOS. However, this is not native nor is is expected functionality.

Your Dell 1901FP monitor, also has a native resolution of 1280 x 1024, has a DVI connector, which I hope you are using directly via the DVI port on the RX580, and not via any adapter. This connection should work, if the Bios is set correctly, the RadeonDeInit option is enabled in the config.plist, you have Lilu.kext and WhateverGreen.kext installed/being injected by your bootloader.

You may want to try adding the SSDT-RX580 attached below to your /CLOVER/ACPI/patched folder. See if that helps with the black screen issue. Use of this SSDT assumes your RX580 is located in the top x16 PCIe slot on your motherboard.

The SSDT may need to be adapted to match with the ACPI address for your RX580. It is currently set to work on the ACPI address (_SB.PCI0.PEG0). You would need to check Hackintool app > PCIE tab or your IOReg to see what address your RX580 uses.
 

Attachments

  • SSDT-RX580.aml.zip
    1.3 KB · Views: 72
Hi Ed!
Thanks again for your suggestions!
I have gotten rid of the HDMI to VGA monitor and I am just using the single monitor with just a single DVI-D cable connected-- no adapters.

I added the file you supplied to the folder /EFI/EFI/Clover/ACPI/Patched/
Is that all that I have to do to adopt it or are there configuration changes I need to make as well?

I am embarrassed to admit it but I haven't been able to figure out how to open the SSDT-RX580.aml file into something that wasn't machine code. Is there an app you can recommend to decompile it?

I was able to download Hackintool and take a peek at the PCIe devices but I couldn't find a ACPI address similar to the one you listed. I attached the new system report display info and the plain text list of PCIe devices.

As it stands, I am still booting into black screen at the same point. I wish I had newer monitors with more diverse inputs to test with but unfortunately I won't for at least a few weeks.

I also wanted to note that I was browsing through the WEG documentation and they write that legacy bios computers are not compatible with WEG, they say that certain aspects may work but there are documented multiple output display bugs that will not be addressed so it feels a bit like no man's land.

"What are the hardware requirements for WhateverGreen?
Full UEFI without CSM. You are strongly recommended to flash a UEFI-compatible ROM unless your card already has it. Failing to do so will quite likely result in issues in multi-monitor configurations and possibly even in single-monitor configurations. It may still work for non-UEFI motherboards, try at your own risk. There are known issues when using 2 or more GPUs in multi-monitor configurations."


While reading through the Boot Arguments I tried a few other things that didn't help including:
-raddvi
gfxrst=1
gfxrst=4
-igfxvesa
-radcodec
-rad24
-radvesa (this one is kind of interesting because it causes the display to hang unlike the others though the computer still boots and is accessible via screenshare.)

Not really sure what to try next. Will keep reading through documentation, googling things and sharing my progress. Any additional help is greatly appreciated!
 

Attachments

  • pcidevices.txt
    7.1 KB · Views: 56
  • Screen Shot 2021-01-30 at 9.13.12 PM.png
    Screen Shot 2021-01-30 at 9.13.12 PM.png
    415.5 KB · Views: 58
According to the pcidevices.txt output your RX580's ACPI address is (_SB.PCI0.NPE3.GFX0), the actual ACPI address has been truncated by the export to txt file.

The SSDT I provided above is set to work with an ACPI address of (_SB.PCI0.PEG0.PEGP), so the SSDT-RX580.aml definitely needs editing.

When Editing SSDT's or your DSDT you need to use an application such as MaciASL. Acidanthera has created/forked a version of this application, which is available from his GitHub repository. Rehabman has a version of this application on his GitHub site which I have used for a number of year, but unfortunately that version is no longer updated.

I have disassembled the SSDT-RX580.aml so the table can be edited, using Terminal and the following command - iasl -dl SSDT*.aml. As when in the .aml state these tables can be not be edited. They need to be in the 'Disassembled ASL File' format for any changes to be made.

Screenshot 2021-01-31 at 14.40.50.png Save as menu from MaciASL - Disassembled ASL file format

Once the Table has been edited, it then needs to be saved to the 'ACPI Machine Language Binary' format. The .aml tables can be used to help your system.

Screenshot 2021-01-31 at 14.41.55.png Save as menu from MaciASL - ACPI Machine Language Binary format

I would ask you to try the attached SSDT-RX580-NPE3-GFX0.aml in your system to see if that helps.

I would also recommend you add another SSDT to your /CLOVER/ACPI/patched folder. One that accompanies the WhateverGreen.kext download, SSDT-PLNF.aml, as that may also help with the Black Screen issues you are facing.

Try them separately, and then together, so you can see what if any difference the two SSDT's make.
 

Attachments

  • SSDT-PNLF.aml.zip
    1.4 KB · Views: 44
  • SSDT-RX580-NPE3-GFX0.dsl.zip
    2.4 KB · Views: 51
Hi Ed.
Thank you for this! I tried one at a time and both together and none of them worked (one of the files you shared was .dml so I used MaciASL to recompile it into a .aml file before adding to my EFI partition. Thanks for sharing these tools with me. I replaced the Whatevergreen kernel extension with the most up to date whatevergreen debug kernel extension so that I could try to get a better window into what exactly is happening.

I was able to see the system logs using Hackintool and I found this line right at the point that the screen goes black:

2021-02-01 10:53:33.534772-0500 localhost kernel[0]: IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, now 0, sm 0x0
2021-02-01 10:53:33.536292-0500 localhost kernel[0]: (kernel) SMCBatteryManager bmgr: @ failed to find batteries or adapters!
2021-02-01 10:53:33.536415-0500 localhost kernel[0]: (kernel) SMCBatteryManager smcbus: @ BatteryManager probe failure
2021-02-01 10:53:33.537179-0500 localhost kernel[0]: (kernel) SMCBatteryManager bmgr: @ failed to find batteries or adapters!
2021-02-01 10:53:33.551149-0500 localhost kernel[0]: (kernel) SMCLightSensor alsd: @ No iterator
2021-02-01 10:53:33.629083-0500 localhost kernel[0]: _dlil_attach_flowswitch_nexus kern_nexus_ifattach host failed 45 en6
2021-02-01 10:53:33.657673-0500 localhost kernel[0]: PMRD: power event 7 args 0x2c9e9c483efcf97 0x0
2021-02-01 10:53:33.657952-0500 localhost kernel[0]: PMRD: destroyed capability client set 0x2c9e9c48323ab57
2021-02-01 10:53:33.658283-0500 localhost kernel[0]: (IOGraphicsFamily) <IOGraphicsFamily`IOFramebuffer::systemPowerChange(void*, void*, unsigned int, IOService*, void*, unsigned long)> GTrace synchronization point c
2021-02-01 10:53:33.658578-0500 localhost kernel[0]: kPEDisableScreen 1
2021-02-01 10:53:33.737535-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: com.apple.Ambien(233) deny(1) mach-lookup com.apple.windowserver
2021-02-01 10:53:34.079778-0500 localhost kernel[0]: kPEDisableScreen 1
2021-02-01 10:53:34.081786-0500 localhost kernel[0]: kPEDisableScreen 1
2021-02-01 10:53:34.116511-0500 localhost kernel[0]: PMRD: setAggressiveness(0) kPMMinutesToSleep = 0
2021-02-01 10:53:34.492912-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 1 duplicate report for com.apple.Ambien deny(1) mach-lookup com.apple.windowserver
2021-02-01 10:53:34.492922-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: nsurlsessiond(194) deny(1) file-write-create /private/var/db/nsurlsessiond/Library

Whats interesting to me is the "kPEDisableScreen 1"

I might be onto nothing here but I thought it was worth mentioning.

A bit later, there is an attempt to re-enable the screen:

2021-02-01 10:53:35.815538-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 6 duplicate reports for nsurlsessiond deny(1) file-write-create /private/var/db/nsurlsessiond/Library
2021-02-01 10:53:35.815549-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: MRT(68) System Policy: allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db
2021-02-01 10:53:35.815689-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 1 duplicate report for MRT allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db
2021-02-01 10:53:35.815698-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: MRT(68) System Policy: allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-wal
2021-02-01 10:53:35.815835-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 1 duplicate report for MRT allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-wal
2021-02-01 10:53:35.815843-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: MRT(68) System Policy: allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-shm
2021-02-01 10:53:35.830853-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 1 duplicate report for MRT allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-shm
2021-02-01 10:53:35.830863-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: MRT(68) System Policy: allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db
2021-02-01 10:53:35.830974-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 1 duplicate report for MRT allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db
2021-02-01 10:53:35.830984-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: MRT(68) System Policy: allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-wal
2021-02-01 10:53:35.831092-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 1 duplicate report for MRT allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-wal
2021-02-01 10:53:35.831101-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: MRT(68) System Policy: allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-shm
2021-02-01 10:53:35.831336-0500 localhost kernel[0]: (Sandbox) <Sandbox`sb_report> Sandbox: 1 duplicate report for MRT allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db-shm
2021-02-01 10:53:35.831347-0500 localhost kernel[0]: (Sandbox) <Sandbox`kernel_report> Sandbox: MRT(68) System Policy: allow file-read-metadata /private/var/db/CoreDuet/Knowledge/knowledgeC.db
2021-02-01 10:53:35.955083-0500 localhost kernel[0]: kPEEnableScreen 1
2021-02-01 10:53:35.979698-0500 localhost kernel[0]: (IOSurface) <IOSurface`IOSurfaceRootUserClient::s_log(IOSurfaceRootUserClient*, void*, IOExternalMethodArguments*)>
2021-02-01 10:53:35.979753-0500 localhost kernel[0]: (IOSurface) <IOSurface`IOSurfaceRootUserClient::s_log(IOSurfaceRootUserClient*, void*, IOExternalMethodArguments*)>
2021-02-01 10:53:36.137357-0500 localhost kernel[0]: kPEDisableScreen 1
2021-02-01 10:53:36.138725-0500 localhost kernel[0]: kPEEnableScreen 1
2021-02-01 10:53:36.139780-0500 localhost kernel[0]: kPEEnableScreen 1
2021-02-01 10:53:36.290131-0500 localhost kernel[0]: kPEEnableScreen 1
2021-02-01 10:53:36.333100-0500 localhost kernel[0]: kPEDisableScreen 1
2021-02-01 10:53:36.334429-0500 localhost kernel[0]: kPEEnableScreen 1
2021-02-01 10:53:36.620096-0500 localhost kernel[0]: IOConsoleUsers: time(0) 0->0, lin 0, llk 0,
2021-02-01 10:53:36.620118-0500 localhost kernel[0]: IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, now 0, sm 0x0
2021-02-01 10:53:36.621269-0500 localhost kernel[0]: (kernel) SMCBatteryManager bmgr: @ failed to find batteries or adapters!
2021-02-01 10:53:36.621285-0500 localhost kernel[0]: (kernel) SMCBatteryManager smcbus: @ BatteryManager probe failure
2021-02-01 10:53:36.621645-0500 localhost kernel[0]: (kernel) SMCBatteryManager bmgr: @ failed to find batteries or adapters!
2021-02-01 10:53:36.622182-0500 localhost kernel[0]: (kernel) SMCLightSensor alsd: @ No iterator
2021-02-01 10:53:36.735340-0500 localhost kernel[0]: (AMDFramebuffer) <AMDFramebuffer`AMDFramebuffer::scheduledTransactionHandler(OSObject*, IOInterruptEventSource*, int)> AMD IOFB CRITICAL ERROR!!!VBLANK interrupt has not been generated in time! Display transaction ID#1-0-0-5-0-113
2021-02-01 10:53:36.735358-0500 localhost kernel[0]: (AMDFramebuffer) <AMDFramebuffer`AMDFramebuffer::scheduledTransactionHandler(OSObject*, IOInterruptEventSource*, int)> AMD IOFB CRITICAL ERROR!!!VBLANK interrupt has not been generated in time! Display transaction ID#1-0-0-5-0-113
2021-02-01 10:53:36.735361-0500 localhost kernel[0]: (AMDFramebuffer) <AMDFramebuffer`AMDFramebuffer::scheduledTransactionHandler(OSObject*, IOInterruptEventSource*, int)> CRITICAL ERROR : VBLANK interrupt has not been generated in time!
2021-02-01 10:53:36.735370-0500 localhost kernel[0]: (AMDSupport) <AMDSupport`ATIController::recoverDisplay()> AMD Recovery Display. enabled:1

This might be the crux of the issue, if I'm understanding it correctly -- AMD IOFB Critical error, VBLANK interrupt has not been generated in time.

Time for more research. Thank you again for helping me learn, Ed. Let me know if you have any other thoughts.
 
There are a bunch more errors related to the graphics so I am attaching the full kernel log as well as the boot log.
 

Attachments

  • full_log.txt
    2.7 MB · Views: 212
  • boot_log.txt
    31.4 KB · Views: 57
You can remove these two sensor kexts, as they are related to laptop sensors.
  • SMCBatteryManager.kext
  • SMCLightSensor.kext
Where is your Realtek ethernet kext, /Library/Extensions?

Can you post a copy of your CLOVER folder, so I can see what else you are using to boot your system.

This is the last line in the bootlog.txt, it might also be part of the issue with the black screen:

Custom boot screen not used because entry has unset use graphics

Can you also confirm which version of Clover you are using. If it is one of the more recent, i.e. newer than Clover-r5120 then you may need to downgrade Clover to r5119 or r5120. As the newer versions were a bit of a mess, trying to incorporate OpenCore in to Clover!

A copy of Clover_r5119 is attached.
 

Attachments

  • Clover_r5119.zip
    8 MB · Views: 32
Here is a screenshot of the console log running with blank screens-
 

Attachments

  • Screen Shot 2021-02-01 at 1.15.35 PM.png
    Screen Shot 2021-02-01 at 1.15.35 PM.png
    618.2 KB · Views: 54
Ah ok -
I was experimenting with updating clover and I had been running r5119 but I just tried updating to the most recent version. I will revert back.

I have a theory that I'm exploring which is that Westmere CPUs don't have iGPU features. Whatevergreen seems to rely on it. The SMBIOS that I'm using per your recommendation is the iMacPro1,1 which from what I understand has a Skylake CPU which does have an iGPU. Since the most common fix for this problem (for users with UEFI) is to enable iGPU, I wonder if I need to somehow spoof an iGPU. This could be related to exactly what you said:
This is the last line in the bootlog.txt, it might also be part of the issue with the black screen:

Custom boot screen not used because entry has unset use graphics

I don't know if thats possible or how to go about doing that, so my research continues.

In the mean time, attached is my Clover folder. Thank you again, Ed!
 

Attachments

  • CLOVER.zip
    1.8 MB · Views: 38
No your Westmere CPU won't have an IGPU. But there is nothing in the system for WhateverGreen.kext to suppose there is, or try to work with one.

WhateverGreen.kext is useful with your RX580 dGPU. It contains a number of fixes, including ACPI rename patches, standard settings for your AMD dGPU so it works with macOS. Well that is normally the case.

You have an ACPI fix in your config.plist, which will not work with AppleALC.kext or WhateverGreen.kext - FixHDA=true

You are missing a few common ACPI fixes, and a few other common items which I have added to the config.plist attached below. I am also going to remove the debug entries, as sometimes they cause more issues than they resolve.

I have been wondering which slot is the RX580 installed in to in your system, do you know if it is called 'Slot-1'

Can you screen share and look in the IOReg, or provide a copy of your IOReg so I can see which slot it is used from. The SSDT-RX580 looks for the dGPU in Slot-1, if it is not in that Slot, or the name is different then that might be a cause for the message in the bootlog. So I have removed it from the revised Clover folder attached below.

There is nothing obvious in your config.plist that would make that call.

The kexts you are injecting are in the /CLOVER/kexts/10.15 folder. The Clover folder would probably work better if they are moved to the /CLOVER/kexts/Other folder.

Try the revised CLOVER folder on a Spare USB pen drive, to see if it helps any. It may need a bit more tweaking.

A Copy of your IOReg will help if it needs work.

As would a copy of the ACPI tables from your system, these can be obtained from the Utilities Tab in Hackintool application. The ACPI tables would be dumped on your Desktop by Hackintool app. Alternatively they can be obtained by pressing the 'F4' key while on the Clover Boot Screen, this would save the tables to your the /CLOER/ACPI/origin folder on your USB pen drive or macOS (Hackalina) drive, depending on which you were using to boot the system.
 

Attachments

  • CLOVER.zip
    2.4 MB · Views: 36
Hi Ed,
I backed up my clover folder and replaced it with the one you provided. It still goes black, but I'm feeling hopeful.
Attached is the IOReg and Hackintool's ACPI dump. Thank you thank you thank you!
 

Attachments

  • SSDT-3.dsl
    13 KB · Views: 42
  • SSDT.dsl
    9.2 KB · Views: 39
  • SSDT-1.dsl
    22.8 KB · Views: 43
  • SSDT-2.dsl
    1.1 KB · Views: 44
  • SSDT-4.dsl
    4.7 KB · Views: 46
  • DSDT.dsl
    220 KB · Views: 38
  • SSDT-1.aml
    6.3 KB · Views: 37
  • SSDT.aml
    1.1 KB · Views: 39
  • DSDT.aml
    23.7 KB · Views: 38
  • SSDT-3.aml
    1.9 KB · Views: 33
  • SSDT-2.aml
    162 bytes · Views: 39
  • SSDT-4.aml
    628 bytes · Views: 36
  • ioreg copy.txt
    79.1 KB · Views: 57
Status
Not open for further replies.
Back
Top