Hervé

There's nothing strange, just a total lack of understanding and knowledge on the matter. There's no secret and if you don't try (to understand), you don't get (knowledge)... Simply copying stuff in the blind leads nowhere, you got that proven if nothing else. Don't hesitate to Google for info on framebuffer, graphics memory, picture size or colour depth. Eg: https://www.quora.com/How-can-the-size-of-the-VRAM-determines-the-resolution-and-color-depth-of-the-monitor

Of course it works! Why do you say it's strange? And if it works, isn't it obviously kosher ?

It appears you've not realised that framebuffer-patch-enable is a boolean flag (so set it to 0 or 1 and type NUMBER rather than 8 x bytes with type DATA) and that, by setting it to 0 (i.e. FALSE), you actually disable patching. As such, all subsequent framebuffer patches in your config are rendered useless (but probably not connector patches since these have their own boolean flags)... 4K output usually requires that framebuffer memory be a minimum given size and usually greater than 32MB (I don't know the exact minimum value). Such requirements do normally imply that framebuffer memory settings be left untouched. Instead, your framebuffer patches basically limited framebuffer memory (stolenmem) to 19MB which would explain why you could not obtain 4K output. Such patch is only required (and usually accompanied by cursor memory patch too) if DVMT pre-allocated memory is set to to 32MB in BIOS and the selected OS X/macOS framebuffer default memory settings (stolenmem + fbmem) exceeds 32MB, in which case KP occurs if no patches are applied (cf. Firewolf's 2015 explanations). This usually applies to laptops only, desktops (recent/modern ones) very frequently allowing to adjust DVMT settings in BIOS. You inject/select the expected CFL framebuffer layout 0x3E9B007 which defines/sets/uses 57MB of framebuffer memory (stolenmem) and no cursor memory (fbmem 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 so framebuffer memory is indeed >32MB by default. Given that you do not encounter a KP when you boot without framebuffer patches (i.e. no memory patches), it's fair to conclude that your desktop's default or current DVMT pre-allocated memory is set to at least 64MB (you may be able to check the exact value in BIOS settings or by checking BIOS info through GrubShell). So, indeed, do not apply any framebuffer patches (or limit it to VRAM (unifiedmem) patch), only connector patches if required (for instance to enable HDMI audio output by setting the relevant connector to HDMI type 00080000). I'm not sure all the connector patches you've configured are desired, necessary, suitable or useful though... I invite you to read the Whatevergreen User Manual and a recent article I posted at IM on the matter of DVMT pre-allocated memory/framebuffer memory settings & patches. https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md https://www.insanelymac.com/forum/topic/349132-what-are-dvmt-stolenmem-fbmem-cursormem-and-why-do-we-patch-these-for-broadwell-and-later/?tab=comments#comment-2768210

You may find useful to consult the various threads available at IM that detail the OC changes from one version to the next. https://www.insanelymac.com/forum/782-opencore-releases/

Then you have incorrect settings to fix at lower level; check the SMBIOS set in your config so that it is one compatible with High Sierra; check your BIOS settings (disk in AHCI mode for instance).* You said you followed Jake's guide to the T; which mode, UEFI or legacy? Please be very specific in everything you do and state.

Screensize should be irrelevant. Did you reformat the target disk HFS+ with partition scheme GUID through Tools->Disk Utility once you reached the macOS installation screen? It's the 1st thing to do before you proceed with the installation. Assuming you have an SSD, you will want AFPS. Boot pack is for models with BIOS version A19 or higher, is this your case?

By the way, BCM94360CD is BT4.0, not BT5.0.

As per our published rules which I invite you to read before anything else, no links or references to distros. As a newbie to the Hackintosh world, you're gonna have to go through the pain of educating yourself through much reading, much trying, much failing, much trying agin and so on. There's no other way. We do not support nor welcome shortcuts of distros which are more evil than good. Good places to consult are our Guides and FAQ forum sections. We have several guides for other Broadwell Latitude models that include E5x50 and E7x50 laptops. If you use the forum Search facility, I'm sure you'll also find plenty of threads relating to the E5x50 family.

You're highly unlikely to find a laptop that meets all this nowadays. In recent years, the trend has heavily shifted towards low-power and slim/light platforms. Today, laptops with extra slot for a 2.5" hard drive/SSD usually are 15.6" or larger models. Those don't fall into the slim and light weight category, more into the bulky and heavy one... Upgradable dGPUs, kind of deprecated these days; it was something usually restricted to mobile workstations in the form of MXM modules but I don't think this kind of technology remains much in use today. And even in the days where this was available in laptops, MXM modules were often limited to specific offerings by the manufacturer due to proprietary design. So upgradability was very limited and usually to 2 to 3 dGPUs, 4 if you were lucky.. Examples: Dell Precision M4800/M6800. https://dl.dell.com/content/manual32906200-dell-precision-mobile-workstation-m4800-owner-s-manual.pdf?language=en-us&ps=true The last 14.1" Dell mobile workstations were the old Merom/Penryn C2D-based Precision M2300 and M2400. Former was nothing but a Latitude D630 with a better nVidia dGPU (Quadro FX 360M) than the standard/regular one (Quadro NVS 135M). Latter was the same as the Latitude E6400, also with a better nVidia dGPU (Quadro FX 370M) rather than the standard/regular one (NVS 160M). All subsequent Dell mobile Precision workstations are 15.6" and 17". https://en.wikipedia.org/wiki/Dell_Precision#Dell_Precision_Mobile_Workstations Keep looking for the rare beast!

Very old stuff my E6440 guide and research work but, yeah, those were the days... Yes, this is the kind of adapter you need though you should be able to find it for much cheaper. Look it up. To illustrate why you should feel safe about the BCM94360CD on a mini-PCIe adapter re: space/size:

Of course you need a mini-PCIe adapter board for an Apple BCM94360CD card; please refer to our dedicated thread on the matter as stated above. We also have a couple of inventories re: compatible/non-compatible cards. They cannot be exhaustive of course but look these up. Mini-PCIe slots and cards have been deprecated since circa 2015 so you're highly unlikely to find what you wish for (a Big Sur compatible mini-PCIe card with BT 5.0). As for Apple, they've long stopped using mini-PCIe cards in favour of their own proprietary interface...

Well it does say DW1550 on it, doesn't it? But, unlike an Apple Card, it does not work OOB though... I've checked size of Apple's BCM94360CD on its mini-PCIe adapter (my leftover from the E6220 I sold last year) and it does fit exactly the size of a full-size mini-PCIe wireless card so I'd go for that.

Here is that old thread re: E6440 mini-PCIe slots: https://osxlatitude.com/forums/topic/10117-half-size-pci-wifibluetooth-card-for-airdrop Meantime, on the Net...

As they say in the Dortania documentation, get to know your hardware 1st and foremost... There are no M.2 slots in the Latitude E6440. Otherwise you'd have had no need for your mini PCIe-to-M.2 adapter (just for antenna adapters). Do consult the E6440 owner's manual or Dell's own support forum where this was discussed many years ago. The Latitude E6440 has 3 x mini-PCIe slots: 1 x full size (WWAN) which is combo PCIe/USB/mSATA (the one to use for a combo wifi+BT card) and 2 x half-size (WLAN + 2nd one under the WWAN slot). I know, I once had an E6440. I'm pretty sure we also have at least 1 old thread in which I actually illustrated those slots. Do use for forum Search facility... Space is a little tight for a BCM94360CD in the E6440 but I think it would fit in the WWAN slot. I'll give you the card's measurements. Re: Apple BCM94360CD, please refer to the dedicated thread we published back in 2014 in our R&D forum section. Another alternative to your defective BCM94360NG installation is to opt for a BCM4352-based mini-PCIe card such as the DW1550. It's supported in Big Sur and I understand it remains so in macOS Monterey, so...

-> moved to Wireless & Bluetooth support section. It's not a Latitude E6xxx related matter. No need for any kexts in OS X/macOS for this card, it's 100% natively supported even for Bluetooth. Regarding your signal-related issue, it could be a defective adapter board if you connected your laptop's antennas to the adapter's IPEX connectors and the BCM94360BG card to the adapter's MHF4 connectors (you did make those, right?). I assume you did make all the necessary antenna connections but I'd start by checking they're all properly made and nothing is loose. Careful with those MHF4 antennas, they can be tricky to put in place and the connectors tend to be fragile. An Apple BCM94360CD in a mini-PCIe adapter would have been a much better and much cheaper choice in your E6xxx laptop, whatever the model (all models have the required 4 x antenna wires). That card performs much better than any Fenvi BCM94360NG and with the added benefit of using IPEX connectors... Perfect for older laptops fitted with mini-PCIe WLAN slots/cards.

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.