Hervé

You're using an old Clover setup with old kexts and some incorrect settings, though none that would normally prevent proper macOS installation. Refresh all kexts to their latest versions.

follow the kextcache command with: sudo kcditto

Catalina now, so split to separate thread... I can't understand why your system would load (and crash) Broadcom wireless drivers when you stated you have an Intel wireless card in your Big Sur thread... If you want further assistance, please post a zipped copy of the EFI folder you use. Indicate which boot loader you use and which version.

As long as your i3 is fitted with HD4000 iGPU not HD2500, you're good to go up to current Big Sur. See our FAQ section re: making USB installer without a Mac or a Hack; then look up any existing guide for Ivy Bridge Latitude E5x30 or E6x30 laptops.

macOS normally runs perfectly and totally stable on these Broadwell laptops with all hardware fully supported.

Issues with disks in Media Bay have been discussed in the past, mostly for E6x30 if I recollect properly. Did you check these out? Basically, you need to patch AppleAHCIPort kext. You'll find details on the forum in threads such as these: https://osxlatitude.com/forums/topic/12639-solved-e6430-catalina-new-install-2nd-hdd-in-media-bay-not-readable https://osxlatitude.com/forums/topic/13202-solved-e6330-successful-upgrading-to-catalina-but-major-problems/ Can't say if the patch remains the same in Big Sur but look it up.

I don't usually use GB5 but I just got about the same results as you: 774 & 1703. I'm not sure there is much to say or conclude about those benchmarks. Here's what I obtained with GB4.4.4: Catalina/Clover: 3705, 7500 Big Sur/OpenCore: 3809, 7401 Big Sur/Clover: 3821, 7460 Strange about those graphics glitches you encounter in Mojave and Catalina. Not seen/experienced those. Did you have the Capri framebuffer memory patch in place? Anyway, water under the bridge if you're happy with Big Sur and it's fully functional with Clover

Can't see why the ALC293 audio of the E7450 wouldn't work with layout #11 like it does with ALC293 of the E7250. Try and add CodecCommander kext to work alongside Lilu + AppleALC. Make sure those are the latest versions too. Looking at your OC config, I see that you have arguable ACPI patches in place; for instance, you inject SSDT-EC.aml table (which is good) but you also apply the ACPI patch that renames device ECDV to EC; you should only use the former, not the latter which is now deprecated, especially as you end up with 2 x EC devices, so potentiel conflictual situation, wouldn't you say? Check your other ACPi patches too!

That statement in Dortania's documentation about OpenCore not needing a DSDT is a little confusing and misleading. Possibly something lost in translation as one may say... All bootloaders universally pull/read ACPI tables from BIOS (i.e. firmware). On paper, no Hackintosh bootloader needs a (patched) DSDT. It's just that over the years, ACPI patching developed greatly and what was done years ago through DSDT patching is nowadays done through dedicated SSDT patches that leave the loaded DSDT table more or less untouched. OpenCore came out at a time where such development had reached maturity, having already been vastly experimented and successfully used with Clover. That's for the story (or history)... Focusing back on the E6230, I detailed the patches implemented back in 2018 to A19's original DSDT in my E6230 BIOS settings thread, so you may indeed rework them out through SSDTs or pre-programmed patches of the bootloader. It wouldn't be too difficult, most of them are well known and documented. The only patch missing in that list for the brightness keys and details are available here, in my E7250 guide or here, in my 7490 guide (same patches applied throughout). Jake Lo has also published SSDT alternatives for this brightness keys patch. I was (and remain) too lazy to jump back into that and revisit, especially as Catalina or Big Sur work perfectly with my patched DSDT (even with OpenCore, Yes siree!). No issues and no worry to have on the matter.

Go back to the installer main screen and open up Disk utility to reformat your target partition HFS+, i.e. Mac OS Extended (Journaled). It can't be a new volume on an existing container, that only supports APFS format, it'll have to be a separate partition. Adjust your disk arrangement as required. Please note that, as stated in my guide, I reverted to Clover on what was an existing Big Sur installation made with OpenCore. I'm not 100% certain that you'll actually manage to complete a fresh Big Sur installation with Clover 5128 or r5129 (latter is also Ok to use and I've actually updated from r5128 to r5129). But give it a try, you'll soon find out. You say this is a fresh installation but you've actually downloaded Big Sur and initiated its installation from Mojave, not from a booted USB installer, haven't you?

As always, please post your detailed system's specs or add them in signature. We're in the dark without those! Difficult to make much out of those screenshots. KP seems to happen after "Still waiting for root device" which would suggest USB-related issue. You've placed USBInjectall in your kexts folder but you're not injecting it in your OC config, so... Please note that I'm pretty certain you're injecting the wrong ig-platform-id for your HD530 iGPU, usually it's just 0x19120000. You may refer to this InsanelyMac thread for reference. Injecting iGPU device-id may not be required either but it'll depend on the specifics of your CPU, so no further comment possible in the absence of detailed specs... I also suggest you follow the guidance posted at Dortania for Skylake desktop so that you have an ideally configured system. Good luck.

I'd say the boot loop may result from the known issue that usually only affects systems running in legacy BIOS mode only: missing UUID for temp installation volume in msu-product-url NVRAM parameter or missing parameter, presumably due to non-working NVRAM. It happened to me yesterday when updating my E6230 to Big Sur 11.2 and I messed up at some point with Clover. Various solutions: 1) fix NVRAM 2) manually inject the msu-product-url parameter in an NVRAM.plist file (very long shot; not sure that would work) 3) upgrade the existing Catalina installation following the process detailed here. Best thing to do is verify is that 1) your system runs in UEFI mode and 2) you have working NVRAM. Are you making a completely fresh Big Sur installation having wiped out your disk or or you upgrading your existing Catalina build? NB: can't understand why you downloaded Big Sur from a VM when you have Catalina installed.

Difficult to say much with so little information, including the hardware specs; "normal wifi card" is pretty meaningless... You should be using OpenCore current 0.6.5 version these days. Upgrade your E7450's BIOS to latest version if it does not already run it. Then reset BIOS settings to default and reconfigured along the lines of those I've described here for the E7250. @Jake Lo posted a fully detailed guide here; maybe you could have searched the forum before posting... His guide is based on OC 0.6.3 and 0.6.4 but you can re-use the settings (i.e. ACPI tables + kexts + config file) with OC 0.6.5. Consult Dortania's OpenCore documentation for detailed information on OpenCore. It's a must. Please note that once you initiate the Big Sur installation and system reboots, you must choose the temp "MacOS installer" (or whatever its name might be) partition/volume to complete the process until you're left with only the target partition you chose for Big Sur.

'remove the "boot flat" ? What's that? Or you meant the boot arg brcmfx-driver? Maybe your setup has other or conflicting arrangements somewhere for your wireless card.

MacBookAir7,1 or MacBookAir7,2 should do for a Broadwell laptop, yes; though we usually go for MacBookPro12,1.

Several incorrect, inappropriate and conflicting settings in that Clover setup... For instance, you inject SKL framebuffer layout id 191b000 through properties injection, yet layout 19160000 in Graphics section. In Kernel & Kext Patches, you apply binary patches for the Kaby Lake framebuffer. There are more patched SSDT and ACPI fixes than I've probably ever seen on a mainstream Dell laptop. Mixing and throwing stuff like you did is the worst thing to do. You've ended up with a very messy arrangement you now need to clean up. There are existing guidance and packs posted for this Skylake family of Latitude 5x80.

Hmm, according to Acidanthera's documentation, the associated boot arg behaves as follows: brcmfx-driver=0|1|2|3 enables only one kext for loading, 0 - AirPortBrcmNIC-MFG, 1 - AirPortBrcm4360, 2 - AirPortBrcmNIC, 3 - AirPortBrcm4331, also can be injected via DSDT or Properties → DeviceProperties in bootloader To me the Fixup kext's Brcm4360 injector and its boot arg should therefore be useless on Big Sur given the absence of kexts such as AirPortBrcmNIC-MFG, AirPortBrcm431 and AirPortBrcm4360 in macOS 11.x. However, the IOProbeScore associated with the device ids are different than the vanilla values. Maybe that contributes to fixing the issues (along with disabling ASPM). Big Sur vanilla AirPortBrcmNIC -> IOProbeScore=1400 AirportBrcmFixup -> IOProbeScore 6000 AirportBrcmFixup.AirPortBrcmNIC_Injector -> IOProbeScore 2048 AirportBrcmFixup.AirPortBrcm4360_Injector -> IOProbeScore 1110 Please note that injecting device id 14e4:43a3 is of no use/benefits given that it's the card's own native id. Anyway, I went back on the Toshiba and removed the Catalina patched kext to try the Fixup kext v2.1.2; the card was indeed operational. All I changed in terms of injected properties was the device id which I set to 14e4:43a0; not boot arg used. It also worked if I injected compatibility with pci14e4,43ba. With the card's default device-id (i.e. no device-id injection), macOS boots very slowly (takes several minutes) and I had no wireless thereafter. Carried further testing with the Fixup kext and found that its injectors are not required, something I was expecting. It therefore looks like the IOProbeScore value adjustment is the key here. So, whatever the solution, it involves injecting a kext + the compatible property, i.e.: 1) patched IO80211Catalina kext + compatible=pci14e4,4353 (or pci14e4,4331) or 2) AirportBrcmFixup kext (without its injectors) + compatible=pci14e4,43a0 (or pci14e4,43ba)

Are you sure? I tried this on my Toshiba R50-B and it causes systematic KP and laptop reset (ASPM was still being disabled through property injection in OC). Loading AirportBrcmNIC always was an issue with this card and I don't believe this has changed in Big Sur... But, given that AirportBrcmNIC offers native support for Broadcom chips BCM43602 (14e4:43ba), BCM4350 (14e4:43a3) and BCM4360 (14e4:43a0), I guess there must be differences in terms of handling in the kext's code.

And CodecCommander kext probably useful too.

Follow our BCM4350 guide. Inject the necessary properties + patched kext in your OC config.

It does not look like you followed the Dortania's guide step by step, no... your OC config does refer to any of those ACPI patched tables you've placed in the ACPI folder you've used SSDT-EC-USBX which is for Skylake and later systems, when you should just use SSDT-EC for your Broadwell laptop you've completely missed the Device Properties section, you'll need to inject graphics properties at minimum you inject AppleMCEReporterDisabler.kext which I believe to be unecessary AppleCpuPmCfgLock quirk is for Sandy Bridge and Ivy Bridge platforms so useless for you (but it'll do no harm) you've got stuff in LegacySchema I've never seen before (those mmm entries) you've opted for MacPro7,1 SMBIOS which is totally wrong for your Broadwell laptop You'll never get anywhere without that setup. Dortania provides a complete and correct guidance for Broadwell laptops, why don't you follow it?

I'd say you messed up the 2nd part of the posted instructions. Because when I look into the Precision 7510 HD530 pack available in that guide, there's all the stuff you need and you're missing it all...

It's a very specific OpenCore setup for a particular set of hardware specs. Yours probably don't match so you'll have to adjust the settings.

Like its M200M bigger brother, nVidia Quadro M1000M is Maxwell and unsupported outside Sierra/High Sierra in which it can only be suported with the nVidia Web Driver. It's totally unsupported in Mojave and later macOS versions. Had your Precision 7510 be fitted with the AMD FirePro W5170M alternative, you'd probably be more lucky, but... Meantime, you'll need to enable Optimus in BIOS, disable the nVidia GPU through patched DSDT/SSDT (to preserve battery) and run exclusively on the HD530 GPU of the i5-6300HQ. The EFI you posted contains no patched ACPI table, no add-on kexts and its Clover config refers to an incomplete and incorrect iMac17,1 (i.e. desktop) SMBIOS... This most certainly explains why you're getting much success. You need to go back to the guide you've used (whatever that may be) and probably follow it with better attention.