kgp
Retired
- Joined
- May 30, 2014
- Messages
- 6,743
- Motherboard
- ASUS WS X299 Sage 10G
- CPU
- i9-7980XE
- Graphics
- Vega 64
- Mac
- Mobile Phone
These patches have been a combination of work between myself and the great 'apfelnico'
the PC00 - 5 renames are for all the PCI slots, this however depends on the board and could potentially vary. This could also depend on how many PCI slots are being used.
The USB rename for EC0 to EC is vital for proper USB power management and to get 2.1A charging working, however I haven't yet managed to get 2.1A fast charging working. I have tried using USBX SSDT with no luck.
H_EC is an alternative name and does not exist on our board, however it could be on other boards.
DSM -> XDSM is vital otherwise without it the main SSDT will not load
Graphics rename SL05 -> GFX0 is to be consistent with the iMac 17,1 SMBios which has discreet graphics as GFX0 and integrated graphics as iGPU (our X299 platform does not have this). If using the Mac Pro 6,1 definition this instead has to be GFX1
The ethernet patches are purely cosmetic and make more sense, the name is from 'apfelnico'
PMC1 to PMCR rename is again to be consistent with names on real Macs and SSDT has device details
FPU_->MATH, TMR_->TIMR, PIC_->IPIC all are simply renames to be consistent with real Macs. Nothing is being loaded under these names on either our X299 board or real Mac.
Yes that is correct, I began by making individual SSDTs for each component and with 'apfelnico' help joined them into one. Apfelnico incorporated many beneficial aspects and this big SSDT would not be possible without his hard work.
After extensive testing, my build could not sleep with SMBus properties injected. I spoke with RehabMan, and since removed LPCB (AppleLPC injection) and SMBus properties as they are unnecessary on our modern hardware.
LPCB rename is done to be consistent with real Mac names (after speaking with RehabMan, AppleLPC is not required therefore there is no need to inject anything apart from rename)
NOTE: The vast majority of these renames are specific to our Asus X299 Prime Deluxe motherboard and will vary from vendor. If you plan to use these for your Gigabyte board etc, examine IOReg prior to renaming as exact names could be different. With our platform, there is no one size fits all.
The additional drop tables have been the work of 'apfelnico'. However apart from 'DMAR' and 'CpuPm', are unnecessary. Until further testing the others are not required.
Now regarding audio, I am working on building a custom version of CodecCommander using PinConfigOverride data generated in Windows. This will take some time and a lot of testing for our 0x10ec1168, ALC 1120A audio controller.
I am also trying to get SSDT-XCPM to work for our system, according to RehabMan this should be possible. Again this will take some time for me. I experience this tiny amount of lag occasionally if I don't put the system to sleep, after sleep the issue seems to be gone. I believe this has something to do with our CPU power management and should be resolved in future builds when we can use the .
I want to thank 'apfelnico' for his work, advice, ideas and support
PS. The reason you were signed out of iCloud was because of the rename to ETH0 and ETH1. Also I found that I had to manually modify the 'NetworkInterfaces.plist' file to have en0 in either the i219 or i211 adapter. After doing that I have been able to use iCloud services with no issues whatsoever.
To do list:
- 2.1A USB fast charging
- ALC1120A Audio after sleep using CodecCommander
- RehabMans SSDT-XCPM power management using our i9s native '0x050654' CPU ID without any XCPM bootstrap patches or VoodooTSC sync
@TheOfficialGypsy , @ALL ,
the PC0 -> PCI replaces can indeed only be performed for the populated PCI slots of the ASUS Prime X299 Deluxe! If your perform PC0 -> PCI replacements of unpopulated PCI slots your rig won't boot!
In my case PCI0, PCI2, and PCI3 are populated.
Thus, in my case I had had to perform DSDT replacement patches PC00 -> PCI0, PC02 -> PCI2, and PC03 ->PCI3, in contrast yo your initial instructions instruction to implement DSDT replacement patches PC00 -> PCI0, PC01 -> PCI1, PC02 -> PCI2, and PC03 ->PCI3!
However, yet I still ask myself how the proper PC0 -> PCI replacement relates with AppleALC.kext. Could you please explain the latter relation, if there is any? My suspicion is that there is no relation at all and that the PC0 -> PCI replacement is not required for a successful AppleALC audio implementations in contrast to your earlier instructions.
In any case, now the APCI Tables are correctly implemented, the system boots flawless and Apple's System Report correctly reveals:
When using Lilu.kext v1.1.7 and AppleALC.kext v1.1.4, even analogue audio is properly implemented:
While Lilu.kext v1.2.0 works just fine with all other related plugins, AppleALC.kext v1.2.0 yields on my system a boot kernel panic system under 10.13 High Sierra. Surprisingly, the combination of Lilu.kext v1.2.0 and AppleALC.kext v1.2.0 works fine under 10.12.6, while neither the ACPI Table nor the SSDT-X299.aml seems to apply!
What could be the reason for the AppleALC.kext v1.2.0 Kernel Panic under 10.13? Any helpful comments would be extremely appreciated! We both have the same board, this it is enological that AppleALC.kext v1.2.0 works fine on your case and fails in my case..
This in conclusion 3 main questions:
a.) How does the proper PC0 -> PCI replacement relates with AppleALC.kext? Could you please explain the latter relation, if there is any? My suspicion is that there is no relation at all and that the PC0 -> PCI replacement is not required for a successful AppleALC audio implementations in contrast to your earlier instructions.
I would need your immediate reply, as currently the AppleALC audio approach is still implemented in my guide with the PC00 -> PCI0, PC01 -> PCI1, PC02 -> PCI2, and PC03 ->PCI3 replacement dependency, which is simply wrong, as first the PC0 -> PCI replacement can very like just successfully applied for ASUS Prime X299 Deluxe, and secondly the PC0 -> PCI replacement cannot be generalised to PC00 -> PCI0, PC01 -> PCI1, PC02 -> PCI2, and PC03 ->PCI3, as the PC0 -> PCI replacement apparently depends on the actual PCIe slot population!
I have to urgently update my guide concerning this open issue! The currently implemented description of the AppleALC audio approach is strongly misleading and wrong! It has to potential to make nearly all systems unbootable!
b.) Do you see any possibility for solving the AppleALC.kext v1.2.0 issue on my system?
c.) Do you see any possibility for extending your ACPI Table nor the SSDT-X299.aml to 10.12.6?
Cheers,
KGP
Last edited:
