Hervé

See here: https://osxlatitude.com/forums/topic/11138-inventory-of-supportedunsupported-wireless-cards-2-sierra-monterey Replace that card by a Broadcom model supported in Monterey. If you have enough space, do consider an Apple BCM94360CD in a mini-PCIe adapter; works great and OOB of course but needs 4 antenna wires.

If you would tell us what kind/model of wireless card you use, we may possibly be able to help...

Ho, it's a basic OC setup issue then if the boot loader does not even kick in... Sorry, I misread and thought you were booting to black screen. My apologies.

It's not surprising that you obtain black screen with the iGPU properties you inject: It's all rather incorrect... You chose to opt for Capri layout 0x01660004, i.e. that required for HiRes screen equal or > 1600x900 which, according to your signature, is correct. Why you fake weird and invalid device id 0x02000166 for your iGPU is, on the other hand, a mystery. It's completely wrong and there's no need to fake any id at all (especially one that does not exists), the HD4000 iGPU of your i3-3110M CPU is natively supported just as it is. Of course and as explained in our HD4000 patching guide here, HiRes Capri layout 0x01660004 is a single output port (LVDS) layout by default that has to be patched for additional output ports such as HDMI, DVI or DP for instance. Typically, this is done by injecting the same characteristics as those of 4-port LoRes layout 0x01660003, changing con1 to HDMI type along the way; but you're not doing that either. There is no need to patch the stolenmem framebuffer variable for Capri framebuffers (and it's utterly useless to inject the same value as natively defined in the framebuffer), it's the fbmem which must be adjusted (reduced from 16 to 8MB) to avoid garbled screen (at least on LoRes Capri FB). I also noticed that the IOReg you previously posted showed no detected built-in screen on 1st output port (con0) but an external screen instead. That would result from a combination of incorrect iGPU properties injection + incorrect PNLF data injection; not surprising given you used a patched DSDT of some sort (I did wonder what patches it brought beyond the USB ones) with retained references to GFX0 when, alongside, you injected a SSDT-PNLF against device IGPU (declared as an external object) and renamed GFX0 to IGPU in your previous Clover and OC configs. Such settings would of course fail to properly inject a PNLF device against your iGPU. Jake's proposed config should remedy this. As a reminder, here are how LoRes and HiRes Capri framebuffers 0x01660003 and 0x01660004 are natively defined in the Capri kext (Cf. the WEG user manual ID: 01660003, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000 TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB, MAX STOLEN: 32 MB, MAX OVERALL: 33 MB (34619392 bytes) Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz Mobile: 1, PipeCount: 2, PortCount: 4, FBMemoryCount: 2 [5] busId: 0x03, pipe: 0, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [2] busId: 0x05, pipe: 0, type: 0x00000400, flags: 0x00000407 - ConnectorDP [3] busId: 0x04, pipe: 0, type: 0x00000400, flags: 0x00000081 - ConnectorDP [4] busId: 0x06, pipe: 0, type: 0x00000400, flags: 0x00000081 - ConnectorDP 05030000 02000000 30000000 02050000 00040000 07040000 03040000 00040000 81000000 04060000 00040000 81000000 ID: 01660004, STOLEN: 32 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000 TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 16 MB, MAX OVERALL: 17 MB (18354176 bytes) Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz Mobile: 1, PipeCount: 3, PortCount: 1, FBMemoryCount: 1 [5] busId: 0x03, pipe: 0, type: 0x00000002, flags: 0x00000230 - ConnectorLVDS 05030000 02000000 30020000 I suggest you replace your current and incorrect set of iGPU properties by the following set: AAPL,ig-platform-id 04006601 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA framebuffer-portcount 4 NUMBER framebuffer-memcount 2 NUMBER framebuffer-pipecount 2 NUMBER framebuffer-con1-enable 1 NUMBER framebuffer-con1-alldata 020500000008000007040000030400000004000081000000040600000004000081000000 DATA These respectively: select HiRes Capri framebuffer 0x0166004 enable framebuffer patching patches framebuffer fbmem from 16MB to 8MB patches framebuffer port count from 1 to 4 patches framebuffer memory count from 1 to 2 patches framebuffer pipe count from 3 to 2 leaves 1st output port con0 unchanged as LVDS output (i.e. 05030000 02000000 30020000) enables connector patching for con1 (and subsequent connectors) patches/injects, in one go: 2nd output port con1 as HDMI (02050000 00080000 07040000) 3rd output port con2 as DP (03040000 00040000 81000000) 4th output port con3 as DP (04060000 00040000 81000000) Should you wish to return SMBIOS to Ivy Bridge MBP9.2/10.2, you'll need to add boot arg -no_compat_check.

Just set Misc->Boot->ConsoleAttributes to 0 (zero) and you should be back to a default OC Picker menu.

If the E5420 is like the E6x20, it won't boot from USB in UEFI BIOS mode; but it will boot from internal disk. Of course, you'd have to install Clover for UEFI mode on the internal disk. Use an older version like r5133 rather than latest r514x. Catalina is not the best version to install on Sandy Bridge/HD3000 as a newbie because such platforms were last officially supported in High Sierra. You'll have to use dosdude1's patcher to be able to obtain graphics acceleration. See here: https://osxlatitude.com/forums/topic/7914-dell-latitude-e6220-with-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemiteel-capitansierrahigh-sierramojavecatalina/?do=findComment&comment=109088

We also have download links for Big Sur installation package in Our Picks forum front page section. Or you may opt for a Haswell MBP11,x SMBIOS given that those were dropped in Monterey. Software Update should only offer you Big Sur with such an SMBIOS.

Big Sur still supports HD4000 graphics OOB and is the last version to do so natively; however, it did drop support for Ivy Bridge MBP9,x/10,x so you'll have to use the SMBIOS of, say, a Haswell MBP11,x or Broadwell MBP12,x model for installation; you'll only be able to boot Big Sur with an MBP9,x/10,x SMBIOS with the -no_compat_check boot arg but you'll receive no macOs update due to unsupported SMBIOS/Mac model. With Clover, I recommend you update to version r5133 or higher. You'll then have to boot the Preboot partition. Do post your system's specs, ideally in signature.

I don't understand why Windows was deemed necessary either. And if it's the USB that's suspicious, it's wrong to say that things do not work after applying the BIOS mode. Anyway...

Reset BIOS to default settings to undo the variables mod, then re-apply the regular/expected BIOS settings (UEFI, AHCI disk mode, etc.). You should have checked the variables before changing their values in case those for your SFF model differ from Jakes's MT model.

If you want proper Wifi + Bluetooth, you should replace your Intel card by a supported Broadcom model. With regards to ITLWM, there's nothing else and it remains a project in development.

There's some cleanup to do in order to get rid of the obsolete/deprectated/conflicting stuff. Right now, it's as if everything was thrown at the Hack in the hope that things will work but that's the best recipe for trouble. For instance: you should not be injecting all those Bluetooth RAM patching kexts but only the appropriate ones. Read-up the GitHub repo to that effect. FakePCIIDxxxx kexts are deprecated and no longer useful, you can get rid of them. I don't think you can use VoodooPS2 kexts and SmartTouchpad kexts Lookup the 7510 guide posted by Jake Lo in our Guides section. Same applies to your config settings, especially the properties injected for the iGPU which are ridiculous: There's absolutely no need for such a large set of properties! One must wonder why you opted for 4-port framebuffer layout 0x191B0005 rather than the usual 3-port layout 0x19160000? In addition, most properties you inject are basically the exact same things that are natively contained in the layout! ID: 193B0005, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0023130A TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 137 MB, MAX OVERALL: 138 MB (145244160 bytes) Model name: Intel Iris Pro Graphics 580 Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 4, FBMemoryCount: 4 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000001C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7010000 02040A00 00040000 C7010000 03060A00 00040000 C7010000 As such, your injections for connectors con0, con1, con2, con3 , pipecount, portcount, memorycount, stolenmem, fbmem, mobile, flags, camellia, etc. are therefore utterly useless though harmless. Same goes for device_id since you're basically injecting your iGPU's own id! You may keep the patch for unifiedmem which is meant to increase VRAM to 2048MB but that's not mandatory at all. You really should get rid of all those and only stick to the bare minimum, i.e.: AAPL,ig-platform-id 05003B19 DATA // selects SKL layout 0x193B0005 AAPL,slot-name internal@0,2,0 STRING hda-gfx onboard-1 STRING framebuffer-patch-enable 1 NUMBER // enables framebuffer patching framebuffer-unifiedmem 00000080 DATA // sets VRAM to 2048MB and, unless you've patched your BIOS through Grub shell to increase DVMT pre-allocated memory to 64MB or 96MB (if it's set at 32MB by default), you would normally be expected to add the following patches: framebuffer-fbmem 00009000 DATA // sets cursor memory to 9MB framebuffer-stolenmem 00003001 DATA // sets FB memory to 19MB See this thread for explanations and details.

1536MB VRAM is the correct default value; you must have had a patch in Catalina that increased VRAM to 2GB. See the Whatevergreen User Manual. In order to get audio, make sure you inject latest versions of Lilu + AppleALC kexts; you may then experience with the various layout ids available for ALC293 as per listed in the AppleALC wiki. See here. I invite you to post a zipped copy of your Clover EFI folder and specify the version of Clover + Clover Configurator app you're using.

Neither should be in the config... you do not need to fake/inject any iGPU id since CFL id 0x3E92 is natively supported by macOS (and, for very obvious reasons, you do not need to fake/inject a device's own id) on the other hand you need to inject CFL layout (i.e. ig-platform-id) 0x3E9B0007. I posted the 4 x properties to inject on p1 (as per what you copied right above) so why don't you just configure that? I added a link to the Whatevergreen User Manual on p1, you should consult it to try and understand how things work and learn what the iGPU id is vs. framebuffer layout/platform id. I added a link to ARK Intel for your i5-8400 CPU on p1. You should also consult it to understand a little about your CPU/iGPU specs. ID: 3E9B0007, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00801302 TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel UHD Graphics 630 Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x000003C7 - ConnectorDP 01050900 00040000 C7030000 02040A00 00040000 C7030000 03060800 00040000 C7030000

Are you deliberately doing things incorrectly?

Screen mirroring with what kind of 2nd display?

Not quite! You're injecting a totally duff value for your framebuffer layout. Also make sure that you're using all appropriate files for your given OC version. For instance OC 0.7.6 with files from a previous version is a complete no-no. You've got to use the entire fileset from the selected OC release. Good luck.

This is getting a little difficult to follow... I gave you the list of expected Coffee Lake settings. Did you try them out?

If you opt for the KBL framebuffer, you also need to fake device id 0x5912.

1. -> I doubt it; as I said that config is close to being empty and contains no injected properties at all. Where would the Kaby Lake properties come from then? Patched DSDT or SSDT tables? I suggest you post a zipped copy of your Clover EFI foilder. 2. -> well, you simply re-inject the same properties; you surely know how to do that if you already followed the Dortania guidance...

Unfortunately, this is not a suitable/compatible platform for Hackintosh purposes: Vega8 is a Zen APU so, as stated previously, it's unsupported. See Dortania's GPU documentation. Same about Qualcomm QCA9377 as stated in our Wireless cards inventory. It would have to be replaced by a supported Broadcom M.2 crd or a supported USB adapter but it's kind of irrelevant anyway. If you want confirmation, by all means consult Shaneee's dedicated site for running AMD platforms as Hackintosh: https://amd-osx.com

Erm... very confusing... that Clover config of yours is next to empty so I utterly fail to see how it could work. It cannot be the config you're using. your IOReg extracts show a Hack set as an Haswell-based iMac14,2 + Kaby Lake HD630 settings including: iGPU fake id 0x5912 KBL framebuffer 0x59120000 3 x expected DP (type 00040000) output ports 1 x display on 1st output port con0, whatever that may represent on your PC (DP or HDMI) Kaby Lake framebuffer 0x59120000 defines the following output ports (connectors): ID: 59120000, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000110B TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 115 MB, MAX OVERALL: 116 MB (122171392 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 01050900 00040000 87010000 02040A00 00040000 87010000 03060A00 00040000 87010000 The IOReg info clearly does not show what would normally be expected for the 8th gen Coffee Lake/UHD630 model you described but so be it if that's what got you going in High Sierra... If the recommended settings and black screen patches fail to get you going, try and re-apply the same High Sierra settings to your OpenCore config.

Intel i5-8400 is 8th gen Coffee Lake fitted with UHD 630 iGPU carrying id 0x3E92. As such, it's part of the early CFL iGPUs natively supported from High Sierra right through Monterey. I looked at your iGPU properties injection: I suggest you replace it with the following set of properties, ensuring you remove that "device_type" property which looks wrong to me: AAPL,ig-platform-id 07009B3E DATA framebuffer-patch-enable 1 NUMBER framebuffer-stolenmem 00003001 DATA framebuffer-fbmem 00009000 DATA That should work (as per WEG user manual) but you may also want to enable Vector Acceleration in the UEFI section of your OC config. The Dortania Big Sur guide for Coffee Lake desktop platforms also mentions that, should you encounter black screen on H370 (and others) platforms, you should follow/apply the BusID patch: https://dortania.github.io/OpenCore-Install-Guide/config.plist/coffee-lake.html#deviceproperties https://dortania.github.io/OpenCore-Post-Install/gpu-patching/intel-patching/busid.html Of course, it would help if you could identify all your output ports and type in High Sierra given that you can boot it with Clover. Use IORegistryExplorer app to that effect and plug/unplug monitors in and out of your video ports and see which connector shows changes in the app.

Re: graphics, according to Intel ARK, i5-6300HQ is fitted with HD 530 iGPU (id 8086:191B), not HD 520, so your initial statement was correct.

Probably not if running on an integrated GPU (APU), they're unsupported. Possibly if it's fitted with a supported dGPU.