Jump to content
15 posts in this topic

Recommended Posts

Hey guys,

 

After “talking” to ChatGPT about this and feeling I’m probably losing time more than saving, I decided to open this thread and ask the human intelligence if there is a way to fix this issue. 
 

So, yeah, there is an easy fix and probably a less than easy fix. The easy fix is just adding agdpmod=pikera (doesn’t work with vit9696) to boot args. But that also creates some glitches before loading desktop. Probably because of the resolution (using a 4K monitor), I don’t know. 
Anyway, what I’m trying to achieve is the ability to boot into recovery and not get into black screen (no signal) and remove agdpmod=pikera to fix the glitches when loading desktop. 
 

Is there a way to do that?

 

Smbios is iMac20,1 but I also tried 19,1 with the exact same effect. Meaning it doesn't work.

In case it makes a difference, iGPU is in headless mode and monitor is connected to the RX 580 via DP.
 

What would there be your recommendations?

Edited by arsradu
29 minutes ago, XanthraX said:

I think (not tested yet), to boot in recovery mode, you need to have the monitor connected to the igpu (not to the RX) and to and make the appropriate settings in the BIOS. 

yeah... but...then I'd have to constantly switch between one and the other. It's not quite ideal. :)) 

The IGPU is functional. It's already been configured and tested as the primary output. So I know that works. But...I'd like to have the RX do the job, if possible and keep the UHD 630 in headless mode, doing the compute tasks.

As far as I know, real Macs boot in recovery mode with the igpu. I don't know how it is in Mac Pros. I don't think it is other solution for us. Unfortunately. That's why I avoided to boot in recovery mode. If someone can make a solution to boot in recovery mode from the RX, it would be a real achievement.

  • Like 1
Posted (edited)
3 hours ago, XanthraX said:

As far as I know, real Macs boot in recovery mode with the igpu. I don't know how it is in Mac Pros. I don't think it is other solution for us. Unfortunately. That's why I avoided to boot in recovery mode. If someone can make a solution to boot in recovery mode from the RX, it would be a real achievement.

I mean, there is a way... Using the agdpmod=pikera boot arg. :)) Other than that...I don't know. 

 

Also, I used to think so too (that real Macs use the iGPU for low level stuff)... However, Google seems to have a different opinion. Now, of course, just like ChatGPT, it also lied to me before. So...not sure if I should trust it or not. After all, that's why I decided to open up this topic in the first place. :))

 

image.thumb.png.082bbe2767b1cdc463b92c5257ff1fff.png

 

Edited by arsradu

As I said before, I would be happy if someone will resolve this problem. Even on my MacBook Pro 2015, with OCLP, when I boot into recovery mode, it uses the iGPU instead of dGPU. Even with agdpmod=pikera, I get a black screen. But I have intel i7 8700 CPU Coffee Lake, so my OpenCore is made for this CPU, I only changed the SMBIOS from iMac 19,1 to iMac 20,1 to be available for Tahoe. Anyway, good luck if only need to use this boot arg. If I want to boot into recovery mode I should switch the monitor to the igpu slot and to change in BIOS the initial display output from PCIe Slot to IGPU. And I better avoid to do this.

 

Edited by XanthraX
Posted (edited)
3 hours ago, XanthraX said:

As I said before, I would be happy if someone will resolve this problem. Even on my MacBook Pro 2015, with OCLP, when I boot into recovery mode, it uses the iGPU instead of dGPU. Even with agdpmod=pikera, I get a black screen. But I have intel i7 8700 CPU Coffee Lake, so my OpenCore is made for this CPU, I only changed the SMBIOS from iMac 19,1 to iMac 20,1 to be available for Tahoe. Anyway, good luck if only need to use this boot arg. If I want to boot into recovery mode I should switch the monitor to the igpu slot and to change in BIOS the initial display output from PCIe Slot to IGPU. And I better avoid to do this.

 

Yeah, me too... That sounds like a nightmare. :))

Also, I might be wrong, but I think you would need to do that for the incremental updates as well... Cause otherwise you would just stare at your monitor, with nothing on it, waiting for the computer to finish installing and going back to the system, and hope...that nothing broke during the update. :)) Yeah, definitely not fun.

 

In the meantime...there's a workaround. Probably not the best. I mean, that's why they call it a workaround, not a fix, but...it works. The workaround is to choose an SMBIOS that doesn't have AGDP or has a somewhat more relaxed policy. Such as one of the Mac Pros. They're not meant to have either built-in graphics, or built-in displays. So, for that case, you won't have any issues booting into recovery (tested just now). But yeah...it's not ideal, cause Mac Pros are usually Xeon CPUs, and they have their own set of issues and incompatibilities.

Edited by arsradu

I do not prefer incremental updates. Because the full updates replace the essential system files even if they are not updated. And this almost replaces all system files, even if some got corrupted. The incremental update replaces only the updated system files. Using whatevergreen 1.7.1d7, I can boot the recovery mode with agpmod=pikera as well. Now I understand what you want. I confused recovery mode with safe mode. So ignore what I said before, I was thinking of safe mode. So I use the same opencore settings to the recovery partition / installer as for the whole system. 

WhateverGreen.kext-1.7.1d7.zip

Edited by XanthraX
Posted (edited)
1 hour ago, XanthraX said:

I do not prefer incremental updates. Because the full updates replace the essential system files even if they are not updated. And this almost replaces all system files, even if some got corrupted. The incremental update replaces only the updated system files. Using whatevergreen 1.7.1d7, I can boot the recovery mode with agpmod=pikera as well. Now I understand what you want. I confused recovery mode with safe mode. So ignore what I said before, I was thinking of safe mode. So I use the same opencore settings to the recovery partition / installer as for the whole system. 

WhateverGreen.kext-1.7.1d7.zip 275.74 kB · 0 downloads

If you upgraded Lilu to 1.7.2 (if I'm not mistaken), you should be able to use the original WEG 1.7.0 (so no need for 1.7.1d7) and you should not have any issues with incremental updates being stuck (as far as I know, this is what 1.7.1d7 was aiming to fix). However....as far as I know...you will still have issues with AGDP booting you to black screen, if you don't add agdpmod=pikera and using SMBIOS iMac20,1.

So yeah, what I'm trying to achieve is to keep the iMac20,1 SMBIOS, remove agdpmod=pikera (I don't need it for booting to the system, only for the recovery) and still be able to boot into recovery (without going the iGPU way). I'm not sure why it doesn't work for recovery specifically. But yeah...that's kind of what I'm trying to solve.

 

So far, the two workarounds seem to be: agdpmod=pikera boot arg, ooor...Mac Pro SMBIOS.

Edited by arsradu
Posted (edited)
1 hour ago, LockDown said:

Hi @arsradu im not trying to solve your issue.. Just curious if your UHD 630 has other patches aside from frambuffer to do compute task?

Well, as far as I know, you don't need framebuffer patches for compute tasks. Only to output video.

 

This is what I'm using for compute:
AAPL,ig-platform-id: 0300913E | Type: data.

Edited by arsradu
  • Like 1
Posted (edited)
10 minutes ago, LockDown said:

That is what i meant. Not sure why i wrote framebuffer 😆

Thanks 👍

You're most welcome.


By the way, I just realised I missed a "-" in "AAPL,ig-platform-id". Added now. But pretty sure you already knew what I meant anyway. :D 

Edited by arsradu
  • Like 1
Posted (edited)

Well, looks like I might have found another workaround here: in case you're on DP like me, try the HDMI port for once.

In my case, it fixed two things: booting into recovery no longer requires agdpmod=pikera and now I also have a very nice second-stage boot logo and loading bar, whereas earlier it was just a black screen.

So....I think the issue here might be just telling MacOS which port to use by default. I'll look more into it, since I think there might be a way to do that from Display Properties (with @x,APPL,boot-display property). So I'll test this theory a bit more.

But for now, if you don't necessarily need DP, apparently switching to HDMI (I selected the closest port to the motherboard) might be a valid workaround.

 

Solution:

 

Ok. So looks like this was actually easier than I expected.

 

For DP, all you have to do is switch your monitor from (probably default) DP 1.4 to DP 1.2. That's all.

 

I guess, depending on the monitor model, this might be in a different section of the menu. For my LG 27UD59P-B, the option is on the OSD Menu > General > DisplayPort1.2 > Enable.

 

Not sure why it doesn't work with 1.4, not sure if the limiting factor is the cable itself, the graphics card, or the OS. But...this simple switch fixed the boot to black screen in recovery and in the OS, and also, provided a really nice second-stage boot logo and loading bar. Absolutely perfect!

 

So yes, you can boot to recovery without using agdpmod=pikera, and without switching to a Mac Pro SMBIOS.

You can either use HDMI, or change DP from 1.4 which is probably default on the monitor, to 1.2.

Edited by arsradu
  • Like 1
×
×
  • Create New...