Catalina on Dell Latitude E6410 (Nvidia Graphics) With Working Sleep

[deeveedee]

Has anyone been able to apply incremental security updates to our hacks?

 

Catalina Security updates will be available as incremental updates with no option for full installers.  In order to stay current with these security updates, we'll need a way to apply the incremental updates.  jackluke's catalinaswufix appears to be the best way to do this, but I have not been successful when using catalinaswufix on our hacks.  Has anyone been able to apply incremental updates to our hacks?

 

My experience with catalinaswufix has been as follows

• I cleared /Library/Updates as suggested here
• I successfully enabled the incremental updates so that they are available through standard Software Update mechanism
• After I started the incremental update, I clicked "OTA Update Fix" at about 200K into the download as suggested here and allowed the download to complete 
• The update appeared to install without issues
• I booted from the Catalina Installer USB and attempted to apply the Post-Install patches; however, when the patches were applied, there is no option to Force Cache Rebuild (this is normally available) as suggested here
• Attempts to boot the updated/patched Catalina result in white screen
• Booting into single-user mode and rebuilding cache does not fix the problem
• The only way I have found to recover is to reinstall Catalina 10.15.7.03 from a patched full installer (the install retains all programs and data, so nothing is lost and the system is fully recovered, but not updated)

[1337ftw]

Quick update: My Big Sur attempt a couple of months ago failed and my E6510 died today :/

 

[vbmota]

49 minutes ago, 1337ftw said:

Quick update: My Big Sur attempt a couple of months ago failed and my E6510 died today :/

 

RIP, my friend.

Can you report why your 6510 died?

[1337ftw]

The DVD drive was already dead. Now the RAM died, and I don't feel like fixing it anymore

[deeveedee]

Open Core now includes support for Legacy NVidia graphics.  An OC solution for this Latitude E6410 will be a fun exercise.

 

The MacBookPro6,2 is now listed here.  Does this mean we could be running Big Sur with graphics acceleration?

Edited May 6, 2021 by tonyx86

[deeveedee]

Much progress has been made to install the latest macoS versions on legacy hardware.  See here.  I have been too busy to spend any time on this HackBookPro6,2, so installing Big Sur is going to need to be done by someone else. It looks to me like it should be very possible.

[deeveedee]

It has been a long time since I installed macOS on this Dell Latitude E6410.  This thread revisits the installation and may help others who want to install macOS on their old (and still great) Dell Latitude E6410.

[deeveedee]

I am now booting my Dell Latitude E6410 with OpenCore 0.8.5 and all ACPI hot patches (no more custom DSDT).  I have a few things to work on and am going to test first by installing High Sierra (the last OS natively supported without DosDude's patcher).  I am then planning to use the OpenCore Legacy patch tools to enable booting of more current macOS versions on this Latitude E6410.

 

Is there any interest in my OC solution for this laptop?  If so, just like this post and I'll use the level of interest to decide whether I post my solution with a new guide.

[vbmota]

1 hour ago, deeveedee said:

I am now booting my Dell Latitude E6410 with OpenCore 0.8.5 and all ACPI hot patches (no more custom DSDT).  I have a few things to work on and am going to test first by installing High Sierra (the last OS natively supported without DosDude's patcher).  I am then planning to use the OpenCore Legacy patch tools to enable booting of more current macOS versions on this Latitude E6410.

 

Is there any interest in my OC solution for this laptop?  If so, just like this post and I'll use the level of interest to decide whether I post my solution with a new guide.

Yes, please. Have a work to do with it.

[deeveedee]

@vbmota I estimate that I have a few more hours of work (the solution has already taken more hours than I want to admit).  If there is enough interest, I will finish the solution and post a guide.  If there's not enough interest, I may decide not to finish the solution (which means I won't post the guide since I'd be answering lots of questions about what work remains).  It may not be worth my time.  Let's see if there is enough interest in this.

Edited October 14, 2022 by deeveedee

[deeveedee]

 

[deeveedee]

I still need help, so I'm leaving my post below, but I'm going to see if I can figure out NVCAP from this.

 

-------------------------------

 

@1Revenger1 I stumbled upon your NVCAP calculator tool and am very impressed!  Thank you for your work on this!  I'm currently using this NVCAP

Spoiler

                    "NVCAP", 
                    Buffer (0x14)
                    {
                        /* 0000 */  0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00,  // ........
                        /* 0008 */  0x0E, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07,  // ........
                        /* 0010 */  0x00, 0x00, 0x00, 0x00                           // ....
                    }, 

 

that I found through trial and error, but I'd like to recalculate it using your tool.  My current NVCAP is copied from someone else's post and I don't remember where I got it.

 

Would you be able to confirm that I'm using your tool correctly with the attached VBIOS file?  My Dell Latitude E6410 has an NVidia G3100m dGPU with internal display, analog VGA output and DP output.  I don't know what to specify for the Version (my graphics specs are here) (your instructions indicate 'Version - 5 starting with the 8000-series, 4 for 6000 and 7000 series') and I think that the Field f should be 0xf, but I'm not sure.  Thank you for your help.

1. Extract the VBIOS bin file (attached) using CLOVER
2. Download and run NVCAP calculator tool, opening the extracted VBIOS bin file
3. Select Option (2) - calculate NVCAP
4. Add Digital display to NVCAP head 1 and Analog display to NVCAP head 2
   Spoiler

   

5. Change mobile from false to true
   Spoiler

   

6. Version?  My current NVCAP appears to be specifying Version 4
7. Field F: 0xf?  My current NVCAP appears to be specifying 0xe

 

Thank you for your help!

c0000.bin.zip

Edited October 15, 2022 by deeveedee

[1Revenger1]

It should be Version 5, and I'm not totally sure about Field F. I got a few examples for values in the README.

Field f - Unknown
    07: Clover's default
    0A: Desktop-class GPU (Chameleon default)
    0B: Laptop-class GPU
    0E: 300 series+ MacBook Air/Low end
    0F: 300 series+ MacBook Pro/iMac/High End

I think either 0xE or 0xF is fine. Looks like it's an Quadro NVS 3100M, which is based on a GeForce 200/300 series core.
Edit: I got a similar output to your NVCAP value you were using before by putting the digital display (Display Port?) on head 1, and everything else on head 2. Each head represents one of the two monitors that the GPU can output too.

Edited October 16, 2022 by 1Revenger1

[deeveedee]

@1Revenger1 Thank you!!!

 

[deeveedee]

@1Revenger1 It appears that this laptop and/or the NVS 3100m are very tolerant of NVCAP values.  I ran your tool and assigned the digital (I suspect DP as you guessed) to Head 1 and the Analog to Head 2.  I left the DVI displays unassigned.  I am currently running with this NVCAP:

 

 

I was previously running with version 04 and the laptop lid byte set to 00 (now it's 01).  

 

Thanks again for your help!

[deeveedee]

Just a quick update on my OpenCore solution for this old but still excellent Latitude E6410.  I have completed all ACPI hot patches and verbose booting shows that all tables are properly loaded with no ACPI errors.  I'm currently running High Sierra (last macOS that natively supports Nvidia) and the laptop is operating perfectly.  Boot time is very fast, so applying hot patches vs. loading a custom DSDT makes no noticeable boot time difference.

 

Sleep / Wake and USB work well (as with the custom DSDT).  I'm currently debugging sound, since AppleALC still has the same problems that it did before with CLOVER and custom DSDT (which caused me to switch to VoodooHDA).

 

After I get sound working properly with OC 0.8.5, ACPI hot patches and High Sierra, I'll learn OC legacy patching and attempt to boot newer macOS versions, starting with Monterey.

 

EDIT: I'm noticing that this new OC-based solution sleeps and wakes very fast.  I haven't timed it, but it seems to me that the laptop sleeps and wakes faster than it did before.

Edited October 16, 2022 by deeveedee

[deeveedee]

EDIT2: After specifying alcid=11 in my OC boot-args, boot time is still painfully slow with AppleALC.kext enabled and layout-id still appears as 7 in IORegistry

Spoiler

 

Still open to suggestions.  Thank you.

-------------------------------------------------------

EDIT: I am specifying layout id in my SSDT patch.  I noticed that the layout id in IOReg is shown as 7 (not 11 as I have specified).  I am not specifying the AppleALC layout id in a boot-arg or DeviceProperties, so maybe this is part of the problem.  I will test this when I have time.

 

-------------------------------------------------------

 

Here are my AppleALC.kext test observations in case anyone has suggestions.  

• With AppleALC.kext enabled, boot time is 1-2 minutes longer than without (didn't time it exactly) (no sound without kext).
• With AppleALC.kext, sound works after macOS (High Sierra) boots
• I specify the codec as 0x111D76D5 (287143637) with layout id 0x0b (11).  This matches a supported codec and layout ID in AppleALC.kext/Contents/Info.plist

I know I can fix the boot time by resorting to VoodooHDA.  I also am aware this this is an old problem.  If anyone has any suggestions for speeding up the boot time when using AppleALC, I'm very open to your suggestions.  Thank you.

 

Verbose boot log (with AppleALC) shows:

busy timeout[0], (60s) 'IOHDACodecFunction','IOHDACodeFunction', 'IOHDACodeFunction', 'IOHDACodecFunction'
considerRebuildOfPrelinkedKernel com.apple.driver.AudioAUUC triggered rebuild

 

IOReg

Spoiler

 

Edited October 16, 2022 by deeveedee

[deeveedee]

According to this, if alc-layout-id appears in IORegistry, Apple ALC is patching correctly.  It looks like AppleALC is working properly, but the boot time is delayed.  Strange.

 

IORegistry: alc-layout-id

Spoiler

 

Edited October 16, 2022 by deeveedee

[deeveedee]

I believe that I have found the fix for the AppleALC.kext boot delay problem.  Adding boot-arg alcdelay=1000 seems to fix the problem.  I suspect that this delay is too long, but I don't notice any delay in boot time with this boot-arg.

 

EDIT: The slow boot problem still happens with alcdelay=500.  With alcdelay=1000, audio becomes available shortly after macOS boots.  I'm leaving alcdelay=1000 as a bandaid, but it does appear that there is an unresolved conflict.

Edited October 16, 2022 by deeveedee

[deeveedee]

Leaving this post below, but I have completed enough work to show that this new OC-based solution is viable.  My new thread where I will post the solution is here.

 

@vbmota I appreciate your encouragement to find a way to install newer macOS versions on this Dell Latitude E6410.  It appears that only you and I share this interest.  I haven't seen any other interest in the Latitude E6410 (understandable, since it's so old).  I have been experimenting with OpenCoreLegacyPatcher to generate an OpenCore build for installing Monterey on this HackBookPro6,2.  I am having challenges with OCLP and have resorted to downloading the OCLP source, installing the required python dependencies and running OCLP from the command line (not using the GUI).

 

I attempted to install Monterey with the OCLP-built EFI (modified to include my EFI customizations for the Latitude E6410), but the install failed.  Debugging the Monterey installation is going to take work.  As soon as I have anything to report, I'll post here in this Catalina thread.  If I am able to make progress with installing Monterey, I'll create a new thread.

 

Until I am able to install a version of macOS that's newer than Catalina, I recommend sticking with the CLOVER method documented in this thread (using DosDude's patcher).  Documenting my OpenCore solution and methods is not going to be worth my time unless I am able to install something newer than Catalina.

Edited October 18, 2022 by deeveedee

[1Revenger1]

I would strongly recommend not using OCLP to generate EFIs. They create EFIs for Macs which have a very different configuration compared to hacks. If you are going to use OCLP, just use the root volume patches.

[deeveedee]

@1Revenger1 Your timing is perfect.  I've generated an EFI for Big Sur installation with OCLP and am now reviewing the generated EFI to see what I need to add to my own custom EFI. The OCLP generated EFI includes an ACPI add (disable Device CPBG) which I need, kexts (which I'm not sure about), partially disabling SIP and other things.  

 

When you say "just use the root volume patches," what do you mean?  Thanks.

Edited October 17, 2022 by deeveedee

[1Revenger1]

OCLP has two parts to it. The part which generates the EFI (do not use on a hack). The second part is ran on the installed OS, and patches the root volume with the older graphics driver. This is probably the option your looking for to add support.

[deeveedee]

Oh, ok.  I understand the post-install patching part.  I'm reviewing the OCLP-generated EFI to see if I can figure out how to get the macOS installer to run on my unsupported hack.  I think I need the ACPI CPBG patch, one or more of the kexts (like ASPP-Override), partial disable SIP and then probably -amfi_get_out_of_my_way boot arg or something similar.  I also have boot-arg -no_compat_check, but I don't believe that works until after macOS is installed.  I'm not sure how OCLP is spoofing a newer Mac model in order to fool the the installer.

 

EDIT: I just found this and am reviewing.

Edited October 17, 2022 by deeveedee

[deeveedee]

Using the EFI that I created by combining my own custom EFI with the EFI generated by OCLP, I am able to boot the Big Sur installer.  I see this as validation of my approach.  Note that I am only using the OCLP-generated EFI to see what changes I need to make to my own custom EFI.  Note that the Big Sur installer booted into Recovery (which is the same as the installer generated by DosDude's patcher).  I'm venturing into unknown territory (for me), but I believe this confirms that the EFI changes I imported from OCLP's EFI are working.

 

Big Sur installer on Dell Latitude E6410

Spoiler

 

NOTES: For Big Sur, I needed to increase boot-arg alcdelay from 1000 to 2000 (didn't try any values between 1000 and 2000) to avoid the startup delay caused by AppleALC.  Also, I needed to attach a USB keyboard in order to be able to choose an option from the OC boot picker.  OC is not properly selecting the next stage of the Big Sur installation, so I need to manually choose the install option from the OC boot picker each time the Big Sur installer restarts.  Apparently, some of the mods I made to my OC EFI in order to boot the Big Sur installer have interfered with Ps2KeyboardDxe.efi.  Other than that, the Big Sur installer appears to be running fine.

 

Here's a recap of my approach so far:

1. Convert the CLOVER / custom-DSDT EFI in this thread to an OpenCore 0.8.5 / hotpatched EFI (including switch from FakeSMC to VirtualSMC and upgrading all kexts)
2. Thoroughly test new OC-based EFI with verbose logging and OC debug options enabled.  Refine ACPI hot patches based on log output
3. Switch from VoodooHDA to AppleALC (required alcdelay boot-arg)
4. Install macOS High Sierra 10.13.6 and test
5. Download OpenCore Legacy Patcher.  After brief experimentation, I decided to first upgrade to Big Sur with 
   OpenCore-Patcher-TUI.app.zip version 0.4.6 (terminal non-GUI version of OCLP)
6. Running OCLP on my HackBookPro6,2 (running High Sierra) allowed OCLP to detect and self-configure for my hack.  I used OCLP to generate an EFI suitable for installing Big Sur.
7. Reviewed the OCLP-generated EFI to determine the necessary changes to my own OC EFI.  These changes included
   1. CPBG ACPI patch (to disable Device CPBG)
   2. Additional kexts specified by OCLP
   3. NVRAM additions (including csr-active-config = <02080000>
   4. Other changes

 

A big thank you to the OCLP developers for the hard work and dedication that is allowing us to extend the life of our old Macs and Hacks!

Edited October 17, 2022 by deeveedee