1Revenger1 Posted September 19 Share Posted September 19 I saw the OC-Little-Translated link earlier but I hadn't had a chance to look at it closely until now. @cankiulascmnfye It is a little funny that ACPI is being touted as the more native way to do this when Apple devices themselves use USB maps. Look under /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBHostPlatformProperties.kext/Contents/Info.plist and you will see a bunch of USB maps for various Macs that attach to various USB controllers (EHC1, EHC2, and XHC1 being the most common). The devices that do have USB maps isn't very consistent, it seems to mostly be Ivy Bridge/Haswell in there. I did see the iMacPro1,1 in there though. ACPI mapping is a totally valid way to do things, but I don't think it should be considered more "native" compared to a USB map. 2 Link to comment Share on other sites More sharing options...
cankiulascmnfye Posted September 19 Share Posted September 19 @1Revenger1 I assume your are referring to the "Benefits of mapping USB ports via ACPI vs. using a USB port kext" of the guide, where the point of mapping USB ports via ACPI as being "more native" is made.I had chatgpt generate this section and it seems it has hallucinated in this regard. Thanks for the info. I will redact it later. But as far as running macOS on Wintel systems is concerned, I think mapping ports via ACPI is the best solution, if applicable. I have a ThinkPad T490 which has thunderbold via USB-C and mapping via ACPI doesn't really work because USB definitions are not limited to one file, so it turned ot to be more complicated, so I resorted to the kext metodod. Bur I had to redo this mapping several times in the last 2 years because of things changing in macOS which would not have been necessary if I could have managed to map the ports viia ACPI. 1 Link to comment Share on other sites More sharing options...
1Revenger1 Posted September 19 Share Posted September 19 47 minutes ago, cankiulascmnfye said: @1Revenger1 I assume your are referring to the "Benefits of mapping USB ports via ACPI vs. using a USB port kext" of the guide, where the point of mapping USB ports via ACPI as being "more native" is made.I had chatgpt generate this section and it seems it has hallucinated in this regard. Thanks for the info. I will redact it later. But as far as running macOS on Wintel systems is concerned, I think mapping ports via ACPI is the best solution, if applicable. I have a ThinkPad T490 which has thunderbold via USB-C and mapping via ACPI doesn't really work because USB definitions are not limited to one file, so it turned ot to be more complicated, so I resorted to the kext metodod. Bur I had to redo this mapping several times in the last 2 years because of things changing in macOS which would not have been necessary if I could have managed to map the ports viia ACPI. If you don't mind, can I ask what you had to change between macOS versions? Link to comment Share on other sites More sharing options...
deeveedee Posted September 19 Author Share Posted September 19 (edited) If it helps at all, I haven't ever had to change the USBPorts.kext mapping for this HP EliteDesk 800 G4/G5 Mini because of macOS changes (and I first finalized this USBPorts.kext mapping for macOS Catalina). I reviewed the history of my USBPorts.kext changes and they were driven by experimentation with Bluetooth, defining USB-TypeC connector types and adding port comments. No USB port mapping changes were driven by changes in macOS. I did not attempt installations of macOS earlier than Catalina, so I can't comment on any USB port map changes that might be required for earlier versions of macOS. This hack boots macOS versions Catalina through Sequoia with the exact same USBPorts.kext. EDIT: I also made the required USBPorts.kext changes when experimenting with different SMBIOS models, but it's not hard to incorporate multiple SMBIOS models in a single USBPorts.kext so that the single kext accommodates multiple SMBIOS models. Edited September 19 by deeveedee 4 Link to comment Share on other sites More sharing options...
ird Posted September 20 Share Posted September 20 On 8/12/2024 at 5:35 PM, ird said: All the reading I've done so far seems to point to BlueToolFixup.kext as the culprit for incremental updates failing and forcing a full update (after of course, disabling SecureBootModel). Seems to be orthogonal to what SMBIOS one uses (so MacMini8,1 users should also see the same issue if they use BT). I will have to wait until Apple issues the next incremental update to confirm this theory. This theory is confirmed. I disabled SecureBoot as well as the 3 Bluetooth Kexts (IntelBTPatcher.kext, IntelBluetoothFirmware.kext and BlueToolFixup.kext) and Sonoma 14.7 incremental update worked just fine. Enabled secure boot as well as those BT kexts after the update. @deeveedee You may want to document this either in this thread or the master thread regarding incremental updates in case someone else is also scratching their heads like I was. 2 1 Link to comment Share on other sites More sharing options...
deeveedee Posted September 20 Author Share Posted September 20 (edited) @ird That is a known (or at least highly suspected) issue for BlueToolFixup.kext, but I can certainly add it to Known Issues the next time I update them. See other discussions like this. EDIT: I don't have Bluetooth enabled (only enabling it for testing and to help others). I'll leave it enabled and test with you to see if I can help to isolate the relationship between Bluetooth and OTA. Edited September 20 by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted September 23 Author Share Posted September 23 (edited) @ird EDIT: I have confirmed that incremental Sequoia updates fail with Bluetooth kexts. EDIT2: My Bluetooth-related config.plist entries are attached. Not pictured is the corresponding NVRAM Delete entries for bluetoothExternalDongleFailed and bluetoothInternalControllerInfo. Spoiler @EDIT3: Like you, I have confirmed that disabling BluetoolFixup.kext allows incremental macOS updates to complete without issues. I have reported the problem here and hope that someone has found the cause/solution (hopefully not simply disabling BluetoolFixup.kext). Edited September 23 by deeveedee 3 Link to comment Share on other sites More sharing options...
deeveedee Posted September 28 Author Share Posted September 28 (edited) The HP laptop SATA cable/connector works perfectly in this EliteDesk 800 G4 Mini. With the addition of this SATA solution and the m.2 slot 2 solution explained previously, all three available drive ports can be utilized (2 x m.2 and 1 x SATA) when the dGPU is installed. The HP laptop SATA cable/connector that I purchased has small tabs as shown. I trimmed the small tabs using a razor blade. After trimming the tabs, the SATA cable width perfectly matched that of an EliteDesk 800 G4 Mini SATA ribbon cable. Spoiler After trimming the tabs, I fed the new ribbon cable through the lock port on the back of the unit ( @ird's great suggestion) and inserted it into the SATA0 port. Be sure to enable SATA0 in BIOS. Spoiler The laptop SATA cable is plenty long enough to allow slack when the dGPU is installed. Spoiler With the cover installed, the SATA connector is easily accessible for use as a backup drive (e.g., Time Machine). For those who want a second SSD and who don't want to perform the dGPU surgery for a second m.2 drive, this SATA option may be a good solution for you. Spoiler NOTES: As installed above, the SATA cable does not have a strain relief (the internal connector is not designed for external use). There's plenty of slack to allow for cable movement, but don't pull the SATA cable far out of the back of the unit. Creating a strain relief for the SATA cable should be as easy as applying hot glue or similar to the SATA cable on the inner side of the lock port. The HP EliteDesk BIOS checks for the presence of the SATA caddy fan when a drive is connected to the SATA0 port. The cooling fan on the dGPU satisfies the BIOS requirement for the SATA caddy fan, so the BIOS does not throw a SATA caddy fan error on boot. You will notice that if you attempt to boot your EliteDesk Mini with the SATA drive, but without the SATA caddy fan or the dGPU fan, the BIOS will throw an error at boot. This SATA drive solution works perfectly. EDIT: For others who wish to purchase this cable, here's the description of what I purchased: "SATA Cable HP 17-by L22526-001 L22534-001 6017B0970101". My cost was under $7 USD with shipping. EDIT2: While it may be tempting to try a 3.5" SATA drive, it's not likely to work. 3.5" SATA drives typically have higher power requirements than 2.5" SATA drives (requiring additional power lines not present in our EliteDesk Mini SATA connector). I tried it and the 3.5" SATA drive didn't even power up. No harm done - it just didn't work. Edited September 28 by deeveedee 3 Link to comment Share on other sites More sharing options...
deeveedee Posted September 29 Author Share Posted September 29 For those who use it, SMCRadeonSensors.kext version 2.3.0 is available here. 2 1 Link to comment Share on other sites More sharing options...
deeveedee Posted October 1 Author Share Posted October 1 (edited) Closer inspection of the 35W and 65W EliteDesk 800 G4 Mini motherboards revealed additional circuitry differences that may explain why the 35W board does not POST after MOSFETs and Inductor Choke Coil are added to the top-side of the board. On the bottom-side of the 65W board in the space directly opposite the CPU Power MOSFETS is additional circuitry that is missing on the 35W board. The missing components have feature sizes that can be soldered with a heatgun. I would need to desolder the components from a 65W board and solder them onto a 35W board. Tempting... 65W Motherboard Spoiler 35W Motherboard (missing components) Spoiler EDIT: I am now seeing other differences between the populated components. For those who loved the "Spot the Difference" puzzles when you were growing up, this takes the game to a whole new level. Edited October 1 by deeveedee 3 Link to comment Share on other sites More sharing options...
deeveedee Posted October 6 Author Share Posted October 6 This is a commonly known fix, but I'll post it here for those who may not know about it. Now that we can dual-boot this hack with macOS and Windows (using separate NVMe SSDs for each OS), Windows Time and macOS Time are out-of-sync when using the default time sync settings of each OS. There are multiple ways to compensate for this time sync issue (adjusting the settings in macOS or in Windows). I prefer to make the time sync adjustment in Windows, but that's just my preference. Choose the method described here that works best for you. 1 Link to comment Share on other sites More sharing options...
ird Posted October 6 Share Posted October 6 (edited) 47 minutes ago, deeveedee said: This is a commonly known fix, but I'll post it here for those who may not know about it. Now that we can dual-boot this hack with macOS and Windows (using separate NVMe SSDs for each OS), Windows Time and macOS Time are out-of-sync when using the default time sync settings of each OS. There are multiple ways to compensate for this time sync issue (adjusting the settings in macOS or in Windows). I prefer to make the time sync adjustment in Windows, but that's just my preference. Choose the method described here that works best for you. Good tip. Btw, this will work for dual-booting any non-Windows OS with Windows (Linux+Windows etc.). In addition, if you have bluetooth devices paired in Mac and want to reuse them in Windows, I've found this guide to be useful. Edit: On a side note, registry key generation for both sync'ing time and BT keys is now supported in Hackintool as well, I believe. Edited October 6 by ird 1 Link to comment Share on other sites More sharing options...
deeveedee Posted October 8 Author Share Posted October 8 Flawless upgrade from Sequoia 15.1 Beta 5 to Beta 6. See details here. 3 Link to comment Share on other sites More sharing options...
deeveedee Posted October 9 Author Share Posted October 9 I'm currently using a SATA HD for Time Machine and it is working very well. I'm finding no issues with these instructions for adding a SATA drive to this hack. Link to comment Share on other sites More sharing options...
deeveedee Posted October 10 Author Share Posted October 10 (edited) I don't see any compelling reasons to upgrade to Open Core 1.0.2 from 1.0.1, so if you're happy with your hack, you can leave it alone. For those who want to upgrade to OC 1.0.2, the EFI changes are below. for the EFI attached to Post #1 are below. As of the writing of this post, the EFI attached to Post #1 is still based on OC 1.0.1 without any of the updates below. A new EFI based on Open Core 1.0.2 with the changes listed below is now attached to Post #1. Upgrading to Open Core 1.0.2 Upgrade BOOT/BOOTx64.efi Upgrade OC/OpenCore.efi Upgrade OC/Drivers/*.* (except HfsPlus.efi) Upgrade OC/Tools/*.* Upgrade OC/Kexts AppleALC.kext 1.9.1 -> 1.9.2 Lilu.kext 1.6.8 -> 1.6.9 RestrictEvents.kext 1.1.4 -> 1.1.5 VirtualSMC.kext 1.3.3 -> 1.3.4 SMCProcessor.kext 1.3.3 -> 1.3.4 SMCSuperIO.kext 1.3.3 -> 1.3.4 (not enabled in config.plist) WhateverGreen.kext 1.6.7 -> 1.6.8 SMCRadeonSensors.kext 2.2.0 -> 2.3.0 (not enabled in config.plist) OC/config.plist Add UEFI > Unload (Type: Array) If you are using Bluetooth, BluetoolFixup.kext 2.6.9 Beta -> 2.6.9 Release (not in the EFI attached to Post #1) Edited October 14 by deeveedee 1 1 Link to comment Share on other sites More sharing options...
deeveedee Posted October 12 Author Share Posted October 12 The EFI attached to Post #1 is now updated with Open Core 1.0.2 (full change log here in the previous post). 2 Link to comment Share on other sites More sharing options...
deeveedee Posted October 16 Author Share Posted October 16 (edited) I continue to experience a failed Ethernet connection with Microsoft Remote Desktop in Sequoia 15.1 Beta 7. As I mentioned earlier, a work-around is to toggle the active state of Ethernet before attempting the MS Remote Desktop connection to a remote Windows session. See details and solution here. I do not experience this in Sonoma. EDIT: I just learned that Slice has his own fork of IntelMausiEthernet here. I won't be in a position to test this kext until the 2nd week of November. Maybe this kext solves the Ethernet issues with i219LM and Sequoia 15.1? Note that I haven't tested the release version of 15.1 on this hack, so the Ethernet problem may be solved with 15.1 release. Edited October 30 by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted October 29 Author Share Posted October 29 (edited) I don't believe the i9-9900T will work on an EliteDesk 800 G4 Mini motherboard. See my EDIT and EDIT2 below. Leaving the full post for historical purposes. -------------------------------------------------------------- An experiment for those who are interested... @rcurley55 states here that his i5-9500T (9th Gen CPU) works on an EliteDesk 800 G4 Mini 35W motherboard. According to HP, the 9th Gen CPU codes are not in the G4 Mini BIOS, so my guess is that the 9th-Gen 35W "T" CPUs are an exception to this rule for some reason. At the request of someone in the TonyMacx86 forum, I had tested an i7-9700 (65W TDP) CPU on a 65W EliteDesk 800 G4 Mini motherboard and the system would not POST. That was at least two years ago with an older BIOS, so maybe HP added the 9th Gen CPU codes to the G4 Mini BIOS? If this works, adding an i9-9900T CPU to a 35W EliteDesk 800 G4 Mini motherboard may be an easy CPU upgrade. I'll be interested to learn about test results from others. EDIT: If someone wants to double-check this theory, that would be helpful... the DeviceID for "9th Gen" i5-9500T CPUs is 0x3e92 which is the same as "8th Gen" CPUs. The DeviceID for the i9-9900T is 0x3e98. It appears to me that i5-9500T CPU is actually repackaged 8th Gen. EDIT2: Further inspection reveals that other "9th Gen" i5 CPUs have a Device ID of 0x3e92, while the "9th Gen" i7 and i9 CPUs have a DeviceID of 0x3e98. It is very possible that Intel pulled a fast one and repackaged 8th Gen CPUs for the "9th Gen" i5 models. This seems very possible, since 9th Gen i5s are 6-core, just like 8th Gen. Edited October 31 by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted Tuesday at 01:02 PM Author Share Posted Tuesday at 01:02 PM (edited) Sequoia 15.2 Beta 24C5079e appears to have fixed the Ethernet connectivity issues that I experienced with previous Sequoia Betas when attempting remote desktop connections to Windows PCs. This Ethernet connectivity issue has come and gone with previous Sequoia Betas, so I will continue to monitor. The upgrade to Sequoia 15.2 Beta 24C5079e was flawless after temporarily disabling BluetoolFixup.kext. EDIT: Note that Slice's fork of IntelMausiEthernet.kext did not resolve the Ethernet connectivity issue in previous Sequoia Beta versions. I am currently using the OC 1.0.2 EFI attached to Post #1 (with Acidanthera's IntelMausi.kext v. 1.0.7). Edited Tuesday at 01:06 PM by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted 11 hours ago Author Share Posted 11 hours ago macOS 15.2 Beta (24C5089c) has reintroduced the Ethernet issue. See details and remedy here. 2 1 Link to comment Share on other sites More sharing options...
Recommended Posts