Hervé

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…

You may install Sonoma the exact same way you followed for Ventura. Just update your bootloader to the latest version, same with your add-on kexts (especially Lilu & Plugins) and make sure to use the relevant Lilu/Whatevergreen beta boot args.

Are you still running with OpenCore?

Try and add the USB HID patch in your OC config. You'll find the details of the path in my Latitude E7270 guide and/or through a forum search.

The graphics properties you inject are totally incorrect. Where did you get these from? If you wish to inject a connector's "alldata", know that it's a 12 bytes value, not just 4 like you've entered (presumably for DP type which is the native type of con1). Remove this. Injecting a stolenmem value is not required for HD4000 and it would be wrong to inject a different one; don't do this. Here, you inject the same value as natively defined in the framebuffer, it's therefore entirely useless. Remove this. Injecting memorycount, pipecount and portcount is unnecessary for HD4000 framebuffer 0x01660003. Here, you inject the same values as natively defined in the framebuffer, it's therefore entirely useless. Remove these. Generally speaking, injecting properties carrying the exact same values as natively defined in a framebuffer is something entirely useless (though harmless). The framebuffer native settings are as follows: 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 All you really ought to do is: inject con1's type as HDMI because that's where HDMI output port gets attached in macOS for those E6x30 laptops. This is required for HDMI audio. set fbmem to 8MB because default value (16MB) causes the corruption you experience. So remove all those incorrect properties you currently inject and limit your settings to the following: AAPL,ig-layout-id 03006601 DATA // Optional because it's the default layout framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA framebuffer-con1-enable 1 NUMBER framebufffer-con1-type 00080000 DATA See the following for references: whatevergreen user manual my E6230 guide our HD4000 patching guide Finally: Get rid of those Realtek and Atheros Ethernet kexts you inject. Those do not apply to the Latitude E6x30 laptops which are fitted with an Intel LAN card, so inject the correct Intel driver instead. You'll find it in all those E6x30 packs available on the forum. Intel wireless card may work, depending on the model you have . Check ITLWM repo, I see that you inject one of their kext. Can't say more, you've not posted your system's hardware specs. You're missing the CPU power management SSDT (sometimes named SSDT-PM.aml). Given that you have an Ivy Bridge laptop, you need to generate this SSDT for your CPU with good old Pike R Alpha's generator script. You correctly drop CpuPm + Cpu0Ist SSDTs in your config but you won't obtain any CPU power management without the CPU-specific SSDT-Pm table. This may also impact Sleep & Wake. Can't say more, you've not posted your systems's hardware specs... Latitude E6x30 laptops are fitted with IDT 92HD93 audio. You need to inject AppleALC layout 12 (i.e. 0x0C) to get audio working, the values you inject being wrong and contradictory: As stated in the Dortania OpenCore guidance, 1st thing 1st: get to know your hardware...

Released July 11th, 2023. Build 23A5286i. Beta3 update, to coïncide with the release of the 1st public beta.

We have existing guides for Latitude 5x80 and other Skylake E7x70in our Guides section. Did you check them out? I also recommend you read the information posted in our Technical Information/R&D section so that your familiarise yourself with capabilities, limitations and constraints of your hardware with regards to running macOS.

I experienced the same with Big Sur when using OpenCore on my E6230. See my guide. I never managed to identify the root cause. Switching to Clover with what was, in essence, an identical setup sorted the issue. I never went back to OpenCore on that laptop.

No USB touchPad listed in SysInfo, sorry. Probably PCIe then... Why don't you post and IOReg extract taken from macOS?

What's Catalina v15? Didn't you mean 10.15 instead? We have existing guides for the E6x30 series, don't hesitate to consult them and use the provided packs. This will include support for USB ports and touchpad. As for the wireless card, it depends entirely on the model which you omitted to specify. If you search the forum using the provided Search facility and browse the relevant information sections, you'll find answers to most if not all of your questions. Natively, E6430 can run macOS up to Big Sur; beyond that, you need OCLP patches.

Not at all. Identify the type of touchscreen you have. If it's USB and you've mapped your ports properly, it should appear in SysInfo->Hardware->USB. You may then apply the USB HID patch in your config. See my Latitude E7270 guide for reference. NB: As per our published rules -which I invite you to read-, please use the Reply box to post replies (it's available at the bottom of each page!) rather that Quotes. Thank you.

I'd say it's highly likely that your BIOS is set for wake on USB.