Contribute
Register

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

Status
Not open for further replies.
Yes, I did put SSDT-DTPG.aml and the SSDT-X299-TB3HP.aml you attached into the patched folder in the ACPI folder (as shown in the pictures attached), here are the results of trying your advice.

The thunderbolt SSDT crashes to load at boot, as it expects PCI0.RP05.PXSX in the original ACPI table of the Deluxe II and not PCI0.RP05.XHC3 like in your case!

386295


You must have at some place a PCI0.RP05.PXSX -> PCI0.RP05.XHC3 replacement that should not be implemented at all! Check your config.plist if you subsequently added some PXSX -> XHC3 ACPI replacement in Section "ACPI" of Clover Configurator in addition, which anyway would be a no-go as it would apply to any PXSX devices implemented in your system's ACPI table! Or do you use any other SSDT in your EFI-Folder that does the PCI0.RP05.PXSX -> PCI0.RP05.XHC3 replacement? PCI0.RP05.XHC3 makes absolutely no sense in any case, as the original TB ACPI table on the Deluxe II is PCI0.RP05.PXSX, and the TB-SSDT is configured such that it will exclusively work with the original and unmodified TB ACPI table of the Deluxe II.

Due to this persistent error in your system configuration (without any TB-SSDT implemented), the TB-SSDT just fails to load on your system at boot (as it expects PCI0.RP05.PXSX and not PCI0.RP05.XHC3 in the originally implemented ACPI table the Deluxe II) and your IOREG.saves with and without the TB-SSDT therefore exactly show the same result (see below), as the TB-SSDT is currently simply ignored by macOS due to the persistent flaw in your EFI-Folder configuration!

386296


If you are not able to find and remove the flaw in your EFI-Folder configuration, please upload your EFI-Folder that I can do it for you.

EDIT: BTW.. Do you use SSDT-X299-XHC.aml for the ASUS Prime X299 Deluxe implemented in the X299 Github repository without any necessary adaptation for the ASUS Prime X299 Deluxe II?

Then I already found the flaw in your EFI-Folder configuration! The respective SSDT implements the PCI0.RP05.XHC3 XHC Controller of the ASUS Prime X299 Deluxe, which however is the TTR onboard controller in case of the ASUS Prime X299 Deluxe II!!

Thus, properly adopt SSDT-X299-XHC.aml for the ASUS Prime X299 Deluxe II and at least remove the PCI0.RP05.XHC3 XHC Controller for the ASUS Prime X299 Deluxe, which is invalid for the ASUS Prime X299 Deluxe II!

Remove at least

386320


and

Code:
    Scope (\_SB.PCI0.RP05)
    {
        Scope (PXSX)
        {
            Name (_STA, Zero)  // _STA: Status
        }

        Device (XHC3)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg2, Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                          
                    })
                }

                Store (Package (0x1B)
                    {
                        "AAPL,slot-name",
                        Buffer (0x09)
                        {
                            "Built In"
                        },

                        "built-in",
                        Buffer (One)
                        {
                             0x00                                          
                        },

                        "device-id",
                        Buffer (0x04)
                        {
                             0x42, 0x21, 0x00, 0x00                        
                        },

                        "name",
                        Buffer (0x17)
                        {
                            "ASMedia XHC Controller"
                        },

                        "model",
                        Buffer (0x2E)
                        {
                            "ASMedia ASM3142 #2 2x USB 3.1 Type-A External"
                        },

                        "AAPL,current-available",
                        0x0834,
                        "AAPL,current-extra",
                        0x0A8C,
                        "AAPL,current-in-sleep",
                        0x0A8C,
                        "AAPL,max-port-current-in-sleep",
                        0x0834,
                        "AAPL,device-internal",
                        Zero,
                        "AAPL,clock-id",
                        Buffer (One)
                        {
                             0x01                                          
                        },

                        "AAPL,root-hub-depth",
                        0x1A,
                        "AAPL,XHC-clock-id",
                        One,
                        Buffer (One)
                        {
                             0x00                                          
                        }
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }
        }
    }

from SSDT-X299-XHC.aml when using the latter with the Deluxe II! However, note that SSDT-X299-XHC.aml might need additional modifications independent from your actual TB-issue when used with the Deluxe II. If you don't know how to properly adapt SSDT-X299-XHC.aml for the Deluxe II, please upload an IOREG.save without SSDT-X299-XHC.aml in your EFI-Folder and I can do it for you.
 
Last edited:
@AsEvil,

I guess I already found the persistent flaw in your EFI-Folder even without having the latter available at all... ;)

See Edit/Update at the end of post #1,684 !
 
@ kgp:
It would appear that the Radeon VII does not support UEFI.
See:
 
The GPU-Z software may act to narrow down the possibilities of where the fault lies: Radeon VII vs. the ASUS motherboard. There are several Youtube reviews of the Radeon VII, and none of those have mentioned being forced to run in CSM enabled mode. Those reviews are not using an Intel X299 chipset board, however.

@DSM2 was extracting the VII BIOS..

No UEFI GOP!
 
@ kgp:
It would appear that the Radeon VII does not support UEFI.
See:

Yes.. As already stated on Friday... the Readon VII is fully Legacy and does not support at all UEFI.

No UEFI GOP in BIOS. Now also confirmed by the posts provided in your link.

What a crap and mess by AMD!
 
Last edited:
Agreed, a modern card with no UEFI. From the latest reviews they seemed to have rushed the card out without decent windows drivers too. The reviewers can’t say good things if it doesn’t work.
PCIe 4.0 with legacy bios? WTH!
 
  • Like
Reactions: kgp
@kgp
Good News! Well somewhat good news, I got acceleration using Vega 12 but its only 20 CUs. Got Metal!

IOReg. iMac Vega V II acellerator.ioreg

386477


Some benches, they are sub par but it is working at 33% of usable Compute Units.

386478
386479


386480
386481
 

Attachments

  • iMac Vega V II acellerator.ioreg
    4.7 MB · Views: 99
  • Like
Reactions: kgp
Update: I got 60 CUs. Basically Vega 56 performance. Link

Attached files will work for the card. Clover needs to be in Legacy boot mode not UEFI. Replace the info.plist of AMD5000kext and AMD5000HWServiceskext and run Kext wizard or other method to rebuild caches. SSDT courtesy of kgp needs to go into Clover/ACPI/Patched folder. Next step to make VGATabkext for frequency.

386502

386503
386504
 

Attachments

  • Radeon VII fixes.zip
    4 MB · Views: 76
Last edited:
Status
Not open for further replies.
Back
Top