Hervé

Is there any particular reason why, as suggested by PM, you won't uncomment the properties injection for the DW1820A? Without this injection, you're highly likely to encounter system reset or plain freeze at startup.

I understand you already found the thread posted back in March with the same unresolved issue on exact same platform. Your IOReg shows that you've patched both con1 and con2 connectors to HDMI type but you also changed their Pipe : Did you get anywhere with default values, just changing the connector type and nothing else (knowing that this is usually only required to gain HDMI audio)? You would need to monitor your iGPU connectors' behaviour in IOReg as you plug and unplug your HMI cable on/off the laptop. If you see absolutely nothing, you probably have to experiment with different SMBIOS and/or CFL framebuffer layouts. https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md You use ig-platform-id 3EA50009 which is the expected one: ID: 3EA50009, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00830B0A TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel HD Graphics CFL CRB Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 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: 0x000001C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7010000 02040A00 00040000 C7010000 You may have to experiment with different combinations of SMBIOS/CFL framebuffer layouts or even patch the connectors further, HDMI usually being attached to connector con1. Did you experiment with WEG igfxonln=1 boot arg at all? https://github.com/acidanthera/WhateverGreen

Touchscreens usually are USB based and require no specific kext for support. Big Sur dropped support for some ancient/older USB stuff and that can prevent items such as Touchscreens to work. I experienced this on my Skylake laptop and only fixed this by applying the USB HID fix.

What if you simply re-open the Bluetooth Prefpane instead after wake and wait a few seconds? Specifying the type of wireless card/bluetooth module/chipset you have would be most useful of course...

Moving to Precision M section where you'll find fairly recent threads about M4800 Hackintosh. Do look those up. Kepler dGPUs are last natively/officially supported in Big Sur. In Monterey, they require specific patching since support was dropped.

That's the spirit; well done.

BCM4352 chipset is not supported OOB; it requires patching. Did you do that? Lookup the existing threads about DW1560, there are several in which you'll find all that needs to be done.

@Lin_25 Before anything else, please post your system's hardware specs (exact CPU model, iGPU model, audio codec, LAN, wireless, card reader, etc.). Latitude 5480 can be Skylake with HD5x0 graphics or Kaby Lake with HD6x0 graphics so settings would differ. Do also consult the numerous threads about the Latitude 5480 that are available in this very section.

Start here maybe: https://www.insanelymac.com/forum/782-opencore-releases/ Careful as you may not manage to get your BCM43224 wireless card working underMonterey... So proceed with the understanding that you're highly likely to require a change of wifi card.

No, as stated before, you need the SMBIOS of an Ivy Bridge model to obtain proper power management on an Ivy Bridge laptop. You may only use the MBP of a more recent model such as Broadwell MBP12,1 at initial installation (not mandatory thanks to -no_compat_check boot arg) and update (mandatory unless you apply tricks to your SMBIOS) for compatibility reasons with Monterey. Given the likely trouble you're likely to experience, I recommend sticking to Big Sur, the last macOS version too fully and natively support HD4000 graphics.

Make sure you reset NVRAM at next reboot after making your config changes.

I've just tried to boot Monterey 12.3.1 on my E7270 after re-instaling a DW1820A and all was Ok with Clover and the usual properties injection (same as you currently have in your OC config). As such, there's no issue using a DW1820A in 12.3.1 but it's your properties injection that must be the issue. I'm not 100% certain of this but I was somehow led to believe not that long ago that OC had changed and required DATA type device property injections only. Don't know if this is true but, if it were, the compatible and pci-aspm-default properties you currently inject for your DW1820A would need to be revised. Try and put your config through the OC checker/validator or convert all properties to DATA type. Try this: compatible 706369313465342c34336130 DATA pci-aspm-default 00000000 DATA

As a test, disable WLAN in BIOS; in case it's the DW1820A that causes the issue.

No KP on your screenshot, looks more like it's hanging. Why don't you post a zipped copy of your EFI folder. I has no issue on updating to 12.3.1 on my own E7270 but then again, I'm using Clover, not OpenCore.

You need to Google about M.2 slots; they're of different types with different keys (A, E, A+E, B, M, B+M) and for different usages: WLAN (typically A&E key), WWAN (typically B key), NVME/SATA (typically B&M key), etc. Meantime, you may look at this: https://www.delock.de/infothek/M.2/M.2_e.html Your adapter board can only go in your WLAN slot where your current Wireless card is.

None; but make sure you disable hibernation as per the details provided in the dedicated thread in our FAQ section.

If laptop has sufficient space for it, go for an Apple BCM94360CS2 on an M.2 adapter: https://osxlatitude.com/forums/topic/16122-apple-bcm94360cs2-in-hackintosh-laptops-a-great-possible-alternative-but Failing that, consult the list of M.2 cards posted in this very section.

As stated above, you should be using the SMBIOS of a MBP9,2 or MBP10,2; this will require to add boot arg -no_compat_check and will block all future updates OTA. For Monterey updates, you'd have to switch back to the SMBIOS of a supported model (the iMac SMBIOS you currently use or MBP11,4/5, MBP12,1, etc.).

You would need to details the particulars of that old installation if it had non-vanilla settings.

This an Ivy Bridge laptop, isn't it? If you use an SMBIOS different from MBP9.x, MBP10.x or MBA5.x, you won't have CPU power management working and are therefore likely to experience such issues as degraded performance and/or increased heat. Whatsapp and VS Code crashing -> could be linked to issues with Metal (remember that Monterey has no native support for HD4000 unlike Big Sur). As for battery management, well... I'm not sure it can work with the SMBIOS of a desktop but you'll sure need to inject a battery management kext.

I've doubled checked and there's nothing specific to 3rd party/add-on hardware in the patched DSDT. If you're on BIOS A20 and have the recommended settings in place, I'm a bit dry. Will have to make a new USB key to see.

Strange; let me check the patched DSDT. The alternative will be to use patched SSDT tables only, which is entirely feasible nowadays of course.

DSDT.dsl is the DSDT source code and of no particular use except if one wants to further patch the table. I only provided it to avoid the Intel iASL bug encountered if recompiling the table after direct modification of the .aml file. What BIOS version is your E6230 running? Patched DSDT is made from A19 so you gotta run that version at a minimum. As I said earlier, make sure you run on last version A20.

If you meant my E6230 Catalina guide, it contains a power management SSDT for i7-3540M CPU so you need to delete it and replace it by a table that suits your i5-3340M processor. It clearly says so in the guide. Given that I initially had an E6230 with that very specific i5 CPU, that table is available in the guides I posted for previous OS X/macOS versions up to Mojave but I attach a copy below. Feel free to rename the file as you wish. i5-3340M_ssdt.aml.zip