Hervé

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.

Add CodecCommander to your set of kexts. You should not require those old FakePCIIDxxx kexts; they're all deprecated nowadays. HDMI audio is normally available through AppleALC + iGPU framebuffer patch to set HDMI output port connector to HDMI.

Target macOS release: Big Sur 11.x This is an OpenCore-based installation, completed as an upgrade of an existing Catalina installation as detailed below. Working: full graphics acceleration on GT730 OOB with macOS native driver multi-display (with Lilu + WEG): DVI & HDMI OOB, VGA with NVCAP value 050000000000FFFFFFFF00000000000E00000000 audio, including HDMI, microphone input and headset output (with AppleALC + all layouts or VoodooHDA) FastEthernet LAN connection (with 82566MM or AppleIntelE1000 kext, patched if necessary for PCI id 8086:10c0) 19in-1 card reader OOB CD/DVD RW drive OOB front and rear USB ports (OOB) partial CPU power management with OpenCore, legacy Core2Duo platform oblige (LFM + HFM only since OpenCore does not generate C States/P States) sleep (Energy Saver settings, Apple menu, PWR button) & wake (PWR button, USB keyboard/mouse) USB or Wireless keyboard and mouse (with IOHIDFamily's isSingleUser function OpenCore patch) Not working: N/A Not tested: N/A GeekBench v4.4.4 (64bit) gives a 3900+ rating: This old desktop PC only operates in legacy BIOS mode, not UEFI. This is a problem for installing Big Sur from scratch with a USB installer because, in legacy BIOS mode, OpenCore does not appear capable to dynamically obtain the volume UUID of the temporary MacOS installer partition/volume (created during the installation process) and properly define an essential parameter called msu-product-url. This causes the installation process to fail proper execution and, instead, triggers computer reset + continuous boot loop of the temporary volume, the installation therefore never reaching completion. A workaround to this problem is to install Big Sur as an upgrade of an existing Catalina installation. When installing Big Sur as an upgrade of Catalina, the temp installation will be created on the existing Catalina Data volume whose UUID can be readily obtained and passed through NVRAM parameter msu-product-url to the installation process. This was described in this thread by pac-man at InsanelyMac, credits to him. Basically, the UUID of the Catalina Data volume is obtained through the diskutil line command and the resulting value is used to create a fully-defined path for the temp installation volume that is stored in NVRAM parameter msu-product-url. This NVRAM parameter is essential to complete the installation process. Please note that installing Big Sur on this old desktop PC takes a substantial amount time to complete (even on a SATA SSD) so set aside a few hours... 1) Preparation OpenCore needs to be setup in legacy mode to boot the Vostro 200 computer, lack of UEFI BIOS mode oblige. This is well documented on the Dortania OpenCore GitHub repo which I invite everyone to refer to. the following OC 0.6.5 EFI folder may be used on the existing disk's EFI partition or on a USB key as bootloader to reboot the system during the Big Sur installation phases, then boot Big Sur once it has been fully installed: OC_0-6-5_EFI_Vostro200_BigSur.zip key elements to note in that config are: the IOHIDFamily kext patch applied to the _isSingleUser function; it's required to obtain working USB keyboard & mouse, they don't work without the patch. This is detailed in the Dortania's documentation. additional msu-product-url parameter added under NVRAM->7C436110-AB2A-4BBB-A880-FE41995C9F82 UUID UUID as per pac-man's thread at InsanelyMac. 2) 11.x installation from an existing Catalina installation (can be a Clover-based one), download a copy of Big Sur installation package. ensure you have emulated NVRAM working and define msu-product-url parameter as follows through Terminal: sudo nvram msu-product-url="msu-product-url://$(diskutil info /System/Volumes/Data | grep "Volume UUID" | awk '{print $3}')/macOS%2520Install%2520Data" run the Big Sur installation package and proceed with installation on your Catalina disk/volume/partition as offered by the installer app. the Big Sur files will be copied over and this may take a lot of time (could be anything from 40mins to 1hr). on 1st and all subsequent reboots, make sure to use OpenCore and the EFI folder/config setup offered above. the whole installation process will normally require 3 or 4 reboots to complete and this make take anything like 1hr. 3) Post-installation tuning once the Big Sur installation has completed and Big Sur first boots, complete the initial configuration tuning. Here too, this may take an unusual and very long time; just hang in there. once at the Big Sur desktop, mount your disk's EFI partition and copy the OpenCore EFI folder as necessary/appropriate in order to boot Big Sur via OpenCore. proceed with usual macOS fine-tuning (wireless setup, hibernation disabling, refresh of serial numbers, etc.). NB: Contrary to pac-man's suggestion to remove the msu-product-url from NVRAM after installation, I strongly recommended to retain it because it'll be required for each Big Sur update. Edit #1: ------- For a fresh installation of Big Sur, proceed as follows to obtain the UUID value to inject in NVRAM as msu-product-url: Boot your Big Sur installer and initiate installation or launch the Big Sur installation package from an existing macOS build. At 1st reboot, boot the Big Sur installer again and type the following in Terminal: diskutil info /Volumes/<target disk or partition name"> | grep "Volume UUID" | awk '{print $3}' Make a note of the returned UUID Edit your OC config and add the following parameter in NVRAM section against UUID 7C436110-AB2A-4BBB-A880-FE41995C9F82: msu-product-url <obtained UUID>/macOS%2520Install%2520Data String Reboot and Reset NVRAM before booting your temp Macintosh HD partition For instance, if installing Big Sur on a disk or partition called "macOS_BigSur_11": In Terminal, type: diskutil info /Volumes/macOS_BigSur_11 | grep "Volume UUOD" | awk '{print $3}' say it returns UUID value 4B9B8623-B1B4-3DC8-841A-D57C824B0067. set key msu-product-url with value 4B9B8623-B1B4-3DC8-841A-D57C824B0067/macOS%2520Install%2520Data and type String in the OC config. reboot, reset NVRAM and boot your temp installation partition to complete the installation.

Afaik, no need to patch framebuffer memory (fbmem) or stolen memory (stolenmem) for Haswell HD4x00 graphics. Only cursor memory (cursormem) is to be patched to 9MB if glitches are experienced.

If you're using OpenCore, just follow the detailed guidance posted at Dortania. It works perfectly. Win10 can be on an existing partition before you install macOS or be installed afterwards. It makes no difference and the process remains the same. Bear in mind that OpenCore settings apply to all OS you may boot so don't be surprised of potential side effects in Windows, like some unknown devices in Device Manager. It's usually without impact however. No such side effects with Clover.

You can start by identifying your wireless card's model then checking its likely compatibility in our FAQ + Wireless forum sections... And guys, please post your system's specs in signature!