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

[deeveedee]

On 11/1/2022 at 10:12 PM, Stefanalmare said:

Is this "Failed boot" appeared after OCLP root patch? If yes, I had same issue yesterday on my core2 quad rig. I changed boot arg, in windows, from amfi=0x80 to amfi_get_out_of_my_way=1 and it booted without problems. Funny is that, after I updated OC, LegacyBoot and LogoutHook and deleted NVRAM folder from EFI, I reverted to amfi=0x80 and I had no problems booting.

Also, at the beginning I had a lot of problems making core2 rigs booting. Until I found the boot quirks working for me. Maybe you should give a try. Take a look at kernel patches too (MaxKernel). 

 

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

 

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

 

Stefanalmare,  I'm still trying to figure out why I can only boot Ventura with -v boot-arg.  My hack boots Ventura 100% of the time with -v and always freezes at the apple logo (with no progress) without -v.  Have you encountered this?

 

Also, Are you still using amfi=0x80 instead of amfi_get_out_of_my_way=1?  Do you have any documentation on amfi=0x80?

 

EDIT: I am aware that OCLP creates an EFI with amfi=0x80.  I have searched and can't find any documentation on this boot-arg.

 

Thank you for your help.

Edited March 24, 2023 by deeveedee

[deeveedee]

This is interesting reading.  I was wondering why I keep seeing a note about my Camera every time I start Microsoft Remote Desktop.  It is because I am using boot-arg amfi_get_out_of_my_way=1 which prevents the camera permission dialog from showing.

 

EDIT: Switching from boot-arg amfi_get_out_of_my_way=1 to amfi=0x80 (the boot-arg used by OCLP 0.6.1) does not change this camera permission behavior.  With boot-arg amfi=0x80, the camera permission dialog is still suppressed.

Edited January 30, 2023 by deeveedee

[FirstTimeCustomac]

3 hours ago, deeveedee said:

 

I'm still trying to figure out why I can only boot Ventura with -v boot-arg.  My hack boots Ventura 100% of the time with -v and always freezes at the apple logo (with no progress) without -v.  

I remember facing this issue before. Not sure what it was but if I had to guess, it was the modified FakeSMC for Big Sur from the forum here somewhere or using the VirtualSMC. With the FAKESMC3 from here, no issue.

[deeveedee]

EDIT: The boot issue is also resolved by adding boot-arg vsmcgen=1 for VirtualSMC.  Two options to fix the boot problem are switching to FakeSMC3 or add boot-arg vsmcgen=1 for VirtualSMC.  This issue is documented here.

 

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

 

@FirstTimeCustomac  I'll be damned - that worked!  Switching from VirtualSMC to FakeSMC3 fixed the boot problem.  I can now boot Ventura without the -v boot arg.  Next steps are to enable FakeSMC sensors.  Thank you!

 

EDIT: Your suggestion also fixed the Monterey boot problems!  Big Sur, Monterey and Ventura are now booting and running perfectly on this hack.

Edited March 24, 2023 by deeveedee

[deeveedee]

@FirstTimeCustomac  Check out this post.  I had originally concluded that VirtualSMC was the problem and then talked myself out of it.  Thanks for setting me straight!

[Stefanalmare]

On my legacy hacks I always use FakeSMC3. Mostly because of sensors reading.
I never use amfi_get_out_of_my_way=1.
For me, there are 2 types of legacy hacks.
1. Who don't need KDK (Intel IGPU, NVIDIA)
2. Who need KDK (AMD Graphics +/or USB1.1)
For first, I use:
Booter, Patch, Skip Board ID check
Kerlel, Patch, Patch IOHIDFamily (for USB1.1 rigs)
                       Force FileVault on Broken Seal
                       Disable Library Validation Enforcement
                       Reroute kern.hv_vmm_present patch (1)
                       Reroute kern.hv_vmm_present patch (2) Ventura
                       Disable _csr_check() in _vnode_check_signature
Kernel, Add, KDKlessWorkaround.kext
                      RSRHelper.kext
                      USB1.1-Injector.kext (for USB1.1 rigs)
NVRAM, 7C436110-AB2A-4BBB-A880-FE41995C9F82, csr-active-config 03080000

Second:
Same as above, but:
No Kernel, Add, KDKlessWorkaround.kext
Yes NVRAM, 7C436110-AB2A-4BBB-A880-FE41995C9F82, boot-args amfi=0x80

At install or upgrade you need boot-args amfi=0x80 also for first type, but can be deleted after.
Hope it helps!

Edited January 30, 2023 by Stefanalmare

[deeveedee]

@Stefanalmare  You already knew what I only learned the hard way and by reviewing the OCLP-generated EFI. I guess I'm late to the legacy hack game.  I currently still have amfi_get_out_of_my_way=1, but since OCLP and you both recommend amfi=0x80, I'll test that instead.  Thank you.

 

On another note, FakeSMC and the plugins (battery, Nvidia, intel) are working perfectly.  I forgot how much I missed the FakeSMC plugins and HWMonitor.  It feels good to be using them again.

 

EDIT: I have updated my High Sierra and Big Sur EFIs to use FakeSMC and associated plugins.  High Sierra, Big Sur, Monterey and Ventura are all booting perfectly after replacing VirtualSMC with FakeSMC.  I wasn't experiencing any High Sierra boot issues, but I change my High Sierra EFI so that my EFIs remain consistent.

 

EDIT2: The boot issue can also be resolved by adding boot-arg vsmcgen=1 for VirtualSMC.

Edited March 24, 2023 by deeveedee

[deeveedee]

EDIT: See amfi=0x80 / amfi_get_out_of_my_way=1 clarification here.  Leaving the post below for historical purposes.

 

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

 

@Stefanalmare I have replaced amfi_get_out_of_my_way=1 with amfi=0x80 and am not seeing any difference in behavior.  When I launch Microsoft Remote Desktop, the camera permissions dialog is suppressed with amfi=0x80 just like it is suppressed with amfi_get_out_of_my_way=1.  If I had to guess, I would say that amfi_get_out_of_my_way=1 and amfi=0x80 are identical and interchangeable.

Edited February 1, 2023 by deeveedee

[Stefanalmare]

1 hour ago, deeveedee said:

@Stefanalmare I have replaced amfi_get_out_of_my_way=1 with amfi=0x80 and am not seeing any difference in behavior.  When I launch Microsoft Remote Desktop, the camera permissions dialog is suppressed with amfi=0x80 just like it is suppressed with amfi_get_out_of_my_way=1.  If I had to guess, I would say that amfi_get_out_of_my_way=1 and amfi=0x80 are identical and interchangeable.

Nope! More security with amfi=0x80.

[deeveedee]

On 1/29/2023 at 10:00 PM, Stefanalmare said:

Nope! More security with amfi=0x80.

 

EDIT: See amfi=0x80 / amfi_get_out_of_my_way=1 clarification here.  Leaving the post below for historical purposes.

 

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

 

Ok.  I'd like to see documentation on the amfi=0x80 boot-arg if you can point me to it.  Thank you.

 

I suspect that by "more security," you mean that amfi=0x80 is only disabling some parts of amfi (unlike amfi_get_out_of_my_way=1 which disables amfi).  I can't find documentation on this anywhere.

Edited February 1, 2023 by deeveedee

[Stefanalmare]

True! When I posted this: 

,I saw a @khronokernel post about AMFI, explaining about decreasing the security risk. And the solution it was amfi=0x80. After a while he removed totally the amfi issue for non KDK root pathed rigs. This is what I know!

[deeveedee]

EDIT: See amfi=0x80 / amfi_get_out_of_my_way=1 clarification here.  Leaving the post below for historical purposes.

 

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

 

Ok - thanks.  I know that OCLP uses amfi=0x80.  I'm just looking for documentation on the boot-arg.  Thank you for your continuing help.

Edited February 1, 2023 by deeveedee

[deeveedee]

I have uploaded my current Big Sur EFI here.  This new EFI uses FakeSMC instead of VirtualSMC.  With this EFI, Big Sur, Monterey and Ventura boot without issues.  The only remaining issues that I need to resolve are non-working camera in Photo Booth app (camera works in other apps like Zoom) and non-working Bluetooth in Monterey and Ventura.  These are known issues that are still in progress.

 

EDIT: I have uploaded my current High Sierra EFI here.  While I did not need to switch from VirtualSMC to FakeSMC for booting High Sierra, I made the switch to keep the two EFIs as close as possible, since I would eventually like to have a single EFI for all versions of macOS.

 

EDIT2: I have added required hardware specifications to Post #1.  Please make sure that your Dell Latitude E6410 matches the required specifications before applying my solution in this thread.

Edited January 30, 2023 by deeveedee

[deeveedee]

When using amfi_get_out_of_my_way=1 or amfi=0x80 boot-args to disable amfi (both boot-args do the same thing), accessibility permission dialogs (e.g., camera and microphone permission dialogs) are suppressed.  When you run an app that requires these permissions, the app will be repeatedly denied these accessibility permissions without allowing you to approve them.

 

Here is a solution that worked for me.

1. Download tccplus here
2. Give Execute permissions to tccplus (chmod +x tccplus)
3. Identify the fully qualified name of the app that needs accessibility approvals (e.g., for Microsoft Remote Desktop, the app name is /Applications/'Microsoft Remote Desktop.app'
4. Use the following command to obtain the Bundle Identifier for your app identified in Step 3: "grep 'BundleIdent' -A 1 /Applications/<APPLICATION NAME>/Contents/Info.plist" (without double quotes) (e.g., for Remote Desktop, run the terminal command "grep 'BundleIdent' -A 1 /Applications/'Microsoft Remote Desktop.app'/Contents/Info.plist" (without the double quotes) )
5. Using the Bundle Identifier obtained in Step 4, run the terminal command "tccplus add <ACCESSIBILITY> <Bundle Identifier>" (without double quotes).  To grant Camera and Microphone permissions to Remote Desktop, execute the following:
   tccplus add Camera com.microsoft.rdc.macos
   tccplus add Microphone com.microsoft.rdc.macos
6. For each permission granted, you will see a response similar to the following:
   Successfully added Camera approval status for com.microsoft.rdc.macos
   Successfully added Microphone approval status for com.microsoft.rdc.macos

 

Now when you run your application, you won't be warned about Accessibility permissions.

 

EDIT: When I ran Zoom to prepare for a Zoom call, Zoom would not access my camera or microphone (and I was not prompted to allow Camera and Microphone permissions).  I executed the following terminal commands to grant Camera and Microphone access to Zoom:

• tccplus add Camera us.zoom.xos
• tccplus add Microphone us.zoom.xos

After executing these commands, Camera and Microphone worked as expected in Zoom (running in Big Sur).

 

EDIT2: If after granting permissions, you decide to deny accessibility permissions, change the accessibility permissions in System Preferences > Security and Privacy.

Edited February 1, 2023 by deeveedee

[deeveedee]

I just tested this hack's WebCam in Zoom when running Ventura 13.2 - It works!  The Webcam on this hack does work in Ventura, it is the Photo Booth app that has the camera problem.  For those who want to conduct Zoom meeting with their HackBookPro6,2 running MacOS Ventura, this hack works perfectly!

[deeveedee]

UPDATE: After further experimentation as described below with USBPorts-New.kext, I may be staying with a USBPorts.kext that uses "PortType" instead of "UsbConnector" to define child port connectors.  I am not noticing any behavioral difference between port mapping strategies, so I am not seeing any reason to change.

 

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

 

If you noticed that my USBPorts.kext/Contents/Info.plist specifies PortType where it should be specifying UsbConnector, and you noticed that I am specifying PortType = 2 where I should be specifying UsbConnector=255, you are right.  I was playing with various USB port mappings and port type guesses in an attempt to solve non-working BlueTooth in Monterey and Ventura.  I am continuing to experiment with USB port type specifications (none of which fix Bluetooth in Monterey and Ventura) and I do expect to post an updated EFI with a revised USBPorts.kext.  

 

What is interesting is that USB ports on this hack work fine despite what appears to be incorrect port type specification.

 

EDIT: My current USBPorts.kext is attached in USBPorts.kext

USBPorts.kext.zip

 

 

EDIT2: I have been reviewing the AppleUSBMaps/Plist in the OCLP 0.6.1 source code.  OCLP uses PortType instead of UsbConnector for some ports that are children of a UsbConnector.  I have revised my USBPorts.kext to match what I observed in the OCLP USB Map and attached this new kext in USBPorts-New.kext.  I can interchangeably use the two attached kexts without observing any behavioral difference in my USB ports.  Note that USBPorts-New.kext is close to my original USBPorts.kext.

USBPorts-New.kext.zip

 

When using PortType=2 for "internal" child USB ports in USBPorts.kext, Hackintool reports the port Connector as "ExpressCard."  ExpressCard is accurate for the Dell Latitude E6410, given that these internal ports (e.g., ports for Camera and Bluetooth) are only available when Express Card is enabled in BIOS.  Note that Hackintool reports the parent hub Connector (with UsbConnector=255) as "Internal."

 

Hackintool USB Connectors when using PortType=2 for "internal" USB ports.

Spoiler

 

Edited February 2, 2023 by deeveedee

[deeveedee]

I spoke with ASentientHedgebleh on Discord Server.  amfi_get_out_of_my_way=1 and amfi=0x80 are identical.  They can be used interchangeably with no difference.  The amfi bit mask is below.  I'll leave my boot-arg as amfi=0x80, but we can also use amfi_get_out_of_my_way=1 without any changes in security.

 

amfi bit mask

Spoiler

 

 

Here's the full discussion

Spoiler

 

EDIT: Now realizing that I should have been able to find this myself.  I searched the OCLP 0.6.1 source and found the amfi definitions in data/amfi_data.py.

Edited February 1, 2023 by deeveedee

[deeveedee]

I still can't get over how incredible this is...  I'm using a 2010 Dell laptop that is perfectly running macOS Monterey and I'm being prompted to upgrade to Ventura.

 

[deeveedee]

I upgraded this hack to OC0.8.9.  OC0.8.9 fixes the LegacyBoot bug that prevented OC0.8.8 LegacyBoot from loading HfsPlusLegacy.efi.  At the time of this post, my posted EFIs are still using OC0.8.8.  I will upgrade my posted EFIs to OC0.8.9 when OCLP 0.6.2 is released.

 

Also, in Monterey 12.6.3, I was prompted to install a Safari upgrade (Version 16.3 (17614.4.6.11.6, 17614)).  After applying the Safari upgrade in Monterey, I could not login to InsanelyMac.  After re-applying OCLP 0.6.1 post-install patches, I can login to InsanelyMac with the latest Safari.  Note that OCLP did not prompt me to apply the post-install patches after the Safari upgrade.

 

EDIT: The Ventura 13.2.1 upgrade proceeded without any issues - very smooth!  Currently booting macOS with OC0.8.9 and patching with OCLP 0.6.1.

 

EDIT2: After upgrading Safari in Big Sur 11.7.3, I did not have the website issues that I experienced in Monterey 12.6.3.  I did not need to re-apply OCLP 0.6.1 post-install patches in Big Sur after upgrading Safari.

 

About This Hack: Ventura 13.2.1

Spoiler

 

EDIT3: Shortly after releasing 11.7.3, Apple has released Big Sur 11.7.4 and has announced 11.7.5.

Edited February 16, 2023 by deeveedee

[deeveedee]

@PoMpIs   I remember that you were experimenting with a Wi-Fi/BlueTooth card (I think it was a BCM 94360...) in an attempt to get working BlueTooth in Ventura.  Did you ever find a working solution?  I'm still using BCM 94352HMB in this hack and it does not provide working BlueTooth in Monterey and Ventura.  My BCM 94352HMB is a 2-antenna, half-height, mini-PCIe card which I think is the same as the Dell DW1550.  Thanks!

[Stefanalmare]

1 hour ago, deeveedee said:

@PoMpIs   I remember that you were experimenting with a Wi-Fi/BlueTooth card (I think it was a BCM 94360...) in an attempt to get working BlueTooth in Ventura.  Did you ever find a working solution?  I'm still using BCM 94352HMB in this hack and it does not provide working BlueTooth in Monterey and Ventura.  My BCM 94352HMB is a 2-antenna, half-height, mini-PCIe card which I think is the same as the Dell DW1550.  Thanks!

I had this problem. And by chance, the solution was to change SMBIOS. Same config, same hardware, 94352HMB was not working in some SMBIOS, and working in another. Assuming USB map is OK.

[PoMpIs]

6 hours ago, deeveedee said:

@PoMpIs   I remember that you were experimenting with a Wi-Fi/BlueTooth card (I think it was a BCM 94360...) in an attempt to get working BlueTooth in Ventura.  Did you ever find a working solution?  I'm still using BCM 94352HMB in this hack and it does not provide working BlueTooth in Monterey and Ventura.  My BCM 94352HMB is a 2-antenna, half-height, mini-PCIe card which I think is the same as the Dell DW1550.  Thanks!

 

I have this model in the Lenovo T430:

 

https://www.ebay.es/itm/203043709916

 

Now I don't use that laptop with MacOS anymore, but it worked until MacOS Ventura 13.1...

 

bluetooth worked but no airdrop

[deeveedee]

This Monterey/Ventura Bluetooth issue has been documented in other threads and issues (including here).  I'm capturing the issue here since it's relevant to this hack and is currently one of my unresolved issues for Monterey and Ventura.  Note that I do not want to change my hack's SMBIOS MacModel, even though that is a possible fix for this.

 

My BCM 94352HMB Wi-Fi/BlueTooth card works perfectly in Big Sur.  In Monterey and Ventura, Wi-Fi works without issues, but I am unable to turn-on BlueTooth.  Inspection of the System Report reveals that, in Big Sur, the BlueTooth device is detected on Transport USB.  In Monterey and Ventura, the BlueTooth device is detected on Transport PCIe.  My webcam works and is on a USB hub just like BlueTooth, so I'm fairly confident that my USB mapping is correct.

 

Big Sur BlueTooth Transport (BCM 94352HMB): USB

Spoiler

 

Monterey/Ventura BlueTooth Transport (BCM 94352HMB) : PCIe

Spoiler

 

I have unsuccessfully experimented with different combinations of enabling/disabling BluetoolFixup.kext, BluetoothSpoof.txt and BluetoothInjector.kext.  I have tried 'sudo killall -9 BlueTool bluetoothd' and 'sudo pkill bluetoothd'.  I have tried adding DeviceProperty pci-aspm-default = 0.

 

 

EDIT: On my HackBookPro15,2 with BCM94360NG, BlueTooth Transport is USB in Monterey and Ventura

 

Monterey/Ventura BlueTooth Transport (BCM94360NG):

Spoiler

 

Edited February 20, 2023 by deeveedee

[deeveedee]

I am currently using this hack with an external VGA display, multiple browsers (Safari and Firefox) on both displays and multiple Microsoft Remote Desktop sessions.  Performance is outstanding in Monterey 12.6.3.  After my amazing experience with this old hack, I think the pursuit of the latest/greatest hardware for a new hack is far overrated.  Apple has done an outstanding job with macOS.  It is very efficient on this old hardware.

 

EDIT: With the NVCAP that I have configured in my currently posted EFI, both the external DP and VGA ports are working perfectly.  I can have three simultaneous displays (internal, VGA and DP).  Also, the DP port works as a straight-through DP->DP and with a DP->VGA adapter.

Edited February 25, 2023 by deeveedee

[deeveedee]

Now that I'm using this hack on a regular basis without any significant issues (Monterey is my production baseline for most activities and I use Big Sur for XCode 13, booting with OC 0.8.9 and patched with OCLP 0.6.1), I added a second drive in the aux bay for Time Machine.  Very convenient.  Dell did a great job with the hardware design of this Latitude E6410.  The ACPI developers were lazy (as you can see from the numerous ACPI patches that I needed to make and even an ACPI bug that I found early on in my first Mojave thread for this hack), but the hardware developers did a great job.  I still can't believe that an old platform like this is as responsive as it is.

 

My next major upgrade for this hack will occur when OCLP 0.6.2 is released, but until then, this hack is amazingly perfect.  It was a lot of work to hack this, but very rewarding.  It was worth it.

Edited March 4, 2023 by deeveedee