[Guide] Dell Latitude E6410 (Nvidia) Hackintosh: Big Sur, Monterey, Ventura & Sonoma macOS installations with Open Core Legacy Patching

[deeveedee]

@Stefanalmare I didn't think OCLP supported Ventura on MacBookPro6,2.  As of 0.5.1, the status was "still working on it."  

 

IORegistryExplorer AGP (Big Sur and Monterey)

Spoiler

 

[deeveedee]

Xcode 14.1 update completed without any issues on this HackBookPro6,2 running Monterey 12.6.1.

[Stefanalmare]

2 hours ago, deeveedee said:

@Stefanalmare I didn't think OCLP supported Ventura on MacBookPro6,2.  As of 0.5.1, the status was "still working on it."  

 

IORegistryExplorer AGP (Big Sur and Monterey)

  Hide contents

 

You don't have a real Mac. You just need GPU patch. I'm sure Ventura will run well on your laptop. Only USB 1,1 will not, if you have...........

[deeveedee]

Ok. I think I'll wait for a more mature version of Ventura and OCLP.  Sleep and Wake work perfectly in Monterey, so I can avoid the Monterey boot issue by closing and opening the lid instead of shutting down.  Thanks again for your help.

[deeveedee]

I have updated my posted High Sierra EFI and Big Sur EFI with OC0.8.6 [Release].  My posted EFIs are the current EFIs that I am using to boot High Sierra and Big Sur and Monterey.  High Sierra boots and runs without issues using OC0.8.6-EFI-HighSierra-R01.  Big Sur boots and runs without issues using OC0.8.6-EFI-BigSur-R01.  Monterey has intermittent boot issues with OC0.8.6-EFI-BigSur-R01.  Once booted, Monterey runs well.

[deeveedee]

As @Stefanalmare indicates here, UEFI > Quirks > RequestBootVarRouting should be disabled when using OpenDuet (which is used by this HackBookPro6,2 implementation for legacy booting).  I have experimented with RequestBootVarRouting enabled and disabled and have not observed any difference in behavior (it is enabled in my currently posted EFIs).  I will be disabling this quirk in my next posted versions of my EFIs.

[deeveedee]

The latest nightly build of OCLP 0.5.2 removes the -disable_sidecar_mac boot-arg for MBP6,x. I don't know if this was removed in an earlier OCLP version, but it is a change from when I first started looking at the EFI generated by OCLP.  I will be removing -disable_sidecar_mac from my boot-args.

 

EDIT: OCLP no longer injects kext BigSurSDXC.kext for MBP6,x.  I don't have this kext enabled in my config.plist since I haven't found it necessary for my hack, but I plan to completely remove BigSurSDXC.kext from OC/kexts and from the config.plist.

 

EDIT2: Along with other elements from the OCLP-generated EFI, I copied SSDT-CPBG (and the associated config.plist ACPI > Add entry).  After further review, SSDT-CPBG was required on real MBP6,2 to disable the dummy Device CPBG to prevent kernel panic on early versions of Big Sur.  This is not needed on this hack.  I will be removing SSDT-CPBG from my next posted EFI.

 

EDIT3: I will be removing SSDT-HDEF and SSDT-HDAU (along with config.plist entries) since these are no longer necessary when using AppleALC.

86

EDIT4: I have repurposed SSDT-HDAU to set HDAU.class-code = <FF FF FF FF>.  As per Vit9696, this causes AppleALC and AppleHDA to ignore the device (thus avoiding the boot delay).

Edited January 29, 2023 by deeveedee

[deeveedee]

The intermittent Monterey boot issue is solved by replacing VirtualSMC.kext with FakeSMC.kext or add boot-arg vsmcgen=1 for VirtualSMC.  Leaving the post below for historical purposes.

 

=================================

 

I have an update on Monterey booting after further testing.  Monterey is more likely to boot without issues from a "cold boot" (laptop is powered on from a powered-off state) than from a "warm boot" (laptop is rebooted from a previously running Monterey session without a complete shutdown).

 

At this time, the two ways I have found to improve Monterey booting:

1. Disable CPU TurboBoost in BIOS: with TurboBoost disabled, Monterey always boots without issues
2. Power on laptop from a powered-off state: Monterey is more likely to boot reliably from a powered-off state when TurboBoost is enabled in BIOS.  Monterey boot may still abort and restart early in the boot cycle, but this Monterey boot issue is much less likely when powered-on from a powered-off state.

Big Sur continues to boot reliably without any issues.  Once booted, both Big Sur and Monterey run well without major issues.  In Big Sur, BlueTooth and Webcam work perfectly.  In Monterey, BlueTooth does not work and PhotoBooth opens to a black screen (no video).

 

EDIT: As shown in the attached screenshots

• In Big Sur (working WebCam), IORegistryExplorer shows VDCAssistant attached to Integrated Webcam@0
• In Monterey (non-working WebCam), IORegistry shows UVCAssistant attached to Integrated Webcam@0

 

In Monterey, when PhotoBooth is opened, the WebCam's blue LED illuminates (indicating active WebCam), but the PhotoBooth screen is black (no video).

 

BigSur Webcam as viewed in IORegistry Explorer (VDCAssistant)

 

Monterey Webcam as viewed in IORegistry Explorer (UVCAssistant)

 

 

Edited March 24, 2023 by deeveedee

[deeveedee]

I upgraded this old Dell Latitude E6410 to Ventura 13.0.1. I'm amazed!  Ventura runs better on this old hack than Monterey.  I have rebooted Ventura a few times and have not experienced the boot issue that I see with Monterey.  @Stefanalmare - you were right!  Ventura does work well!  I'm using the same EFI that I posted here for Big Sur and Monterey.

 

About this Mac: Ventura 13.0.1

Spoiler

 

EDIT: As is the case with Monterey, the webcam and bluetooth are not yet working in Ventura.

 

EDIT2: While it's nice to have the "bragging rights" and to be able to say that I'm able to boot and run Monterey and Ventura on a 2010 Dell laptop, by far the best user experience is with Big Sur.  Big Sur is more responsive, has working bluetooth and webcam and still runs current apps.  The only current app that I'd want to run but can't with Big Sur is Xcode 14.

 

EDIT3: It appears that Nvidia graphics acceleration is still a work-in-progress for OCLP / Ventura.  I applied Post-install patches to Ventura using OCLP 0.5.1 [RELEASE] and OCLP 0.5.2 [DEVELOPMENT].  I am unable to open Microsoft Word in Ventura.  Still, just the fact that Ventura installs, boots flawlessly and runs is significant progress.  OCLP status does report that work on MBP6,2 is on-going.

Edited November 13, 2022 by deeveedee

[Stefanalmare]

"EDIT: As is the case with Monterey, the webcam and bluetooth are not yet working in Ventura."

 

Congrats! For sure bluetooth works with another SMBIOS.

[deeveedee]

As I reported here, this Dell Latitude E6410 is extremely picky about SSDs.  When I was first migrating my original CLOVER-based solution to this OC-based solution, I had a lot of problems (cause unknown to me at the time) that were caused by the SSDs. After I determined that certain SSDs were problematic, my migration proceeded much more smoothly.   I have reported my SSD test results here.

 

EDIT: I have tried setting Kernel > Quirks > SetApfsTrimTimeout = 0 (default -1) and this did not help.  The only working solution that I have found for fixing slow boot on this HackBookPro6,2 is to change SSDs.

Edited November 18, 2022 by deeveedee

[deeveedee]

When Norton 360 is installed on this hack running Big Sur (maybe other versions of macOS, but I didn't test), macOS does not shutdown.  Work-around is to disable Norton 360 idle scans.  EDIT: I have also needed to disable Automatic Scans to guarantee a smooth shutdown.  It appears that if Norton is performing a scan at the time that I shutdown, shutdown fails and my rig freezes with a blank background screen (cursor still moves).

 

Leaving this for historical purposes, but changing full disk access permissions did not resolve shutdown with Norton Idle Scan enabled.

EDIT: I am testing a theory after discovering that Norton System Extension was not granted full disk access in System Preferences > Security & Privacy.  I have granted full disk access to Norton System Extension and have been able to shutdown without problems when Norton Idle Scan is enabled.  Still testing before drawing a final conclusion.

 

Full Disk Access for Norton System Extension

Spoiler

 

Edited November 21, 2022 by deeveedee

[deeveedee]

I'm booting Big Sur, Monterey and Ventura on this HackBookPro6,2.  I wanted to modify the macOS names that appear in OC's boot picker, so I edited the following files:

 

• System/Volumes/Preboot/uuid/System/Library/CoreServices/.contentDetails
• System/Volumes/Preboot/uuid/System/Library/CoreServices/.disk_label.contentDetails

where uuid is different for each installed macOS.  I edited both .contentsDetails and .disk_label.contentDetails because I found in one case that changing .disk_label.contentDetails did not change the name in OC boot picker.  I didn't spend much time on this, so it's possible that I only needed to edit one of the two files.

[deeveedee]

OCLP 0.5.2 has been officially released.  The MBP6,2 EFI generated by OCLP 0.5.2 has the following changes from that of previous OCLP releases.  I am currently running with these EFI changes:

• Upgrade RestrictEvents.kext from 1.0.8 -> 1.0.9
• Remove USB1.1 kernel adds from config.plist
• Change Lilu.kext MinKernel to 8.0.0 (from 12.0.0)
• Changed AppleALC.kext MinKernel to 18.0.0 (from 12.0.0)
• Changed AirportBrcmFixup.kext/Contents/PlugIns/AirPortBrcmNIC_Injector.kext MinKernel to 20.0.0
• Remove kernel patch Reroute kern.hv_vmm_present patch (1)
• Remove kernel patch Reroute kern.hv_vmm_present patch (2)
• Remove kernel patch Reroute kern.hv_vmm_present patch (2) Ventura
• Remove NVRAM > 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14 > OC_BID
• Remove Booter patch Reroute HW_BID to OC_BID (this was already disabled in my config.plist)
• Add Booter > Patch > Skip Board ID check

Edited November 23, 2022 by deeveedee

[deeveedee]

EDIT: The intermittent Monterey boot issue and the -v boot issue are both solved by replacing VirtualSMC.kext with FakeSMC.kext or add boot-arg vsmcgen=1 for VirtualSMC.  With FakeSMC.kext, macOS boots without the -v boot-arg.

 

==============================

 

While testing my latest EFI with changes here in my previous post, I discovered that Big Sur fails to boot when verbose boot is disabled (-v is removed from boot-args).  This boot behavior (without -v) is different from the Monterey boot failure that I have been observing, in that with the Big Sur boot failure, the Apple logo appears and the progress bar is displayed, but boot is frozen with no progress.  With the Monterey boot failure, the laptop automatically reboots until Monterey boots successfully. With this Big Sur boot failure, boot is frozen and I can recover only by pressing and holding the power button to force shutdown.   If I restore -v to the boot args, Big Sur boots without issues.  If I remove -v and disable CPU TurboBoost in BIOS (the fix for the Monterey boot problem), Big Sur still does not boot.

 

I'm not certain, but I believe this suggests that there is a timing problem that is "fixed" with the delays introduced by verbose logging.

 

Has anyone observed this behavior (where booting occurs normally only with the -v boot-arg) and if so, how did you debug the problem?  I am keeping the -v boot-arg for now so that Big Sur continues to boot without issues.

Edited March 24, 2023 by deeveedee

[deeveedee]

EDIT: I'm leaving this post below for historical purposes, but after re-running OCLP 0.5.2 to create a MBP6,2 EFI, the kernel patches referenced below now appear in the OCLP-generated config.plist. I do not understand why these did not appear the first time I ran OCLP 0.5.2.

 

=================================================

 

After I removed the three kernel patches below from my config.plist, Ventura stopped appearing as an update when I booted Monterey:

• Remove kernel patch Reroute kern.hv_vmm_present patch (1)
• Remove kernel patch Reroute kern.hv_vmm_present patch (2)
• Remove kernel patch Reroute kern.hv_vmm_present patch (2) Ventura

I removed these kernel patches here, because the MBP6,2 EFI generated by OCLP 0.5.2 no longer includes these kernel patches. 

 

I'm certainly not an OCLP expert, but it appears to me that these OCLP changes have broken macOS updates in Monterey for the MBP6,2.

 

I have restored these three kernel patches to my config.plist (the 3rd Ventura patch is not applicable to Monterey) and the Ventura update is now available again.

Edited November 23, 2022 by deeveedee

[deeveedee]

I changed my hack's CPU description so that "About This Mac" shows that my hack is a Dell Latitude E6410.

 

About This Hack: Monterey 12.6.1

Spoiler

 

If you want to change the CPU description of your hack, you can follow my instructions here.  Note that instructions for Ventura are different.

[deeveedee]

The intermittent Monterey boot issue and the -v boot issue are solved by replacing VirtualSMC.kext with FakeSMC.kext or add boot-arg vsmcgen=1 for VirtualSMC.  Leaving post below for historical purposes.

 

==========================================

 

Updated Status: For about a week now, I have been using my Dell Latitude E6410 with CPU TurboBoost disabled in BIOS.  I have had NO problems with booting Monterey (or Big Sur or Ventura).  Disabling CPU TurboBoost completely resolves the Monterey boot issue.  I don't have the boot issue with TurboBoost when booting Big Sur or Ventura.  OCLP0.5.2 has still not completely patched Nvidia Graphics, as graphics acceleration is not fully working yet in Ventura.  It will be interesting to see if the boot problem starts happening in Ventura when Nvidia graphics patching for Ventura is complete.

 

EDIT: This OCLP Issue suggests that Big Sur 11.2 is the currently tested macOS version for the MacBookPro6,2.  That explains why I'm still seeing issues with Monterey.  OCLP support for Ventura is still in development.  Note that this issue references the PhotoBooth black screen in Monterey (solution is ot downgrade to Big Sur).

Edited March 24, 2023 by deeveedee

[deeveedee]

Since OCLP adds RestrictEvents.kext, I have enabled RestrictEvents.kext in my BigSur EFI. With RestrictEvents.kext, I no longer need EFICheckDisabler.kext, so I have removed EFICheckDisabler.kext from my BigSur EFI.  This change will be included in the next EFI that I post for Big Sur.

 

Spoiler

 

[deeveedee]

My HackBookPro6,2 EFI includes a redefinition of RTC._CRS to change RTC memory length from 8 to 2 and to remove IRQNoFlags.  My SSDT includes an External declaration of the original (renamed) RTC.XCRS as UnknownObj as shown below.  I don't know how to explicitly declare a ResourceTemplate object for External reference.  Does anyone know the proper External declaration type for a ResourceTemplate object (e.g., something like ResTmpObj)?

 

External declaration of ResourceTemplate object: What should I use instead of UnknownObj?

Spoiler

 

Edited December 2, 2022 by deeveedee

[Slice]

9 hours ago, deeveedee said:

My HackBookPro6,2 EFI includes a redefinition of RTC._CRS to change RTC memory length from 8 to 2 and to remove IRQNoFlags.  My SSDT includes an External declaration of the original (renamed) RTC.XCRS as UnknownObj as shown below.  I don't know how to explicitly declare a ResourceTemplate object for External reference.  Does anyone know the proper External declaration type for a ResourceTemplate object (e.g., something like ResTmpObj)?

 

External declaration of ResourceTemplate object: What should I use instead of UnknownObj?

  Hide contents

 

Replace the whole Device(RTC).

(For my mind Acidanthera's strategy to make changes in DSDT by SSDTs is wrong ab ovo)

[deeveedee]

@Slice My SSDT RTC patch works (see IORegistry screenshot below), so my question is one of curiosity and not to fix a problem.  The UnknownObj declaration does not prevent the patch from working.  I'm just wondering if there is an explicit External declaration type for ResourceTemplate.  I have a feeling we'll be debating custom DSDT vs. SSDT until Apple completely discontinues Intel support.  Maybe longer.  I don't use SSDTs because of Acidanthera - I started using them when I learned that Rehabman switched from Custom DSDT to SSDT hot patches.

 

EDIT: Note that my External declaration of XCRS is required only when not running macOS ( !_OSI("Darwin") ).  I only boot macOS with OC, so my SSDTs really don't need the If (_OSI("Darwin")) conditions.  I only added them in case others used my EFI.

 

EDIT2: I don't think that making ACPI changes with SSDTs can be considered as wrong.  It's simply another completely viable technique that works well.  I find that making the changes with SSDTs is more challenging than making them via direct edits of the DSDT and I enjoy the challenge.  The changes require much more thought which requires me to more fully understand the changes.  For me, the initial SSDTs are more difficult to produce than editing the DSDT, but the end result with SSDTs is more readable and my changes are easier for me to maintain.  It's just my personal opinion.

 

IORegistry: RTC

Spoiler

 

Edited December 3, 2022 by deeveedee

[Slice]

I think ResourceTemplate can't be external declared. Moreover declare new ResourceTemplate you will not kill previous one. They both will be in place. Be careful.

You should make new Method. One of them return one template and other one return other.

[deeveedee]

@Slice I see your point.  I definitely need to give this more thought. Thank you.

 

 

Edited December 3, 2022 by deeveedee

[deeveedee]

I now understand why I could not find an External type declaration for ResourceTemplate.  After further research of the ResourceTemplate (see ASL documentation here),  a ResourceTemplate is a macro that converts a Resource to a Buffer.  Since ResourceTemplate returns type Buffer, the correct External declaration of an object XCRS generated by ResourceTemplate (e.g., Name ( XCRS, ResourceTemplate () {....} ) is BuffObj.  

 

If I continue to include External declarations of XCRS (or any object generated by ResourceTemplate macro) in my SSDT-IRQ, the External declaration of XCRS would be BuffObj as follows:

 

    External (_SB_.PCI0.LPCB.RTC_, DeviceObj)
    External (_SB_.PCI0.LPCB.RTC_.XCRS, BuffObj)
    External (_SB_.PCI0.LPCB.TIMR, DeviceObj)
    External (_SB_.PCI0.LPCB.TIMR.XCRS, BuffObj)

 

EDIT: I have applied the change above (UnkownObj -> BuffObj) to my SSDT-IRQ and am running Big Sur, Monterey and Ventura with this change.

Edited December 4, 2022 by deeveedee