Hervé

Not really because neither the APU nor the nVidia dGPU of your Ideapad has support under macOS. Sorry. You could probably install macOS but it would run like crap and be very buggy without graphics acceleration so you'd probably quickly hate it. Best place for AMD Hackintosh: https://amd-osx.com

You've tested things in preparation of Ventura, great even if a little odd doing this with Monterey rather than with a Ventura beta build. But, as I said, why not? The boot arg -igfxsklaskbl won't be necessary in Ventura. However, this is obviously not the proper way to run Monterey at all on a fully supported Skylake platform. Changing thread title to reflect true situation and closing this topic.

I'm not sure I understand. You want to use Catalina icons for Big Sur instead of Big Sur icons? If so, just make copies of the Catalina icon files and rename them to Big Sur's icons filenames. As simple as that. Of course, make sure to have installed latest OC GUI files (i.e. Resource folder) beforehand.

Were you booting Monterey or Ventura beta (and which beta)? I've no graphics boot arg other than igfxonln=1 in my E7270 setup (to ensure that LCD screen remains activated when HDMI is plugged in but that's platform specific, not Ventura specific). I'm using Lilu v1.6.2 and Whatevergreen v1.6.1 since Ventura beta 3. I've no error message in the boot log about iGPU firmware failing: There's probably something wrong in your config/setup so post a zipped copy of your EFI folder if you want further assistance. Ideally your boot log too.

Those values you inject for fbmem (5MB !), stolenmem (8MB !), portcount (4 !) or device-id look rather odd and incorrect to me. I invite you to consult the existing threads posted this Ventura beta section where you'll find copies of the Clover packs I posted for my Skylake/HD520 Dell Latitude E7270. You may want to revisit the iGPU faked id you went for, knowing that: 8086:591e -> HD 615 8086:5916 -> HD 620 8086:591b -> HD 630 On top of the correct iGPU properties injection, you also need to ensure you use: the correct SMBIOS (MBP14,1) the correct version of Lilu + Whatevergreen (WEG v1.6.0 minimum) kexts Check your system's default DVMT settings; if DVMT is set to 32MB, try and patch that at BIOS level to 64MB or 96MB. If you can't, adjust fbmem and stolenmem so that the sum of the two parameters totals a little less than 32MB. KBL framebuffer 0x59160000 defines the following graphics settings: ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI 00000800 02000000 98000000 01050900 00040000 87010000 -> 0105 connector good for HDMI. Type 00080000 for HDMI audio. 02040A00 00080000 87010000 -> Ok for DP, incl. audio. If patching were required due to DVMT=32MB, all you'd have to inject is this: framebuffer-stolenmem DATA 0000F001 // i.e. 31MB or a lower value like 19+MB but certainly not down to 8MB only! When default DVMT value is 32MB and cannot be increased in BIOS, the regular convention adopted for years and inherited from Haswell's original mobile framebuffers is to set: stolenmem to 19MB (i.e. 0x01300000) fbmem to 9MB (0x00900000) No need to patch fbmem or stolenmem if DVMT=64MB or higher. KBL framebuffer 0x591B0000 has closer fbmem + stolenmem settings to SKL framebuffer 0x19160000 used for HD 520 graphics but it requires con1 patching for HDMI: ID: 591B0000, STOLEN: 38 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000130B TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 136 MB, MAX OVERALL: 137 MB (144191488 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 02040A00 00080000 87010000 -> Not good for HDMI output. Needs patching to 01050900 [00080000 87010000]. 03060A00 00040000 87010000 -> Ok for DP, incl audio. All explanations readily available in original Ventura beta 1 thread. I would suggest you modify your properties injection like this: AAPL,ig-platform-id 00001659 DATA device-id 16590000 DATA framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA or like this: AAPL,ig-platform-id 00001B59 DATA device-id 1B590000 DATA framebuffer-con1-enable 1 NUMBER framebuffer-con1-alldata 010509000008000087010000 DATA adding the fbmem + stolenmem patches only if required. Of course, all this applies to Ventura only; I don't know if such KBL-spoofing settings work under Monterey, I've never even considered trying but why not? You should revert to previous and normal settings for Monterey and experiment with Ventura beta booted off a USB key instead.

WWAN modules are really seldomly used these days given that it's become so easy and common to just share one's mobile phone data connection. If you consult our R&D->WWAN section, you'll find there's not been much written for yonks and more stories of failures than success in recent years. As such, I'm afraid you won't obtain much response to your query. It's an old post but you may want to look at this model. You'd have to adjust the patches for Monterey of course. If you google the Net a wee bit, you'll also find reports of apparent success with DW5809e and EM7305/EM7355 WWAN modules under Monterey.

Incorrect or missing settings in all likelihood...

Well, if you don't have graphics acceleration, all you have to do is follow the instructions provided in my E6220 Mojave guide.

You need a very specific and very different config for Ventura which does not natively support Skylake platforms. See our previous threads about Ventura beta.

There are guides for the E6x20 models in our Guides section. I'm sure you can refer to those for guidance.

I don't believe your remaining issue is graphics related but if you believe so, you may try and boot in VESA mode and see if you reach macOS desktop, albeit without graphics acceleration of course.

You were told about HDMI-to-VGA adapter last week. The same principles will apply to any VGA adapters, whether DP or DVI: they need to be active to convert digital signal to analog. Passive adapters just won't do.

You need to better follow the Dortania guidance for Coffee Lake desktops which you appear to have diverted from. For instance: in the ACPI section, you're not using the recommended SSDT-EC-USBX but a SSDT-USBX table without any specific code for EC. in the Kernel section, I see that, instead of AppleXcpmCfgLock, you've enabled the AppleCpuPmCfgLock quirk, something meant for CPU power Management on Sandy Bridge & Ivy Bridge only; it's totally inapplicable to your Coffee Lake platform though it'll do no harm of course. But you may need the other quirk to avoid a kernel panic... in the Misc->Entries section, I noticed a "CustomOS" entry. There are probably several other things to double check.

I understand that Ventura may now be installed and run with possible graphics acceleration on Haswell platforms with HD4200/HD4400/HD4600/... with the patches available in latest pre-release/alpha version of OCLP. Look it up.

Released Sept. 9th, 2022. Build 22A5242f. Ok on my Skylake/HD520 Latitude E7270 with exact same/unmodified Clover r5148 setup previously used for 13.0 beta 3 to 6. Everything working as before.

@donjave You made a significant mistake in your revised config when attempting to inject iGPU properties under iGPU device at PciRoot(0x0/Pci(0x2,0x0): You replaced: AAPL,ig-platform-id by: AAPL,slot-name Oups! Former (expressed as an hexadecimal, i.e. DATA value) refers to the desired target graphics framebuffer and is essential -not to say mandatory- in most cases, latter (expressed as a text, i.e. STRING value) is more of a cosmetic parameter to specify the PCIe slot and is entirely optional. You need to fix this little mistake. You should be Ok with an HDMI to VGA adapter as long as it's an active one; HDMI being digital and VGA analog, you require signal conversion. But I guess it's Ok if you're already obtaining your verbose output on screen.

Make sure you perform a Reset NVRAM operation from the OC Picker after you modify your OC config; it's necessary to take the changes into account.

Hi, being stuck at the stage you mentioned usually means that graphics are not initialising. Not surprising given that you do not inject any properties against your iGPU, something that's required: This because you simply placed the iGPU properties injection at the wrong place in your OpenCore config file: Once you correct this by properly placing your properties under the iGPU device, i.e. under PciRoot(0x0)/Pci(0x2,0x0) just like the layout-id injection under HDEF (audio) device at PciRoot(0x0)/Pci(0x1b,0x0), your system should be able to initialise graphics and complete its boot process. NB: 1st screenshot shows your config opened in OCC (OpenCore Configurator) app, 2nd one shows your config opened in ProperTree app.

Released Aug 25th, 2022. Build 22A5331f. Ok on my Skylake/HD520 Latitude E7270 with exact same/unmodified Clover r5148 setup previously used for 13.0 beta 3, 4 & 5. Everything working as before.

MBP15,1 or MBP16,1 probably makes no difference, as long as it registers properly with the SMBIOS fix.

It's Coffee Lake Refresh (not Plus) but it should make not difference since the CFL framebuffer remains 0x3EA50009 for UHD 630, granted that the Dortania guidance advocates MBP16,x. Remember that mid-2019 15" MacBookPro15,1 were actually 9th gen Coffee Lake Refresh (same for mid-2019 15" MacBookPro15,3), including this one fitted with 6-core i7-9750H. MacBookPro16,1/3/4 models are late-2019 16" Coffee Lake Refresh models. You still need to fix your SMBIOS corruption... Have you done this?

IOReg extract shows corrupt SMBIOS model "MacBookPro16,", something typical on some Dell laptops that requires a fix/patch. This can affect video output of course. You still use to MBP16,x SMBIOS when all documentation state you should be using MBP15,x SMBIOS. Any reason you refuse to use MBP15,x?

No option in BIOS that would disable the HDMI port?

Did you consult the Dortania Anti-Hackintosh buyers guide as suggested above?

No need to update OC to v0.8.3 to update Monterey to 12.5.1 afaik. Your current version should do just fine. This being said, one best learns by his mistakes and doing the work for you is not only lazy but discouraged. If you really want to update Opencore, make sure you make backup of your EFI partition/folder on a USB key and test that key to boot Monterey before proceeding with updating OC. Or vice-versa. You're already aware of the various threads at Insanelymac, that will be your base lines.