Hervé

A little update further to recent discussions at InsanelyMac on the matter of SIP and macOS updates not being offered in Big Sur. 1st of all, it should be pointed out that Big Sur introduced a new 12th flag for unauthenticated root updating SIP as follows: nibble: #3 | #2 | #1 nibble bits: 4 3 2 1 | 4 3 2 1 | 4 3 2 1 bits: 12 11 10 9 | 8 7 6 5 | 4 3 2 1 - - - - - - - - - - - - | | | | | | | | | | | | | | | | | | | | | | | | / | | | | | | | | | | | Unauth. Root / | | | | | | | | | | Policy Over. / | | | | | | | | | Kext app. / | | | | | | | | Recov. OS / | | | | | | \ Device Config. / | | | | \ Kext Sig. NVRAM Prot. / | | \ FS Prot. DTrace Rest. / \ Task for PID Apple Int. Kernel Debug. where: Bit #1 = Allow untrusted kexts Bit #2 = Allow unrestricted FileSystem Bit #3 = Allow task for PID Bit #4 = Allow kernel debugger Bit #5 = Allow Apple internal Bit #6 = Allow unrestricted DTrace Bit #7 = Allow unrestricted NVRAM Bit #8 = Allow device configuration Bit #9 = Allow any recovery OS Bit #10 = Allow unapproved kexts Bit #11 = Allow executable policy override Bit #12 = Allow unauthenticated root Source: csr.h (in bsd/sys folder) of Big Sur 11's published XNU source code at https://opensource.apple.com/ Initially, back in the days of El Capitan, disabling SIP was mostly required to load add-on kexts, especially when these were cached. With Big Sur, this is not really required with add-on kexts being injected from Clover and/or OpenCore and SIP can usually remain enabled with no particular side effects/impacts. For those who still want to disable SIP -for instance if booting Big Sur with Clover and using cached kexts- it's important not to set all flags to 1 as this blocks/prevents Big Sur updates from being offered to the Hackintosh. This is typically what happens to people who use csr-active-config 0xFFF as recommended in Dortania's OpenCore documentation. Such a value results in the following SIP status: admin@E6230 ~ % nvram -p | grep csr csr-active-config %ff%0f%00%00 admin@E6230 ~ % admin@E6230 ~ % csrutil status System Integrity Protection status: unknown (Custom Configuration). Configuration: Apple Internal: enabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled BaseSystem Verification: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state. However, Apple Internal flag needs to be kept disabled (i.e. bit #5 unset) for Big Sur updates to be offered. Alternative csr-active-config values such as 0x67 / 0x267 / 0x867 / 0xA67 / 0xFEF are therefore recommended instead of 0xFFF. Example with 0xFEF: admin@E6230 ~ % nvram -p | grep csr csr-active-config %ef%0f%00%00 admin@E6230 ~ % admin@E6230 ~ % csrutil status System Integrity Protection status: unknown (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled BaseSystem Verification: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Your OC config is incorrect in several instances: you opted for XCPM on this Ivy Bridge laptop and that no longer works (well) afaik: Remove the AppleXcpmCgfLock quirk from the Kernel section only to keep the AppleCpuPmCfgLock quirk Remove the SSDT-PLUG.aml table from your OpenCore EFI/ACPI folder and replace it by your CPU-specific power management SSDT table (that you can rename SSDT-PM if you wish) generated with good old generator script from Pike R Alpha. It's the best solution for Sandy and Ivy Bridge laptops. Then, in your config's ACPI section, replace the defunct reference to SSDT-PLUG by the name of your generated CPU PM SSDT. In your OC config's Device Properties section, you need to add the following properties against your iGPU to reduce framebuffer memory size from 16MB to 8MB (or you'll get glitches): framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA Not sure you need SSDT-HPET table. Not sure you need -wegnoegpu boot arg in NVRAM settings. Does your E5430 have a dGPU that needs disabling? alcid=1 seems incorrect to me if, as I suspect, your E5430 is fitted with same IDT audio codec as the E6x30, in which case the correct layout id is 12 (0x0C). you did not say which macOS (or OS X) version you're trying to install but you've set csr-active-config NVRAM parameter to 3. This was fine for older OS versions but more recent versions would typically require different values. It really depends on what you want to disable in SIP Check the OC pack I had posted in my E6230 Big Sur guide and build from it.

You did adjust the relevant PrefPanes for Dock effects and Hot corners, right?

Better replace the card with a compatible Broadcom model. Your Wifi 6 will be kind of wasted with the current limitations in macOS.

What about it? Do you see any reply to that thread which dates back to Big Sur beta? Of course Sandy Bridge CPUs/platforms can run Big Sur... with a compatible graphics card! As I said: no support for HD3000 graphics in Big Sur. If you need further confirmation, read this: https://forums.macrumors.com/threads/macos-11-big-sur-on-unsupported-macs-thread.2242172/ If you don't believe me, go ahead and knock yourself out at it.

There's no support whatsoever for HD3000 graphics in Big Sur. No patcher this time. Hence why you didn't and won't find any guide on the matter. No point trying to run Big Sur on this old laptop.

You only need to declare the kext under the Kernel section. The device property injection is of no operational purpose other than the cosmetic side of things and you sure do not need to declare it compatible with... itself! Try: disabling SIP loading the kext manually v1.3.0 since it's supposed to support 160MHz cards

SIP is not disabled from Terminal (unless you boot into Recovery) but with a boot/NVRAM variable that you set accordingly. Again, see our FAQ section.

@mosfet51 Why don't you just consult the support documentation available on Dell's web site? It's always included user manuals and/or maintenance guides explaining how to disassemble Latitude laptops in order upgrade or change components such as batteries, RAM, disks, batteries, etc. In the case of the 7400, I expect we'll be talking about M.2 SATA or NVME SSDs, i.e. the same as with the 7490 that the 7400 replaced. Look it up. Of course, you'll be able to replace your unsupported current NVME model by a supported one.

Which version of the kext are you using? Try this one (v2.7.2): CodecCommander.kext.zip Alternatively, grab the copy I had provided in the pack of my E6220 (Sandy Bridge) High Sierra guide. It's probably an older version.

Make sure you have NVRAM working properly. Brightness level can get stored there in order to be retained at next reboot. Same for audio volume level and things like that.

All attachments are present and available. I've just checked.

Clover config looks alright to me, except the choice of MacBook8,1 SMBIOS as opposed to MacBookPro8,1 for this older Sandy Bridge laptop. There's an extensive thread about the N5110 at InsanelyMac. Did you check it?

Check your boot-args once in macOS: nvram -p | grep boot-args Delete the existing boot-args as/if appropriate.

If you've already generated your CPU-specific power management SSDT, all you need to do is place/copy the .aml file to OC's EFI/ACPI folder and call it/declare it in the ACPI section of your OC config. You may then use apps such HWMonitor (provided with all recent/latest versions of FakeSMC) to check your CPU behaviour; alternatively, download and install Intel's own tool called Power Gadget. Re: audio, use AppleALC kext (it's a PlugIn of Lilu so it goes with it) and check the kext's wiki to get the list of layouts you may use for that codec.

You appear to have a Micron 2200s SSD in that Latitude 7400. Those are known to be troublesome with macOS and you should consider replacing it. https://dortania.github.io/Anti-Hackintosh-Buyers-Guide/Storage.html

No, CPU model makes no difference to the OpenCore setup, except for graphics and SMBIOS settings if iGPUs differ. Post your specs in signature, you'll make everyone's life easier.

Check that your iGPU's 4K capabilities match that of the TV, especially the frequency (eg: 4K@24/30/60Hz.). If they don't match, you won't get 4K output. HDMI cable also needs to be of the right specs. And then, you must use the right config file settings too.

Please note that HDMI audio for Haswell iGPU normally requires: renaming of ACPI device B0D3 to HDAU injecting hda-gfx property to ACPI devices HDEF/HDA/IGPU, set to "onboard-1" injecting HDMI connector type 00080000 to HDMI output port/connector (usually con1) injection pipe value 0x12 to HDMI connector to 12 (or system will crash on HDMI cable plugging/unplugging) Check what you have in IOReg to begin with and adjust your bootloader config accordingly afterwards.

Yes that's the adapter. We've got a fully detailed thread about this in the R&D->Wifi section. Look it up. If you want to verify the model of wireless card in your E6230, it could be simpler: losen the sole screw that holds the bottom cover and slide it out. You'll see the card in the corner of the laptop; you can't miss it!

Intel Ultimate-N 6300 is meant to be supported by the recently developed Intel wireless tools but I still recommend you opt for a fully supported Broadcom card or a real Apple Card with a mini-PCIe adapter (eg: BCM94360CD). That's what I use in my E62x0 laptops and never regretted it for a second. You get full and native Wireless + Bluetooth services, just like on a real Mac and never need to worry about it again.

Yes, of course it is; you jut need the correct settings on your bootloader config.

No need to switch to the other bootpack. As stated in the guides you simply need to generate your CPU-specific power management SSDT. Granted it may not have been explained well-enough, something I've now addressed. If you use the SSDTs for I provided for the CPUs stated in my guides, you'll indeed encounter issues. Anyway, assuming you're unable to generate your own SSDT, here it is. Just unzip and place inside your Clover's ACPI/patched folder. SSDT-PM_i5-3320M.aml.zip

Obviously just a typo that has now been attended for; thanks for pointing this out. We won't be able to make anything out of that KP screenshot unfortunately. Things that could be wrong, open thoughts really: dodgy RAM module or slot unsupported wireless card; please specify non-vanilla installation You should also post your specs in signature like most of us do.

All the info and data provided in the Mojave guide were accurate at the time of writing and remains so to date. Of course, numerous newer versions of Clover and numerous new versions of some of the kexts of the provided bootpack were released since. Whether you update those is entirely up to you but rest-assured that the provided pack will work perfectly with the provided Clover version for all versions of Mojave. Check your BIOS settings and adjust as per the recommended settings in case something differs.