iMac Pro X299 - Live the Future now with macOS 10.14 Mojave [Successful Build/Extended Guide]

[kgp]

@kgp
I am now using the latest EFI folder in #1,735

The USB-C driver seems missing in your PCI snapshot, although XHC3 is properly implemented in your IOREG.save of your systems ACPI table. Reason?

Else your Nvme properly pops-up under DSB1 and the respective driver is also loaded in your PCI snapshot.

Thus following your IOREG.save at least the TB ACPI table seems properly implemented.

All ETH devices are properly implemented

HDEF, GFX0 and HDAU are properly implemented

Decklink is properly implemented

For XHCI you again seem to just use 15-port kext, although else XHCI is also properly implemented

XHC2 is properly implemented.

PMC, SAT1 and TSSH are properly implemented

You suddenly seem to have another NVMe under PC03.BR3D.SLOC though, thus please use the modified SSDT-X299-ANS.aml.zip attached below and report back with new IOREG.save and PCI snapshot after revision of remaining discrepancies mentioned above.

 

[kgp]

@trueadm, please see my recent updates and edits in post #1,763.

 

[AsEvil]

I am sorry that I could not report back immediately since the hackintosh is in my office and I am not with it to test when you replied, but I will always report back as soon as I can!!!

To conclude your replies, I also want to make sure what to test when I return to my office:

USB-C ports of onboard TTR controller only should pop-up under XHCI with Alpine Ridge XHCI WA Enabled in BIOS.. Please disable!

I asked you to check if the USB-C ports of the onboard TTR controller still pop-up under XHCI with Alpine Ridge XHCI WA Enabled.

Thus, if now with the new EFI-Folder you want to check what I asked for already in post #1,732, you just have to reimplement HS09 and HS10 to the kext. I anyway enabled the 3 valid USB port limit patches and the fully implemented kext for now in your EFI-Folder for testing purposes.

1. With the new EFI folder, I should reimplement HS09 and HS10 to the kext and see if the USB-C device will appear under HS09 and HS10 or not in the IOreg, right? To test this, I should also enable "Alpine Ridge XHCI WA", which is disabled now?

You suddenly seem to have another NVMe under PC03.BR3D.SLOC though, thus please use the modified SSDT-X299-ANS.aml.zip attached below and report back with new IOREG.save and PCI snapshot after revision of remaining discrepancies mentioned above.

2. The another NVME is a testing system drive with macOS, I put it on only to copy some applications to the current one. However, I should still test the new ANS.aml and upload the IOreg.save and PCI snapshot.

As for the USB-C driver:

The USB-C driver seems missing in your PCI snapshot, although XHC3 is properly implemented in your IOREG.save of your systems ACPI table. Reason?

Seriously, I do not know why the USB-C drivers are gone now. In today's test, the USB-C SSD suddenly cannot be detected by the system. I will test more on the USB-C drive.

 

[kgp]

I am sorry that I could not report back immediately since the hackintosh is in my office and I am not with it to test when you replied, but I will always report back as soon as I can!!!

To conclude your replies, I also want to make sure what to test when I return to my office:







1. With the new EFI folder, I should reimplement HS09 and HS10 to the kext and see if the USB-C device will appear under HS09 and HS10 or not in the IOREG, right? To test this, I should also enable "Alpine Ridge XHCI WA", which is disabled now?




2. The another NVME is a testing system drive with macOS, I put it on only to copy some applications to the current one. However, I should still test the new ANS.aml and upload the IOreg.save and PCI snapshot.

As for the USB-C driver:


Seriously, I do not know why the USB-C drivers are gone now. In today's test, the USB-C SSD suddenly cannot be detected by the system. I will test more on the USB-C drive.

ad 1.) Partly yes.. You should enable implemented USB port limit patches, use the fully implemented kext zipped in your EFI-Folder and properly implement HS09 (9) and HS10 (9) in the latter. Then you should DISBALE "Alpine Ridge XHCI WA" and see if the TTR ports still pop-up under HS09 and HS10 of XHCI.

ad.2) Did you add the new NVMe in the second M.2 onboard slot or did you add the new NVMe by means of an additional PCIe adapter in any PCIe slot of your Deluxe II? If the primer is the case, the new ANS-SSDT is of general interest for all Deluxe II users and should remain included during all ongoing tests, which also states for your second NVMe recently added.

From all former tests with @applemacosxGOD it seems necessary to connect a USB-C device at boot for populating DSB2 with XHC3 entries and to successfully load also the respective TTR USB-C PCI driver. Afterwards one also should be able to at least hot swap USB-C devices.

You really should properly initialise and verify the functionality of your TTR onboard controller and its 2 ports with TB and USB-C devices under Windows before performing any tests under macOS. If the TTR onboard controller is not properly initialised once and not performing as expected, all test results obtained under macOS are useless anyway.

Also ensure that the IOREG.saves and PCI snapshots you will upload now and in the future, are really taken at same instance and do not represent different system states or different temporal instances.

 

[trueadm]

Apparently just adding 0x66AF1002 to AMDRadeonX5000.kext seems not sufficient with UEFI Clover and/or the new UEFI firmware for the VII.. Black screen on boot after adding 0x66AF1002 to IOPCIMatch of AMDRadeonX5000.kext, independent from all available macOS versions in use. I already checked that. And device-ID 0x66AF1002 is natively even already part of IOPCIMatch in AMD10000Controller.kext and AMDRadeonX5000HWServices.kext under 10.14.3 and 10.14.3 SU.

Thus it appears that the approach of simply adding 0x66AF1002 to IOPCIMatch of AMDRadeonX5000.kext as proposed by @Gigamaxx indeed seems to work only in case of Legacy and there is something else missing to be changed in either AMD10000Controller.kext, AMDRadeonX5000.kext, AMDRadeonX5000HWServices.kext, WEG, Clover, or config.plist to enable hardware acceleration under macOS for the VII based on the current AMDRadeonX5000.kext AMDVega10GraphicsAccelerator or AMDVega12GraphicsAccelerator implementations in case of UEFI. Else one could just wait until the VII has been finally fully natively implemented under macOS by Apple in order to see that the recently added UEFI GOP in the new ASRock VII hybrid firmware is also fully compatible with macOS.

@vit9696 or @sLice, anything else that needs to be considered in terms of WEG or UEFI Clover for using the VII with the hybrid ASRock firmware and UEFI GOP under macOS as currently implemented and outlined above?

I've just tried now to boot into Clover with legacy mode (removed EFI/Clover directory and re-installed it from Multibeast -> Legacy mode). Unfortunately, I don't get past the Apple logo when booting up. If I swap back to UEFI, then I can get back into macOS fine. I think maybe the only thing to do is wait for official drivers :/

 

[kgp]

I've just tried now to boot into Clover with legacy mode (removed EFI/Clover directory and re-installed it from Multibeast -> Legacy mode). Unfortunately, I don't get past the Apple logo when booting up. If I swap back to UEFI, then I can get back into macOS fine. I think maybe the only thing to do is wait for official drivers :/

Waiting for the correct native macOS implementation of the VII by Apple is definitely the most correct and appropriate approach!

But wait.. are you saying that you can boot into macOS now with UEFI after adding 0x66AF1002 to AMDRadeonX5000.kext?

This is what does not work in my case and I am stocked at the Apple Logo and progress bar that usually pops-up for one second after else verbose boot with -v, just immediately before entering the macOS login screen.

Did you do any additional step after replacing the plist of AMDRadeonX5000.kext with the modified one?

I am just using the modified AMDRadeonX5000.kext in my EFI-Folder, thus it should also not be a question of permissions either, which anyway can be easily fixed by means of Kext Wizard after directly modifying the kext in /S/L/E.

I can only boot into macOS without the 0x66AF1002 in AMDRadeonX5000.kext, like currently implemented in any default macOS distribution. However, no hardware acceleration in this case and Vii just recognised and partly implemented as Vega in any case.

 

[trueadm]

Waiting for the correct native macOS implementation of the VII by Apple is definitely the most correct and appropriate approach!

But wait.. are you saying that you can boot into macOS now with UEFI after adding 0x66AF1002 to AMDRadeonX5000.kext?

This is what does not work in my case and I am stocked at the Apple Logo and progress bar that usually pops-up for a second after else verbose boot with -v, just immediately before entering the macOS login screen.

Did you do any additional step after replacing the plist of AMDRadeonX5000.kext with the modified one?

I am just using the modified AMDRadeonX5000.kext in my EFI-Folder, thus it should also not be a question of permissions.

Sorry I wasn't clear – I have the same issue as you. Adding 0x66AF1002 never lets met get past the Apple Logo and progress bar in UEFI mode - it gets to 100% but stays there forever and nothing happens.

I meant, in my previous post, that when I tried using Legacy mode with Multibeast, that also doesn't work – even without changing any plist files. I just see an Apple logo on a black screen on startup, the progress bar doesn't even show at all. I did flash my Radeon VII bios to the ASRock one though, so that might be why it doesn't work in legacy mode anymore?

Did you get the plist change (with 0x66AF1002) working with legacy mode? This is all a bit frustrating. Mojave is barely usable in most applications without hardware acceleration.

 

[kgp]

Sorry I wasn't clear – I have the same issue as you. Adding 0x66AF1002 never lets met get past the Apple Logo and progress bar in UEFI mode - it gets to 100% but stays there forever and nothing happens.

I meant, in my previous post, that when I tried using Legacy mode with Multibeast, that also doesn't work – even without changing any plist files. I just see an Apple logo on a black screen on startup, the progress bar doesn't even show at all. I did flash my Radeon VII bios to the ASRock one though, so that might be why it doesn't work in legacy mode anymore?

Did you get the plist change (with 0x66AF1002) working with legacy mode? This is all a bit frustrating. Mojave is barely usable in most applications without hardware acceleration.

Oh I see.. No, I do not use Legacy Clover at all.. Everything including my BIOS settings is fully UEFI.

I fully agree to wait with further tests and conclusions until the VII is correctly and fully natively implemented within macOS by Apple.

 

[kgp]

@kgp on your 10.14.3 su, do you the MacOs Public Beta Access Utility? can you see the 10.14.4 beta 2 update?

Apparently the last days and still for now, 10.14.4 seems excluded from Apple's seed. No way to update in the usual way.

 

[rugula]

Aquantia firmware flash success. Have only tested with Windows, however. Can't comment on macOS usage.
In summary:
Unplug the ethernet cable going to the Aquantia LAN port.
Use "diag -k -p" to first check the existing firmware version.
Use "diag -k -f DellNormalDirtyWake-3.1.56_bdp.clx --phy_flash_bdp" to perform the flash.
Shut down the system, use the PSU rocker switch to turn off power, then press and hold the front case power button for a few seconds.
Flip the PSU power switch back on and reboot Windows.
Go to Device Manager and uninstall the Sources/Aquantia device.
Re-install the Aquantia device driver, and check that it is again present under Network Adapters.
Plug in the ethernet cable.