Hervé

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!

HDMI works OOB out of the E6230. HDMI connector patch required for HDMI audio. The laptop usually drives/controls the output resolution on cable connection, at least on the 3 x TVs + the few monitors I've hooked my E6230 to. Could be a damaged/unsuitable cable, bad connection or a damaged HDMI port on either side. Start by removing video mirroring on the Hack to avoid potential resolution-related issue on the TV screen. I recommend using Display Menu app for immediate access off the Finder's bar. https://osxlatitude.com/forums/topic/2366-finders-bar-display-tool/?tab=comments#comment-17779 Rest assured it's not a Hackintosh or macOS issue.

With MBP11,1 (which is the desired target), use the -no_compat_check boot arg depending on the version of Big Sur you try to install. I've cleaned up your OC config. Try it out: config.plist.zip

Quite surprising and strange that your OS version is stated as unknown... Are you using a full vanilla installation or a distro of some sort? I have to say that I strongly suspect latter rather than former. And what are these boot args? chunklist-security-epoch=0 -chunklist-no-rev2-dev Did you disable hibernation? If not, expect trouble with sleep and wake, especially if you kept settings such as Power Nap or Wake on Network Access enabled. Please consult out FAQ section regarding Sleep/Wake settings.

There are probably a few things to review given that your config looks like a mix of Dortania's settings + stuff carried over from a previous Catalina setup. For instance: SSDT-EC (which injects a separate EC device), yet your rename device ECDV to EC in your config file. You may also want to revisit those ACPI patches you appear to have carried over in relation to HPET, RTC and TIMR.

No double post on the forum please, especially if you double post for support matters in the Guides section! I don't know what you mean but "error" given that you have no driver installed for your LAN card... According to your Aida64 report, it's a Realtek RTL8139/810x Fast Ethernet Adapter with PCI id 10ec:8136 so clearly a Realtek RTL810x card. It's not natively supported but it may work with this old kext that does cater for 10ec:8136: AppleRTL8169Ethernet.kext.zip Possible alternatives: the RTL8139 driver mentioned here with a patch to add id 8136 or change id 8139 to 8136 (but chance that it'll work is low) Rehabman's oldish RTL8169 kext available here (will probably need same patching too and agin, low chance that it'll work) Failing that, Google for an OS X/macOS driver for 10ec:8136. Good luck. NB: you appear to have a Haswell/HD4x00 laptop so you can remove AppleCpuPmCfgLock kernel quirk, it applies to Sandy Bridge/Ivy Bridge platforms. Also, unless your laptop is fitted with quad-core CPU -but you've not bothered to post your system specs-, you should use MBA6,2 or MBP11,1 SMBIOS.

Post a zipped copy of your EFI folder so that we check your settings.

Do you use a valid payable subscription or one of those free offers with the purchase of an Apple device? If latter, could be the reason...

Last update: 21 Jan 2021 Here are BIOS settings that are known to work on the Satellite Pro R50-B-116 (4th gen. Haswell CPU with Intel HD4400 graphics) under Big Sur. These settings were tested and verified with BIOS v1.70. Security . BIOS Password: * User: Not Registered or set * Supervisor: Not Registered or set . HDD/SSD Password: * Mode: Master+User or User Only * User: Not Registered or set * Master: Not Registered or set . Secure Boot: Disabled . TPM: Enabled or Disabled . Hide TPM: Yes or No Power Management . Wake-up on LAN = Disabled . Wake-up on LAN on Battery = Disabled . Wake-up on Keyboard = Enabled . Critical Battery Wake-up: Enabled . Panel Open - Power On: Enabled to support wake on opening the lid or Disabled . Power on by AC: Enabled to support wake on plugging AC or Disabled . Dynamic CPU Frequency Mode: Dynamic Switch . Core Multi-Processing: Enabled . Intel Turbo Boost Technology: Enabled . Intel Display Power Management: Enabled . SATA Interface setting: Performance BIOS Power Management . Battery Save Mode: Full Power Advanced . Execute-Disable Bit Capability: Available . Virtualization Technology: Disabled or Enabled . Beep Sound: Medium or any other value . USB Power in Off State: Enabled . USB Legacy Emulation: Enabled System Configuration . Built-in LAN: Enabled . Wireless LAN = Enabled . Auto Wireless LAN RF Switching: Disabled . SD Host Controller: Enabled . Memory Performance Mode: Enabled . Boot Mode: UEFI Boot (may be set to CSM (i.e. legacy) for Chameleon/Enoch or Clover and older OS X/macOS versions) . Power On Display: Auto-Selected . Boot Up NumLock Status: ON . Function Keys Mode: Standard F1-F12 mode

No difference between OpenCore and Clover in the respect of audio, keyboard/trackpad or graphics settings. If you follow the Dortania's guidance, you'll clearly see it. No further hint to provide until you post your config.

You're using Lilu v1.5.0 and I read it could cause issues. Try with the previous version.