Hervé

I'd recommend using pre-existing/ready-made SSDTs rather than creating new ones. In all the Hacks I've had, ready-made ones never have been a problem.

Looks like the above method no longer works, certainly not in Big Sur 11.4, possibly before. @Slice reminded us that Gatekeeper can be used as an alternative. Many people often disable Gatekeeper by default through Terminal command: sudo spctl --master-disable Kexts can be cached from /L/E in Big Sur (and Monterey) by re-enabling Gatekeeper, copying the kexts to /L/E through Terminal via sudo commands and authorizing the kexts from Security & Privacy PrefPane. Upon such authorisation, Gatekeeper will rebuild the cache and restart macOS with the newly cached kexts. Gatekeeper can then be disabled again afterwards. sudo spctl --master-enable sudo cp -Rf <path>/xxxx.kext /L*/E*/ GateKeeper can be disabled again afterwards.

No patched DSDT should be required. Only SSDTs.

Can't find any reference to any Aspire (not espire) E 13 on Acer's web site. You'll have to post the correct reference of the model and its specs of course. This being said, the few Google findings I obtained for an Aspire E13 or ES13 all lead to low-end laptops with Bay Trail, Braswell or Apollo Lake CPUs and associated GT1 Intel HD/HD 500 graphics, i.e. platforms not compatible with macOS and therefore unsuitable as Hackintoshes. If this is your case, don't waste your time any longer. https://osxlatitude.com/forums/topic/2998-min-requirements-for-os-xmacos https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards

It would be a mistake to believe that the E7470 and the 7490 are "very similar laptops". They're not. Former is a 6th gen Skylake model and latter is 8th gen Kaby Lake R model. They're of different generations and use different CPUs, different chipsets, different iGPUs, different audio codec, etc. Afaik, the only pieces of hardware they have in common are the Intel GigEthernet card and the Realtek SD card reader. Your may create your 7490 OpenCore setup from an existing E7470 one but you must extensively modify it of course. At this point of time, given your stated skill set, I would recommend you use the following process instead: 1) follow the Dortania Opencore guidance for Kaby Lake R laptops 2) grab the last Clover pack I posted in my Latitude 7490 guide and adjust your Opencore setup accordingly (patched tables, properties injection, kexts) Failing that, I believe there are several copies of Opencore EFI folders for Big Sur available in various existing 7490 threads. Here for instance.

I suggest you start by simplifying your properties injection in order to fallback to a minimum set of working properties that do not get graphics acceleration altered by complicated and probably misunderstood properties. Just start with the basics (CFL framebuffer id, device id, fbmem + stolenmem patches if required). Once you have graphics acceleration working, you can look at additional outputs such as HDMI and that sort of things. Please refer to the thread linked in the last post before your 1st one. As I said, it's limpid as far as getting graphics acceleration working is concerned on the exact same platform as you, although OP clearly misunderstood what con0/con1/con2/etc. were in terms of output ports; anyway no reason why his setup would not work for you as long as you apply them the same way. NB: As per our published rules -which I again invite you to read-, please refrain from systematically quoting messages to post replies. Just use the Reply box available at the bottom of each forum page.

Your OC config shows a # character in front of location PciRoot(0x0)/Pci(0x2,0x0) for the iGPU. As such, you're not injecting any properties for your iGPU and that's why you're not getting any graphics acceleration. Uncomment that line, i.e. remove the # character and you should find that your properties injection will get applied. I expect that things should change thereafter... I can't say more about the iGPU connectors patches that are listed other than question their relevance. But that's another story. I'd also suggest you experiment with MacBookPro15,x SMBIOS. I noticed some odd ACPI patches too, though there's a good chance they do no harm, but just irrelevant:

No need for the AppleCpuPmCfgLock kernel patch; that for 2nd gen Sandy Bridge and 3rd gen Ivy Bridge platforms. You opted for SSDT-EC table instead of SSDT-EC-USBX table as recommended in Dortania's documentation. Dortania does state that SSDT-EC is for Broadwell and older systems when SSDT-EC-USBX is for Skylake and later. Being a Coffee Lake platform, your laptop falls into the 2nd category. UHD630 iGPU of i7-9850H carries native id 0x3E9B. As such, no need to inject that exact same device-id through OpenCore. It does no harm of course. MacBookPro16,4 may not be the correct or best SMBIOS to use though MBP16,1/MBP16,4 are 9th gen Coffee Lake with UHD 630 graphics. You could try MacBookPro15,1 or MacBookPro15,3 instead. Absolutely no need for the -no_compat_check boot arg in NVRAM. That's for systems using an officially unsupported SMBIOS in a given macOS version. Not the case here, whether you use MBP15,x or MBP16,x SMBIOS. The boot-arg will do no harm but will block all macOS update offers. If you keep getting back screen, do experiment with other CFL mobile framebuffer layouts such as those listed in the https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md. You may also refer to the suggestions provided in Clover Configurator app. I've never Hackintoshed any Coffee Lake laptop so I don't know how accurate these are but 2018 8th gen CFL MBP15,1 certainly uses layout 0x3E0B0006: You've linked to the Dortania documentation but it appears you did not followed it thoroughly. I suggest you do so using the section written for the Coffee Lake laptops: https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/coffee-lake.html

Please post a zipped copy of you OpenCore EFI folder. Resources subfolder can be removed to minimise size.

5GHz networks should normally be visible with a DW1820A but you may have an issue related to Country Code or something like that. Check what you card shows in SysInfo->Network->Wifi in terms of Locale and Country Code. Then check your box/router settings for 5GHz networks/SSIDs. You may need to use AirPortBrcmFixup and one of its parameters as indicated in our BCM4350 guide. But, what I don't understand the most is that you do not inject anything for your DW1820A given that the entry for it is commented out in your OC config... What's the reason for that?

You should find several threads or guides related to installing Big Sur on the Latitude E6x30 models. I myself posted a guide for the E6230 that you can consult for inspiration. There are a few things to note about the E6x30 models fitted with Fermi NVS 5200M: don't re-use the patched DSDT meant for a different model (certainly not one for the E6230/E6330) enable Optimus in BIOS so that you can run Big Sur with HD4000 graphics since it's no longer supported, the nVidia dGPU must be disabled through patched SSDT to prevent it from draining your battery unnecessarily if your LCD is low res (under 1600x900), inject Capri framebuffer 0x01660003 but if it is high res (1600x900 and above), use Capri framebuffer 0x01660004 if you opt for Clover as bootloader, I recommend version r5133 or later

You do reset NVRAM after any OC config change, right?

Try and change LauncherOption to Full. Can't see or imagine any relation to the CPU PM SSDT.

DmgLoading set to "Signed" ?

RTFM... and no off-topic please.

It should not be required with Mojave but try and add the following boot arg if it's still valid: -disablegfxfirmware Failing that, I've no idea why my posted Mojave bootpack would no longer work. I no longer have a Latitude 7490 so won't be be able to help much any more. Check the logs for potential hints regarding the KP and subsequent reset you mentioned.

OS X/macOS does not support disk in RAID mode, you have to set it to AHCI as indicated in my BIOS thread. Can't remember if this also applies to NVME disks rather than just SATA disks but, yes, you should follow the recommendations posted in that thread.

It's good practice to keep threads on-topic... This being said, what do you mean by "don't detect HDMI"? HDMI video & audio output require tuning/patching on Haswell systems. Video output requires: patching pipe of HDMI port/connector (usually con1) to change it from 0x09 to 0x12 (or system will freeze/hang on connecting/disconnecting the HDMI cable) patching HDMI port/connector (usually con1) to change connector-type to HDMI (00080000) is recommended though usually only necessary for HDMI audio Audio output requires: patching HDMI port/connector (usually con1) to change connector-type to HDMI (00080000) injecting hda-gfx property to iGPU device renaming B0D3 device to HDAU You'll find sample configs in our HD4600 graphics R&D topic as well as in most if not all our guides for Haswell laptops or threads pertaining to HDMI output on Haswell laptops.

I would not have expected any downgrade to be required given that the 7490, when I had it, never suffered any issue related to BIOS upgrades and I did a few. You can safely go back to the latest version.

With OpenCore, I found that I had to re-install beta1 from scratch and set SecureBoot to "disabled" (instead of "default") to be able to update to beta2 without hiccup. But all is well now. Once initiated, the update to beta2 completed all by itself.

Did you set your BIOS according to the recommended settings?

The patched DSDT I had posted often gave problems so if it's still in the bootpack, remove it. Its sole purpose was to enable the brightness keys but there are other ways to achieve this.

2nd beta available. Build 21A5268h. A few little improvements like the return of GPU info in About This Mac or the refresh button in Safari. Bluetooth still buggy, especially after wake. We'll see what other improvements and new bugs it brings... Straight & easy update with Clover r5133 on my Skylake/HD520 Latitude E7270. Much more more complicated affair with OpenCore v0.7.0 on my Haswell/HD4400 Satellite Pro R50-B. From the 3rd reboot of the temp installation partition, laptop goes into a boot loop. On rebooting the original Monterey partition, system went through "xx minutes remaining", hinting the update was actually going through but, on reaching the Monterey desktop, back to beta1.

There would be so much to. say about your Catalina setup (especially the set of add-on kexts and the Clover config!) but, at least, you correctly used USBInjectAll kext + SSDT-UIAC table. These defined the USB ports of your E6440 laptops. You also used a patched DSDT in which specific power settings for your EH01 & EH02 USB2.0 controllers + XHC USB3.0 controller were also defined in dedicated _DSM methods: "AAPL,current-available", 0x0834, "AAPL,current-extra", 0x0898, "AAPL,current-extra-in-sleep", 0x0640, "AAPL,device-internal", 0x02, "AAPL,max-port-current-in-sleep", 0x0834 For Big Sur, you made a few additional mistakes: you did not use your previous patched DSDT -ok, why not?- and that would probably be Ok had you not made the choice of injecting SSDT-EC-USBX table (which is for Skylake & later systems) AND SSDT-EC table (which is for Broadwell and earlier systems). The trouble is that SSDT-EC-USBX injects the following power settings for USB ports: "kUSBSleepPowerSupply", 0x13EC, "kUSBSleepPortCurrentLimit", 0x0834, "kUSBWakePowerSupply", 0x13EC, "kUSBWakePortCurrentLimit", 0x0834 which are totally different settings the what you injected before. I would recommend you start by removing SSDT-EC-USBX table and all references to it in your OC config. I'd bet square prunes that your USB ports will work much better afterwards and that you'll no longer have power-related problems with your USB keys/storage devices. In addition, given that you've generated your USBMap kext, I'm not sure you still need the SSDT-UIAC table. Check that out but to me, it's either USBInjectAll kext + SSDT-UIAC table or USBMap kext (as it were with Hackintool-generated USBPorts kext).

Had a quick look at your posted EFI. your Kexts set is quite a mess with all sorts of kexts for LAN (no less than 8!). You would really need to sanitise this. Start by identifying your hardware. you said your were using patched UHD530 graphics for iMac17,1, yet your config shows you're using macPro7,1 SMBIOS. Why? iMac17,1 or MacPro7,1 are both compatible with Monterey. As such, no need for -no_compat_check boot-arg though it does no harm of course, just prevents macOS OTA update. you use a single patched SSDT table from Olarilla to patch ACPI; never seen that one before so can't really comment nor say if all is applicable to your own platform, it's not very common.