deeveedee Posted December 5, 2022 Author Share Posted December 5, 2022 (edited) 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 the post below for historical purposes. ====================================== I'm experimenting with a few changes to see if I can resolve the Monterey boot issue. Part of my experiments included renaming HDEF->HDAS and disabling AppleALC.kext and WhateverGreen.kext. No surprise that macOS boots faster without these kexts and Graphics works fine. EDIT: Disabling AppleALC.kext and WhateverGreen.kext does not seem to have improved Monterey booting; however, I did remember that I don't need WhateverGreen and so I am currently running without WhateverGreen (AppleALC still enabled). My SSDT-GFX0 fully patches Nvidia graphics to the point that I don't see a need for WhateverGreen.kext on this hack. EDIT2: The only difference I'm noticing so far without WhateverGreen.kext is that Device VID is not renamed to GFX0. I confess to being one who, when I was learning about ACPI patching, thought that all of the "Apple" devices needed to be renamed for proper operation. Note that Device HDAU is not missing with WEG, it just appears later in IORegistryExplorer. HDAU is added automatically by AppleALC.kext. Without WhateverGreen.kext Spoiler With WhateverGreen.kext Spoiler Edited March 24, 2023 by deeveedee 1 Link to comment Share on other sites More sharing options...
tafkad Posted December 6, 2022 Share Posted December 6, 2022 On 10/31/2022 at 2:28 PM, deeveedee said: The NVCAP value that I included in my posted EFIs was generated by @1Revenger1 's NVCAP calculator. I downloaded the calculator file "nvcap_calculator_macos_amd64" on my Mac but can not get it to run in the terminal window - any help? (from anyone who knows) greatly appreciated. Thanks ! Link to comment Share on other sites More sharing options...
deeveedee Posted December 6, 2022 Author Share Posted December 6, 2022 @tafkad Have you tried making it executable with the terminal command "chmod +x nvcap_calculator_macos_amd64" (without quotes) I don't remember if I had to do this or not. Link to comment Share on other sites More sharing options...
tafkad Posted December 6, 2022 Share Posted December 6, 2022 5 minutes ago, deeveedee said: @tafkad Have you tried making it executable with the terminal command "chmod +x nvcap_calculator_macos_amd64" (without quotes) I don't remember if I had to do this or not. Egg Salad! yes that did it thank you so much. Working on converting from clover to open core with an M6800 loaded with the Quadro K3100M - currently runs Catalina OOTB but want to move on to newer systems. Really like your posts - cheers! 1 Link to comment Share on other sites More sharing options...
tafkad Posted December 6, 2022 Share Posted December 6, 2022 Is there a link to your video rom? I'd like to try one that works. I've downloaded 5 for the video card I have from Techpowerup and all of them give me errors when opening in the calculator. Link to comment Share on other sites More sharing options...
deeveedee Posted December 6, 2022 Author Share Posted December 6, 2022 (edited) @tafkad See this post in my previous thread which was based on CLOVER / DosDude patcher. If you think you are going to have many questions about your laptop, it would be good if you started a thread for your laptop and asked your questions there. This way we're not confusing two different laptops and the result would be a thread dedicated to your work on your M6800. If you ping me using @deeveedee in your thread, I'll answer your questions there if I can. Edited December 6, 2022 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted December 6, 2022 Author Share Posted December 6, 2022 (edited) EDIT: 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. =============================== Something changed (not sure what) and I need the -v boot-arg again to boot Big Sur and Ventura. =============================== I have upgraded this HackBookPro6,2 to OpenCore 0.8.7 and I upgraded AppleALC and VoodooPS2Controller to the new Release kexts. The OC0.8.7 EFI for Big Sur, Monterey and Ventura is attached here. The changes in this EFI have been documented through posts in this thread. I am leaving my EFI for High Sierra unchanged with OC 0.8.6. Big Sur is still my preferred macOS for this hack and it continues to run flawlessly. This hack has far exceeded my expectations and leaves me with no desire to buy a new laptop. EDIT: I am now able to boot Big Sur without boot-arg -v. If you recall from one of my previous posts, macOS was only booting on this rig with verbose mode enabled. I don't know the change that "fixed" this, since I haven't been testing without -v after I last reported that I needed -v to boot. Edited March 24, 2023 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted December 7, 2022 Author Share Posted December 7, 2022 (edited) EDIT: I am currently disabling the HDAU device by injecting class-code = <FF FF FF FF> via SSDT. With this class-code, AppleALC and AppleHDA ignore the device and booting is quick without the AppleHDA delay. Leaving the post below for historical purposes. ================================= I believe that some of the boot issues I am seeing are the same boot issues that I experienced when using CLOVER here. Namely, loading AppleALC.kext conflicts with something else during boot. If I rename HDEF->HDAS (so that audio is not detected by AppleHDA) and I disable AppleALC, booting Big Sur is consistently fast and flawless. The solution when booting with CLOVER was to switch from AppleALC to VoodooHDA. I would switch to VoodooHDA if there is a single version of VoodooHDA that supports Big Sur, Monterey and Ventura and can be loaded via Bootloader (not installed in /L/E). Edited January 29, 2023 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted December 7, 2022 Author Share Posted December 7, 2022 (edited) I have switched back to AppleALC after resolving the AppleALC / AppleHDA boot delay problem with a new SSDT-HDAU that sets HDAU.class-code = <FF FF FF FF>. With this class-code, AppleALC and AppleHDA ignore device HDAU and my hack boots without the AppleHDA delay. ================================= I have successfully installed VoodooHDA.kext in Big Sur using the steps here. EDIT: Booting Big Sur is quicker with VoodooHDA.kext than with AppleALC.kext and Big Sur continues to run perfectly on this hack. Impressive. Edited January 29, 2023 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted December 9, 2022 Author Share Posted December 9, 2022 (edited) I have switched back to AppleALC after resolving the AppleALC / AppleHDA boot delay problem with a new SSDT-HDAU that sets HDAU.class-code = <FF FF FF FF>. With this class-code, AppleALC and AppleHDA ignore device HDAU and my hack boots without the AppleHDA delay. If VoodooHDA.kext could be injected via BootLoader in newer versions of macOS, I would have remained with VoodooHDA. ================================= I am so impressed with VoodooHDA on this hack, that I updated my High Sierra OC EFI with VoodooHDA. The new High Sierra OC EFI here includes the following changes: Upgraded to OC 0.8.7 Replaced AppleALC with VoodooHDA 2.9.8 (note that VoodooHDA is working after being injected with OC and not installed in /L/E). Note that HDEF is renamed to HDAS and ACPI includes SSDT-HDAS. Removed WhateverGreen.kext (not needed since SSDT-GFX0 fully patches Nvidia graphics) Disabled verbose booting With VoodooHDA, this hack boots and runs High Sierra perfectly. I shouldn't be surprised, since I came to the same conclusion when I was using CLOVER with Mojave and Catalina. EDIT: The config.plists for High Sierra and Big Sur are similar enough now that I should be able to consolidate my High Sierra EFI and my Big Sierra EFI into a single EFI for High Sierra and Big Sur. Big Sur would still require the installation of VoodooHDA.kext in /L/E. Edited January 29, 2023 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted December 9, 2022 Author Share Posted December 9, 2022 (edited) Following @Slice 's tip here, I am injecting the attached SSDT-HDMI to name the audio device at pci10de,be3 (formerly, my SSDT-HDAU). This is a cosmetic change, since VoodooHDA does not need Device at pci10de,be3 to be named HDMI. With this renaming to HDMI, my hack continues to boot fast (using VoodooHDA.kext), since AppleHDA does not detect Device HDMI. HDMI in IORegistryExplorer Spoiler SSDT-HDMI.aml.zip Edited December 9, 2022 by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted December 12, 2022 Author Share Posted December 12, 2022 I have a "working" solution for AppleALC here. Link to comment Share on other sites More sharing options...
deeveedee Posted December 12, 2022 Author Share Posted December 12, 2022 The ssdtPRGen exercise was informative, but after running my hack with a CPU SSDT-PM, I have found that performance and responsiveness is worse with the SSDT-PM than without. I have removed the SSDT-PM from my ACPI patches. Also, I revisited NVCAP generation with NVCAP Calculator and have assigned the two DVI (DP) ports to Head 2 with the Analog (VGA) port. I am using the new NVCAP value (no noticeable difference since I'm not using and haven't retested the DP port) with the NVCAP Calculator values as follows: NVCAP Calculator - revised values Spoiler 1 Link to comment Share on other sites More sharing options...
deeveedee Posted December 13, 2022 Author Share Posted December 13, 2022 (edited) Early in this thread here, I had reported a bug in my _WAK method where I was using variable NHDA that was never defined. I have since removed the offending code from my _WAK method, but for those who are curious, this Acidanthera document for WhateverGreen shows the definition for NHDA. EDIT: I have restored my previous code to my _WAK method after adding the declaration of NHDA to my SSDT-PTS-WAK and am running with this modified SSDT now. I don't notice any changes in WAK behavior and will continue to test. EDIT2: I have implemented the PEG0._PRT fix suggested in the Acidanthera document for WhateverGreen (adding the assignment of NHDA = 1 to PEG0._PRT) and am testing with this now. This looks very interesting, as it relates to dGPU audio. EDIT3: After fully implementing the PEG0._PRT fix, I tested AppleALC. The _PRT fix does not resolve the AppleALC slow-boot problem. The only "fix" I've found so far for AppleALC operating with this hack is to disable the HDAU rename in AppleALC as I documented here. The -alcdelay boot-arg works most of the time, but the delay value (e.g., 3000) is dependent on whether booting with -v and is dependent on the macOS version, so it is difficult to find a single value of alcdelay that works when multi-booting Big Sur, Monterey and Ventura. The best solution for sound on this hack would be VoodooHDA if VoodooHDA could be injected via boot loader. Edited December 14, 2022 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted December 14, 2022 Author Share Posted December 14, 2022 I upgraded to Big Sur 11.7.2 as describe here. The upgrade was smooth and following the upgrade, all appears to be working perfectly. Big Sur continues to be my favorite macOS on this hack. The upgrade overwrote System/Volumes/Preboot/uuid/System/Library/CoreServices/.disk_label.contentDetails, so I needed to edit this file to restore my desired text for the Big Sur entry in OC boot picker. Link to comment Share on other sites More sharing options...
deeveedee Posted December 14, 2022 Author Share Posted December 14, 2022 I will have to try @MacNB 's VMM trick here to perform incremental macOS upgrades. With my posted EFI, macOS upgrades require the full macOS installer. Link to comment Share on other sites More sharing options...
deeveedee Posted December 14, 2022 Author Share Posted December 14, 2022 (edited) Putting this question out there for someone who knows much more than I do about NVCAP (possibly @1Revenger1). After modifying my NVCAP as stated here to add the two DVI ports to HEAD 2, I found that my laptop would boot to a dark screen (internal laptop display is dark) without hda-gfx property defined in GFX0 IOReg (which I can achieve by defining hda-gfx in my GFX0._DSM ACPI patch). I stumbled upon this discovery (for me) purely by accident. It doesn't matter whether I define hda-gfx as "onboard-1" or "onboard-2" and seems to only matter that it is defined. It appears to me that, with the additional display ports added to HEAD 2 and without defining hda-gfx, the dGPU does not choose the internal laptop display as the boot display. Can anyone explain this hda-gfx / NVCAP behavior? Edited December 14, 2022 by deeveedee Link to comment Share on other sites More sharing options...
Stefanalmare Posted December 14, 2022 Share Posted December 14, 2022 32 minutes ago, deeveedee said: Putting this question out there for someone who knows much more than I do about NVCAP (possibly @1Revenger1). After modifying my NVCAP as stated here to add the two DVI ports to HEAD 2, I found that my laptop would boot to a dark screen (internal laptop display is dark) without hda-gfx property defined in GFX0._DSM. I stumbled upon this discovery (for me) purely by accident. It doesn't matter whether I define hda-gfx as "onboard-1" or "onboard-2" and seems to only matter that it is defined. It appears to me that, with the additional display ports added to HEAD 2 and without defining hda-gfx, the dGPU does not choose the internal laptop display as the boot display. Can anyone explain this hda-gfx / NVCAP behavior? Try force-online data 01000000. Link to comment Share on other sites More sharing options...
deeveedee Posted December 14, 2022 Author Share Posted December 14, 2022 (edited) @Stefanalmare Is that a WhateverGreen property or a macOS property? I'm not using WhateverGreen (patching is complete in my SSDT-GFX0 after my change here). My hack works great with my new NVCAP and hda-gfx, I'm just wondering if anyone can explain why hda-gfx must be defined with my new NVCAP. I do need boot-arg igfxonln=1 (same as force-online DeviceProperty) for my HackMini8,1 (UHD630) where I use WhateverGreen. Edited December 14, 2022 by deeveedee 1 Link to comment Share on other sites More sharing options...
1Revenger1 Posted December 14, 2022 Share Posted December 14, 2022 I've got no clue honestly, I wonder if that would help some other people I've seen have issues with Kepler cards. Link to comment Share on other sites More sharing options...
Slice Posted December 15, 2022 Share Posted December 15, 2022 13 hours ago, deeveedee said: Can anyone explain this hda-gfx / NVCAP behavior? May be you can find useful information here? https://github.com/CloverHackyColor/CloverBootloader/wiki/Configuration#nvcap 1 Link to comment Share on other sites More sharing options...
deeveedee Posted December 15, 2022 Author Share Posted December 15, 2022 (edited) Setting pci10de,be3.class-code = <FF FF FF FF> causes AppleHDA to ignore the device, thus eliminating the boot delay. Leaving the post below for historical purposes. At the time of this writing, I am overwriting class-code with SSDT-HDAU. ===================================== I'm still trying to figure out why naming pci10de,be3 -> HDAU causes significant boot delays (because AppleHDA detects HDAU). As I investigate this, I found something that is confusing me: HDEF and pci10de,be3 audio are forced to have property hda-gfx="onboard-1" no matter what I do to patch ACPI. I would think that HDEF would have property hda-gfx="onboard-1" and pci10de,be3 would have hda-gfx="onboard-2" but any attempt that I make with ACPI patching to set hda-gfx="onboard-2" results in hda-gfx="onboard-1" in IOReg. Note that if I attempt to set HDEF's hda-gfx="onboard-2," something is forcing it to hda-gfx="onboard-1" Can anyone confirm that the two audio devices should have different hda-gfx values ("onboard-1" and "onboard-2") and if so, what could be forcing both audio devices to have the same hda-gfx="onboard-1" value? Could it be because I don't have Intel iGPU and only have a single enabled graphics device? For the attached screen shots, I am injecting WhateverGreen.kext (which my Nvidia patching makes unnecessary and WhateverGreen.kext only renames AGP.VID to AGP.GFX0 and it makes no difference regarding the value of hda-gfx) and I am naming pci10de,be3 to HDMI (a cosmetic renaming via SSDT that attempts to set hda-gfx="onboard-2"). My SSDT-HDMI is attached. GFX0 IOReg (hda-gfx = "onboard-1") Spoiler HDEF IOReg (hda-gfx = "onboard-1") Spoiler HDMI (pci10de,be3) IOReg (hda-gfx = "onboard-1") Spoiler SSDT-HDMI (cosmetic naming of pci10de,be3 -> HDAU, unsuccessfully attempts to set hda-gfx="onboard-2") SSDT-HDMI.aml.zip EDIT: My original OC EFI for this hack includes SSDT-IGPU which sets IGPU._STA=0. This is unnecessary, since the iGPU is already disabled (only Nvidia dGPU is enabled). I have removed SSDT-IGPU from my current EFI since it doesn't do anything. As expected, there is no change in IOReg (including no change in hda-gfx values) and no change in system behavior. EDIT2: If I drop my SSDT-HDEF (allowing AppleALC to perform exclusive patching of HDEF), AppleALC does not assign a value of hda-gfx to HDEF IOReg. Spoiler Edited February 18, 2023 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted December 16, 2022 Author Share Posted December 16, 2022 (edited) This test confirmed, for me, that this old hack running Monterey is a viable system. Microsoft Visual Studio / Xamarin and XCode 14.1 are installed and running perfectly in Monterey and I am able to manage certificates and build Release and Development builds of iOS and Android apps. Not nearly as fast as my HackMini8,1 (i9-9900), but a perfectly good mobile development / debugging platform when needed. EDIT: This laptop worked out even better than I expected for some debugging and ultimately a new iOS build in Visual Studio / Xamarin. One of the custom apps that I build links in a custom library built in Xcode to support iOS 9.3 (iPhone 4s). Xcode 14 dropped support for iOS 9.3 (minimum supported iOS is 11). Since this laptop multi-boots Big Sur, Monterey and Ventura, I was able to boot Big Sur, build the library in Xcode 13 with minimum iOS target 9.3 and then reboot into Monterey, run Visual Studio / Xamarin and link the Xcode13-compiled library for app release. Edited December 17, 2022 by deeveedee Link to comment Share on other sites More sharing options...
Slice Posted December 17, 2022 Share Posted December 17, 2022 @deeveedee Looking to your signature and wonder "SBMIOS". 1 Link to comment Share on other sites More sharing options...
deeveedee Posted December 17, 2022 Author Share Posted December 17, 2022 (edited) Ha! If it is spelled that way, it's been that way for a long time EDIT: Thanks for letting me know! Fixed. Edited December 17, 2022 by deeveedee Link to comment Share on other sites More sharing options...
Recommended Posts