Enthusiast laptop: Getting UHD 620 working under Monterey (or Big Sur)?

[flyingfishfinger]

Well, I guess this brings me to a question I've always sort of wondered about. Everything I've ever read about Hackintoshes always seems very "trial and error". I get that maybe for absolute beginners that could be a good approach when stuff doesn't work, but shouldn't there be ways of debugging or deriving the correct solutions a bit more analytically? Or do we really not know how Apple's black box works?

 

For example, if there's a hang during boot because of graphics could we not use the debugging output of WEG / Lilu etc to figure out what it's not happy about? I've seen bits of that in the logs - like figuring out what Link Rates are available and whether those need to be adjusted. Or what WEG thinks of the *actual* framebuffer / device ID. Or, how to check what the actual allocated DVMT is. In-depth technical information about stuff like this is few and far between, and I sometimes wonder why...

 

Any ideas?

R

[Hervé]

Running macOS on standard PCs was never meant to be. And many may indeed consider that Apple operate a "blackbox"; it certainly is opaque in many aspects. Your trouble here is that you're using hardware from a tiny outfit and you cannot expect this to be as reliable and well built as mainstream manufacturer's equipment.

[Syonagar]

Flyingfishfinger,

 

What kind of payload u have on that coreboot? Is it an EFI bootloader?

[flyingfishfinger]

@Baio77 Monterey boot hangs at IGPU if I use 0000C087 as a platform-ID, then KP's after a while. Like I said, so far I can ONLY boot with an invalid one, otherwise it always either hangs in this place or gets a KP. I've attached the ACPI from SysReport, and a screenshot of the KP. It starts with "10 error-reporting cores"

 

 

@Syonagar the payload is Tianocore, specifically MrChromebox's build of coreboot + Tianocore: https://github.com/MrChromebox/coreboot. It works very well generally and is sometimes recommended over Coreboot master. It's based on the latest actual Coreboot release.

 

Thanks,

R

Sysreport.zip

[flyingfishfinger]

I've seen that before. Sadly it's not very helpful, since (1) it's for Clover, which I don't want (2) some of the kexts are no longer applicable (OC guide specifically recommends against them) (3) it just boot loops on my system with Coreboot and (4) the forum thread that refers to this on Thinkpads only goes as far as Big Sur.

 

However, I did find this instead: https://github.com/jamesfawcett/Thinkpad-X2100-51nb-OpenCore-Hackintosh

 

The X2100 is an updated version of the machine with a 10th Gen CPU, but on a whim I tried this as-is. Interestingly, it fakes an Iris 635 instead of the actual UDH 620. I don't know why they do this.... any ideas? The result - if I use the stock BIOS, I actually get acceleration! But on Coreboot, I get the following KP... "airportd" ??

 

R

[Bronxteck]

it still looks to have issues with DVMT. maybe MrChromebox can help you.

[flyingfishfinger]

Hmm, are we sure about that?

 

In the BIOS case, I tried it with both 64MB and 32MB DVMT-prealloc, and it boots fine, with acceleration and no changes to the EFI.

 

I've checked and adjusted the Coreboot code which sets this value (it's called IgdDvmt50PreAlloc), as well as confirmed the register value (GGC, out of here: https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol02c-commandreference-registers-part1.pdf) that should be affected by twiddling the value; it does indeed change. Any value I set results in the above KP (32MB, 64MB, 96MB, 128MB)... so I'm not sure this is the right thing.

 

Further: Reading out the register when both are set to 64MB results in the exact same return value if done with BIOS vs Coreboot, but one boots and the other doesn't. That tells me it's gotta be something other than DVMT issues...

 

Further #2: After going over the OC guide and setting the Booter quirks for MAT & SetupVirtualMap I'm back to the very original hang that started all this (stuck at [IGPU]), even with the new EFI from the link in my previous post.

 

R

 

 

[Bronxteck]

if you can change the value then try 256mb. some have reported that they sometimes have to load an older version of coreboot then move back to the latest. seemed to fix the no graphics loading issues for them.

[flyingfishfinger]

How do you mean "move back to the latest" ? You mean get it to boot once on an older version then update, or something else? I'm not sure I understand how that would help - even if it does boot on older versions wouldn't it just break again after updating?

 

I'll give the 256MB setting a shot, thanks,

 

R

[olm3ca]

I'll be interested in seeing if 256mb helps, or an older version of Coreboot. As Flyingfishfinger mentioned, it's an issue that has plagued Coreboot users like us Chromebook / chrultrabook folks. @Hervé and others here have tried to help with this in the past for the Galaxy Chromebook, 10th Gen Comet Lake also with the UHD 620. It would be so great to figure out what is broken between Coreboot and Catalina / Big Sur / Monterey. On the Galaxy Chromebook, Comet Lake + UHD 620 should be supported, but we are stuck at 31mb vram no matter what values are used.