Hervé

Beta4 update published 31st July. Build 23A5301h.

Try and inject your screen's EDID. If you've not done so already, I also suggest you patch your BIOS to increase DVMT size to 64MB or 96MB. It's explained in our FAQ tuto on the matter as well as on that Git repo you followed. You'll then be able to remove the injected properties that restrict fbmem to 9MB and stolenmem to 19MB. You would no longer need them and would gain 4K output alongside.

I don't fully understand why you inject some graphics properties that are the same as natively defined in KBL framebuffer 0x59160000; sure, it's harmless but why don't you try a more basic config? AAPL,ig-platform-id 00001659 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA Your issue may also come from the use of kexts that I don't believe required: CpuTscSync + ECEnabler; I would recommend you disable/delete them.

@KazuDante KBL HD620 is natively supported in Sonoma with the usual settings. The KBL graphics drivers remain provided as detailed in my Sonoma beta #1 thread. You must be using an incorrect config, especially if you have no success in Ventura. Please post your system's hardware specs, a zipped copy of your Sonoma EFI config (config file + kexts folder + ACPI folder, the rest is not needed) and, ideally, an IOReg extract too. You should be using the settings recommended in the Whatevergreen User Manual, i.e. KBL frame buffer layout 0x59160000, default being 0x591B0000. 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 02040A00 00080000 87010000 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 03060A00 00040000 87010000 Framebuffer 0x59160000 natively supports HDMI output out of connector con1 but you'll need to patch the connector's type to HDMI (00080000) to obtain HDMI audio. Framebuffer 0x591B0000 requires to patch con1's Index and Bus Id from 0204 to 0105. If your laptop's BIOS sets DVMT to 32MB by default, you'll have to inject the properties that patch fbmem to 9MB and stolenmem to 19MB. See our dedicated thread on the matter ins our FAQ forum section for details. No such patches are required if DVMT is set to 64MB or above. Intel i5-7200U CPU integrates HD620 iGPU with id 0x5916 which is natively supported by the KBL driver so absolutely no need to fake any iGPU device. Finally, make sure you use MBP15,2 SMBIOS for Sonoma. In Ventura, it should be MBP14,1.

OCLP v0.6.8 now provides support for Broadcom legacy wireless cards that Sonoma officially dropped. Good news for all of us relying on BCM4350/BCM4360xx cards for Wireless and Bluetooth services. Not tried it yet but process is understood to be as follows with OpenCore (cf. dedicated Sonoma beta threads at Insanelymac.com): add boot-arg amfi=0x80 (or amfi_get_out_of_my_way=1) disable SIP with csr-active-config set to 0x803 (0x0FEF is Ok too) block vanilla kext IOSkywalkFamily kext in the config file disable SecureBoot if applicable inject older kexts IOSkywalkFamily + IO80211FamilyLegacy kexts (in that specific order) once booted with those settings, apply OCLP root patching and reboot Broadcom wireless cards that were previously supported in Ventura are then expected to be operational again Not sure this works with Clover given the lack of system's kext blocking facility afaik. Will try to test asap with OpenCore on my E7270. Edit: This is fully supported with Clover r5157 and later.

Released July 25th, 2023. Build 23A5301g. As usual, no OTA update offered when running with MBP15,2 SMBIOS and had to reboot temporarily with iMac19,1 SMBIOS. Otherwise, completely smooth update.

That's entirely up to you, we cannot guess your ability or not in that respect. You may simply follow the documentation available on Dell's support web site, it's not very difficult.

See my old Latitude 7490 guide available in the Guides section. To me, you're injecting incorrect properties for your iGPU: I can't see why you'd patch con0's pipe to 0x12 for instance.

There will be no need to enable TRIM in recent macOS versions such as Big Sur, Monterey or Ventura. It'll be enabled by default.

in 2023, it's kind of irrelevant... There are many PCs with bugged BIOS tables (DSDT and/or otherwise), Dell is not a unique actor in that respect. Yet, Dell laptops remain ideal platforms by far and large (especially Latitude laptops) when it comes to running OS X/macOS on them.

The brightness keys ACPI patch I posted does not apply to the Sandy Bridge Latitude E6x20 as is. I tried it to no avail on my E6220, whether BIOS operating in legacy of UEFI mode. Instead, I called on a different patch I had found on the web that I adapted for my E6220. I posted the details in my E6220 Mojave guide; look it up. It's a simple ACPI renaming patch in the Clover config file + a patched SSDT-Q66 table. With Mojave, I completely moved away from a patched DSDT to a simple and basic set of a few patched SSDTs + associated ACPI patches in the bootloader's config file. It's very minimal and very efficient. In a nutshell, all you do is replace the original _Q66 event handling method: Method (_Q66, 0, NotSerialized) // _Qxx: EC Query { If (LNotEqual (ECRD, One)) { Return (Zero) } NEVT () Return (Zero) } by this revised code: Method (_Q66, 0, NotSerialized) // _Qxx: EC Query { If (LNotEqual (\ECRD, One)) { Return (Zero) } NEVT () \_SB.AMW0.WED0 (One) Mid (\_SB.AMW0._WED (0xD0), Zero, 0x06, Local2) If (LEqual (Local2, Buffer (0x06) { 0x02, 0x00, 0x10, 0x00, 0x50, 0x00 })) { Notify (\_SB.PCI0.LPCB.PS2K, 0x0365) } If (LEqual (Local2, Buffer (0x06) { 0x02, 0x00, 0x10, 0x00, 0x48, 0x00 })) { Notify (\_SB.PCI0.LPCB.PS2K, 0x0366) } Return (Zero) } making sure not to forget the ACPI renaming in your config file which is necessary to bypass the original _Q66 method of the (native) DSDT table and inject its replacement through SSDT: Find: 5F513636 (="_Q66") Replace: 5F583636 (="_X66") And that's it.

As long as it's the same motherboard model (even with a different CPU if it's soldered provided you're not using a CPU-specific power management SSDT but the PlugIn method), all should work upon straight replacement and without any need to re-install macOS at all. Just make sure the replacement motherboard has same or latest BIOS version and adequate/same BIOS settings as the old one.

4K@24/30Hz over HDMI is perfectly normal, that's the limitation of those 8th gen Whiskey Lake CPUs. See those of the i5-8365U here. 4K@60Hz is only supported over DP output. On the 7400, that'll be out of the USB-c port with a DP adapter/cable (or TB if the port supports this).

Change SMBIOS to MBP11,4. Reboot and, at the OC Picker, make sure to reset NVRAM and reboot again.

Re: 4K over HDMI and/or 4K@60Hz, you'll have to patch your BIOS and set DVMT to 64MB since it probably sits at 32MB at present. See our FAQ section on this matter, you'll find a couple of threads there.

Re: renaming of B0D3 to HDAU, as I said, you need to do it yourself. Simply convert both strings to hex and, in the ACPI patching section of your OC config, just add the associated find/replace values and enable the patch. It'll be similar to the existing patches already present. If you cannot boot without the patched DSDT, you need to add the remaining patched SSDT tables that are missing. Follow what I have suggested above several times now + the Dortania documentation for Haswell laptops. Note that, you'll need the patched SSDTs for HPET associated OC config's ACPI patches to obtain fully working USB3.0 port. I expect you would also require the SSDT-GPRW too. For brightness keys, you may apply the solution that I have described in the Technical Info/R&D section several years ago. Note that: SSDT-HPET requires the associated HPET renaming SSDT-XOSI requires the associated OSID and _OSI renamings SSDT-GPRW requires the associated GRPW method renaming SSDT-BRT6 requires the associated BRT6 method renaming My old E6440 guide is obsolete by today's standard now but it does list the various ACPI patches and kexts that were required to obtain a fully working laptop under OS X/macOS. Things will be identical for your E6540, except the USB ports mapping probably. You may find this E5540 OpenCore guide useful too. You can certainly grab patched SSDT tables and associated OC config ACPI patches from the posted EFI.

You're still using the patched DSDT, which I believe to be inadequate. You're still using the SSDT for CPU PM; get rid of it, it's totally useless with SSDT-PLUG that natively provides CPU PM. You're still using USBInjectAll + USBPorts kexts You need to manually add the B0D3 to HDAU renaming patch to your OC config. In case you had missed this, it's s simple hexadecimal find/replace operation. You're still using MBP11,5 SMBIOS instead of MBP11,4. What are your laptop's specs in terms of CPU and screen resolution? Post a new IOReg.

Ok, although your OC config only calls a limited and partially correct set of them (thankfully!), your OC setup is a complete mess in terms of ACPI tables and kexts with a mix of duplicate and irrelevant tables, incomplete arrangements and obsolete stuff... You need to clean up to avoid confusion and mistakes. 1) ACPI tables: Get rid of all those duplicate DSDT/SSDT and all those SSDT-n tables that come from the past; only use those Dortania recommended tables. For instance, you have 2 x patched DSDT tables that contradict each other in terms of patches and 3 x CPU power management tables! Your patched DSDT renames EHC2 to EH02 but does not do so for EHC1. I don't know where you got that patched DSDT from but I would get 2) Kexts: You've got USBInjectAll AND a generated USBPorts kext; you should only have one or the other but certainly not both. If USBPorts has been generated for your E6540 platform, then keep it and get rid of USBInjectAll; otherwise, just boot with USBInjectAll and generate your platform specific USB ports mapping kexts with the usual tools. 3) OC Config: ACPI patches: I would apply the renaming of EHCx to EH0x. I would apply the renaming of GFX0 to IGPU. I would apply the renaming of B0D3 to HDAU (required for HDMI audio output) Device Properties: your graphics settings are somehow incorrect: Azul FB #12 0x0A260006 defines the following graphics arrangements: ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 You've patched connector con1 for HDMI output and connector con2 for DVI output. Both patches are spot on, as described in my Haswell HD4x00 patching guide. you patch fbmem to 0x01300000, i.e. 19MB. Obviously, there is absolutely no need for this on Haswell HD4600 so get rid of this. Can't see why you inject properties for the AMD dGPU; it's totally unsupported in OS X/macOS and must be disabled/turned off to save battery life. I remind you that you use boot-arg -wegnoegpu to disable this dGPU. SMBIOS: use MBP11,4 (iGPU only) rather than MBP11,5 (dual GPU). See our existing E6x40 guides and published technical information about Haswell graphics patching.

The -wegnoegpu boot arg "disables" the dGPU but it's unlikely to do anything as far as applying/removing power to the device at ACPI level is concerned. You would need to post your DSDT (assuming dGPU is handled in it) or your entire set of raw/extracted ACPI tables to verify how it's natively configured. NB: In your OC config, you drop SSDT tables CpuPm and Cpu0Ist. This is wrong for a Haswell platform such as yours, this only applies to Sandy Bridge and Ivy Bridge platforms. Disable/remove these drops.

There is no access to those Google Drive links you keep posting...

Remove the OCLP patch, reboot and re-apply the minimum patches. Read the documentation before proceeding. At worst, re-install macOS from scratch.

You can boot with boot arg -igfxvesa and that’ll disable all graphics support to run with a basic unaccelerated mode.

I guess it depends entirely how you apply the OCLP patches. This is a Hackintosh, not a Mac so you must not apply all those patches that apply to Mac hardware. Only select the patches relevant to Haswell graphics (eg: for MBP11,x models) and disable SiP.

Perfectly normal: no support for Haswell graphics in Ventura; you have to apply the OCLP patches.

An Ioreg extract would be most useful…