[SOLVED] Lenovo X1 Extreme on OpenCore unable to get to installer

[xefyr0]

Hello, yet another hackintosh newbie here who's found himself in need of help.

I was trying to make my first hackintosh on a Lenovo ThinkPad X1 Extreme Gen 3 (Serial 20TK001JUS) with OpenCore by following Dortania's guide.
I got to the installation process section of the guide and of course hit a brick wall. Booting up from my thumb drive yielded a result similar to the one found in 1.jpeg in the drive link below, so I immediately went and attempted a bunch of fixes I found in and out of the guide. None of them actually got the verbose log to continue past that point, however, and I'm not so confident that I got all of them working properly before I moved on to the next one.
Moving on, I decided to try again with a clean slate and reassembled the EFI folder from scratch and wound up with the same result I had before. This time, however, a few seconds after reaching that point the screen got scrambled as can be seen in 2.jpeg. I assumed this was the same issue as described in the troubleshooting section of the Dortania guide, but unfortunately there is no CSM or "Boot Legacy ROMs" setting in my BIOS.

 

That brings me here. From what I can tell I've encountered two separate issues, but the screen smearing has only occurred twice so far while the verbose log stopping has been more consistent throughout my attempts.

Some information not present in the drive link below:
CPU: Intel i9-10885h (Comet Lake)
Mobo: WM490 chipset
iGPU: Intel UHD Graphics (device ID 9BC4)
dGPU: NVIDIA GeForce GTX 1650 Ti with Max-Q Design (Turing Architecture)
Builtin screen resolution: 1920x1080

I'm trying to boot macOS Big Sur 11.2.3 (Most recent version at the time of writing)

UEFI BIOS version is N2VET29W (Most recent version at the time of writing)
I've been using a 2015 MacBookPro to create and modify the 32 GB boot USB

 

EFI, screen photos & and OpenCore log:
https://drive.google.com/drive/folders/1-k29SMOAdNiBwyDAHl3-RjI8jFt6bRkF?usp=sharing
Product Specification from Lenovo:

https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Extreme_Gen_3/ThinkPad_X1_Extreme_Gen_3_Spec.pdf

 

If I could receive some assistance on this I would highly appreciate it. Thanks!

Edited April 27, 2021 by xefyr0
Separate issue, moved to another post.

[1Revenger1]

You probably don't need SSDT-EC-USBX.
Lenovo Thinkpad devices (atleast the recent ones) already contain a device named "EC". You should keep the SSDT you currently have though since that has USBX included in it as well and it checks for the existance of the EC device already.
I'd check that in your BIOS, it's set to "Windows 10" mode, not "Other OS" or some other option.

The screen smearing with the prohibited symbol is it timing out trying to find your USB. I'd enable the port limit patch temporarily.
You should be able to use SSDT-Time as well with the "Reset USB" option to hopefully try to fix up the ports.

How long are you waiting? The timing out usually takes a minute or two before it appears with that prohibited screen, so that could just be the issue if you aren't waiting long enough in that other screenshot.

[xefyr0]

Thank you for the response. 

The only option in my BIOS that mentions Windows 10 specifically is the sleep optimization option, and that has been set to Windows 10 from the start.
Would the setting you're talking about have some other name?

As for the smearing, a minute or two of waiting before it happened sounds about right.

EDIT: Booting with the Reset USB .aml you suggested finally got the verbose log past that section, thank you!
I'm still stuck though, it seems. The new photo (3.jpeg) and opencore log are in the drive link on the original post.

Edited April 16, 2021 by xefyr0

[xefyr0]

I updated the EFI folder in the drive link above with the changes 1Revenger1 suggested to reflect what I'm working with, but removed serial numbers & other unit-specific info from config.plist.

From what I can tell, the current issue is something GPU-related.
My discrete GPU isn't supported so I used the -wegnoegpu boot argument, but AFAIK my iGPU should work just fine as-is?

I tried the reccomendations from the Dortania guide and a few online searches but either my BIOS didn't have the option or else it simply didn't work. Maybe I'm reading the verbose log wrong, I don't know what I should be looking for when the last message isn't guaranteed to be the issue.

[Slice]

Did you take into account that your CPU is not supported by latest Big Sur?

[1Revenger1]

Looks like it's a graphics issue since you're stuck around gIOLockState -> 3
You could try specifying the device id, and also trying some different ig-platform-ids
What is the "type" for? I'm unfamiliar with that device property.

Edit: Whatevergreen lists quite a few other ig-platform-ids as well, though I'd start with the ones specified in the guide.
https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#intel-uhd-graphics-610-655-coffee-lake-and-comet-lake-processors

Remember that you need to swap the endianness of any numbers that you get from the above link before putting them in your config.plist.
ie if it specifies 0x12345678, when swapped, it would look like 0x78563412
You're swapping the order of bytes, which are each 2 digits long in hex.

Edited April 16, 2021 by 1Revenger1

[xefyr0]

2 hours ago, 1Revenger1 said:

What is the "type" for? I'm unfamiliar with that device property.

At https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/coffee-lake-plus.html#deviceproperties "AAPL,ig-platform-id" and "Type" looked like they were supposed to be understood used in a similar fashion (i.e. in the plist) especially since Type was right next to AAPL,ig-platform-id both in the table provided and the explanation above it. The whatevergreen guide you shared uses different terms & formatting so I guess I was mistaken.

Since my dGPU is unsupported and my iGPU's device ID is 9BC4, I assume putting <C49B0000> in the data field for "device-id" is the correct thing to do since it's natively supported.
as for AAPL,ig-platform-id, <07009B3E> seemed to work. the verbose log continues on for a bit more before the screen goes completely blank.

EDIT: Got past the blank screen by adding -igfxvesa to the boot args. I assume this means I will have to configure CPU hardware acceleration later.

2 hours ago, Slice said:

Did you take into account that your CPU is not supported by latest Big Sur?

And no, I was not aware of this.
Where in the pre/post install process would this cause problems?

Edited April 16, 2021 by xefyr0
Progress update

[Slice]

14 minutes ago, xefyr0 said:

 

And no, I was not aware of this.
Where in the pre/post install process would this cause problems?

I am not famous with OpenCore and dortania guide.

I may say that with Clover you need FakeCPUID to nearest IceLake.

But I am not sure if intel Graphics will work. Anyway write native device-id as <C49B0000> has no sense. You must write here not own id but fakeid supported by macOS drivers.

[Slice]

I think FakeID for graphics can be 0x8A71.

And ig-platform-id, for example 0x8A710001

What is your CPUID? For booter log or from Windows report.

[1Revenger1]

9BC4 is one of the supported device ids actually according to the whatevergreen docs.
This is Cometlake, which should have support since 10.15.4.
 

[xefyr0]

26 minutes ago, Slice said:

I am not famous with OpenCore and dortania guide.

I may say that with Clover you need FakeCPUID to nearest IceLake.

But I am not sure if intel Graphics will work. Anyway write native device-id as <C49B0000> has no sense. You must write here not own id but fakeid supported by macOS drivers.

I see. I managed to get to macOS recovery mode with keyboard and trackpad working so I assume my CPU and GPU are working right, but I'm not an expert so correct me if I'm wrong.
 

[Slice]

6 hours ago, 1Revenger1 said:

9BC4 is one of the supported device ids actually according to the whatevergreen docs.
This is Cometlake, which should have support since 10.15.4.
 

In what kext I can see the id?

I found only

0xff058086 0x8A708086 0x8A718086 0x8A518086 0x8A5C8086 0x8A5D8086 0x8A528086 0x8A538086 0x8A5A8086 0x8A5B8086

in the ICL kexts.

[1Revenger1]

7 minutes ago, Slice said:

In what kext I can see the id?

I found only

0xff058086 0x8A708086 0x8A718086 0x8A518086 0x8A5C8086 0x8A5D8086 0x8A528086 0x8A538086 0x8A5A8086 0x8A5B8086

in the ICL kexts.

IntelGraphicsCFLGraphicsFramebuffer.kext
0x3E9B8086 0x3EA58086 0x3EA68086 0x3E928086 0x3E918086 0x3E988086 0x9BC88086 0x9BC58086 0x9BC48086

Cometlake uses the same UHD graphics as Coffelake. It's only the Icelake devices with G3/G5/G7 on the end of the CPU name which use the newer iGPUs.

[Slice]

@xefyr0

Show me please CPU-Z info from Windows.

[xefyr0]

22 hours ago, Slice said:

@xefyr0

Show me please CPU-Z info from Windows.

Sorry for the late reply, but here. 
The CPU seems to be working just fine, but I'm having issues with DRM/hardware acceleration on the GPU it seems ironically
The GPU says it only has 7 MB of VRAM in "About my Mac" and the screen smears at the end of the boot process right before the apple logo shows if I don't include the -igfxvesa boot argument.
Based on the Dortania guide there's no fix so I guess I'll have to downgrade to Sierra

[Slice]

Well, see extended model = 0xA5

And compare with Big Sur kernel

https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/i386/cpuid.h.auto.html

There are KABYLAKE, ICELAKE... there is no CometLake with model 0xA5

 

I may propose you to try to make FakeCPUID to supported model 0x8E which also can be a CometLake.

[xefyr0]

18 hours ago, Slice said:

Well, see extended model = 0xA5

And compare with Big Sur kernel

https://opensource.apple.com/source/xnu/xnu-7195.81.3/osfmk/i386/cpuid.h.auto.html

There are KABYLAKE, ICELAKE... there is no CometLake with model 0xA5

 

I may propose you to try to make FakeCPUID to supported model 0x8E which also can be a CometLake.

Looking at the link to the kernel you provided, Big Sur doesn't have support for Coffee Lake CPUs either. Apple has released a handful of computers with Coffee Lake CPUs (And even a Comet Lake CPU with the iMac20,1) so there's no reason these relatively recent releases would not be able to run the most recent macOS.  Additionally the copyright is 2000-2019 so I think that the file itself is outdated, and not actually the kernel source for Big Sur.

Moreover, thanks to the help from earlier I'm able to boot up Big Sur on my "unsupported" CPU as shown in the screenshot below.
As the 7 MB of VRAM indicates, I'm having issues with my GPU and not my CPU.

Edited April 19, 2021 by xefyr0
clarity

[Slice]

CoffeeLake is 0x9E which is supported under name of 

#define CPUID_MODEL_KABYLAKE_DT         0x9E

There is also one revision of CometLake with ExtModel = 0x8E which is supported too

#define CPUID_MODEL_KABYLAKE_ULX        0x8E

Somehow you can start but not fully functional.

[1Revenger1]

5 hours ago, xefyr0 said:

Looking at the link to the kernel you provided, Big Sur doesn't have support for Coffee Lake CPUs either. Apple has released a handful of computers with Coffee Lake CPUs (And even a Comet Lake CPU with the iMac20,1) so there's no reason these relatively recent releases would not be able to run the most recent macOS.  Additionally the copyright is 2000-2019 so I think that the file itself is outdated, and not actually the kernel source for Big Sur.

Moreover, thanks to the help from earlier I'm able to boot up Big Sur on my "unsupported" CPU as shown in the screenshot below.
As the 7 MB of VRAM indicates, I'm having issues with my GPU and not my CPU.

Why a mac mini SMBIOS for a laptop? Should be able to use one of the MacbookPro SMBIOSes.
I'd look here and see if some of the things here could be the issue/could help solve it. I specifically linked `-igfxlmr` since I've seen that cause just a black screen as well.
https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#fix-the-invalid-maximum-link-rate-issue-on-some-laptops-dell-xps-15-9570-etc

[xefyr0]

17 hours ago, 1Revenger1 said:

Why a mac mini SMBIOS for a laptop? Should be able to use one of the MacbookPro SMBIOSes.

I've been trying 3 different SMBIOSes and switching between them doesn't seem to fix any issues I'm finding, but I'll stick with MacBookPro16,3 for the long term probably. The reason I was using the Macmini was because it matched the CPU and GPU better, plus my laptop is mobile hardware anyways AFAIK

17 hours ago, 1Revenger1 said:

I'd look here and see if some of the things here could be the issue/could help solve it. I specifically linked `-igfxlmr` since I've seen that cause just a black screen as well.
https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#fix-the-invalid-maximum-link-rate-issue-on-some-laptops-dell-xps-15-9570-etc

This didn't solve the issue, it's a lot more deep than I thought. -igfxblr igfxonln=1 igfxfw=2 and agdpmod=pikera don't work either.
-igfxvesa is required to boot, since without it every framebuffer either forces a reboot, smears or goes blackscreen.
I've been using 3E9B0007 as my framebuffer because it's the only one that results in a black screen when I don't use -igfxvesa, plus the GPU shows up correctly on Hackintool with it.

I've tried busID patching with MacBookPro16,3 SMBIOS and 0x3E9B0007 framebuffer and 0x00000002 bus type for my internal display but none of the 18 busID/Index combinations work. All black screen.
I've also tried BusType patching, first by switching all of the bus types to 0x00000002 (eDP which should work with my internal display based on the motherboard spec) and then by switching all of the bus types to 0x00000800 (HDMI) and hooking up a smartTV to see if I could get any output that way.

The worst part is that, because I need to use -igfxvesa to see, when I use IORegistryExplorer to look at the framebuffers under the IGPU, there aren't any. The connectors in hackintool don't turn red either.

 

Lilu, VirtualSMC and Whatevergreen are all injected in that order and functional.

I updated the drive folder with my current EFI and a few other things:
4.png is a screenshot I took using a boot with the -igfxvesa argument, but since the screen was dark I did it blindly. There's no display listed in the "About my Mac" window, which may be important. You can still see the transparent dock though, which AFAIK means GPU acceleration was working despite the display being black.

5.png is a screenshot of Hackintool and IORegistryExplorer from a boot with -igfxvesa that shows the issues I'm describing.

6.png is a screenshot of Hackintool displaying my IGPU as a peripheral, and with a framebuffer of 0xFFFFFFFF for some reason on an      -igfxvesa boot. I don't know why this is the case but I assume it may be important.
withvesa and novesa are photos of where the IGPU initialization was in the verbose log and their corresponding opencore logs.
As you might guess withvesa is for a boot with -igfxvesa boot argument and novesa is without.

Edited April 20, 2021 by xefyr0
Better 4.png

[xefyr0]

12 hours ago, Slice said:

CoffeeLake is 0x9E which is supported under name of 

#define CPUID_MODEL_KABYLAKE_DT         0x9E

There is also one revision of CometLake with ExtModel = 0x8E which is supported too

#define CPUID_MODEL_KABYLAKE_ULX        0x8E

Somehow you can start but not fully functional.

I see, I was mistaken.

I don't fully understand how I'm able to boot myself, let alone the fact that Opencore doesn't seem to have CPUID spoofing as an option but maybe SMBIOS injection is what does it? I've only been injecting SMBIOSes with Coffee Lake CPUs except for that one Comet Lake iMac20,1 SMBIOS which probably matches with the 0x8E CPU extension.

[xefyr0]

On 4/18/2021 at 11:24 PM, Slice said:

I may propose you to try to make FakeCPUID to supported model 0x8E which also can be a CometLake.

 

On 4/20/2021 at 12:04 PM, xefyr0 said:

I don't fully understand how I'm able to boot myself, let alone the fact that Opencore doesn't seem to have CPUID spoofing as an option but maybe SMBIOS injection is what does it? I've only been injecting SMBIOSes with Coffee Lake CPUs except for that one Comet Lake iMac20,1 SMBIOS which probably matches with the 0x8E CPU extension.

Actually, I found it.
Opencore allows CPUID spoofing in a small section under config.plist -> Kernel -> Emulate, so Big Sur should now think that my EAX is 0x000806E2 (Extended model 0x8E)
Unfortunately, it doesn't help at all with the problem I'm still experiencing (GPU acceleration making my screen black after verbose, forcing me to use -igfxvesa in order to boot with graphics)

[Slice]

I will propose you to install 11.4 beta

[xefyr0]

18 hours ago, Slice said:

I will propose you to install 11.4 beta

I'm trying to, but installing it seems to require a Developer account, which has a fee of $99/yr? My efforts got me the 11.3 public beta instead and it seems that the 11.4 beta won't be available to the public until June, although I may be mistaken.

EDIT 2: I think I figured it out, input and all, but graphic acceleration still seems to be not working. Maybe I might have to downgrade to Catalina instead?

 

That begs the question then, when changing versions of macOS are there any NVRAM considerations I should be aware of? Casually resetting NVRAM has been known to brick Lenovo X1s in the past and that's simply a risk I'm not willing to take so I'm wondering if any data stored there may cause issues, and if so how to fix that.

Edited April 23, 2021 by xefyr0
Status update 2

[vltra]

used this github as reference for trial error https://github.com/aidanchandra/x1c7-hackintosh