Contribute
Register

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

Status
Not open for further replies.
That's absolutely gorgeous, man! :clap::clap::clap: removes all resolution issues and makes SwithResX basically obsolete..



View attachment 386659

interesting resolution you're being offered here: 3008x1269, I don't get this in the list:
5120x2160
3840x1620
3360x1417 (The one I use)
2560x1080
2048x864

those are also the resolution I get when I connect the screen via TB3 to the mac.

Oh, using the RDM utility, I do see this resolution.
 
interesting resolution you're being offered here: 3008x1269, I don't get this in the list:
5120x2160
3840x1620
3360x1417 (The one I use)
2560x1080
2048x864

those are also the resolution I get when I connect the screen via TB3 to the mac.

Oh, using the RDM utility, I do see this resolution.

UI resolution of 3008x1269 (60Hz) seems optimal for this monitor even. That's why I placed it first.

Maybe I have it due to SwitchResX in the background..

386662


I do not use these SwitchResX resolutions but the available scalings in system preferences.

386663


SwitchResX might still contribute with these settings:

386664


386665


386666


BTW.. me and my friend exchanged now Sapphire Radeon VII and Nitro+ Vega 64 for three weeks and testing purposes. :p.. The Sapphire Radeon VII is now in my old X99 system, because on X299 I still have the Nitro+ Vega 64 with water blocking.

386671
 
Last edited:
@kgp ;) and all,

AMD is releasing an official UEFI update for Radeon VII.


Well, their only choice.. ;):p

Thanks for these very positive news!
 
I’m just going to cancel my Radeon VII order since there’s no waterblock for another 5-6 weeks from EKWB.

Can’t stand fan noise :thumbdown

Enjoy guys looking forward to seeing results here :thumbup:
 
I’m just going to cancel my Radeon VII order since there’s no waterblock for another 5-6 weeks from EKWB.

Can’t stand fan noise :thumbdown

Enjoy guys looking forward to seeing results here :thumbup:

The VII, is exactly the same as the Vega 20 (same product id btw), just higher clock rate. Same Vega architecture (just 7nm print). New model is coming soon. I'd wait anyway, even if the waterblocks were available.
 
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!

View attachment 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!

View attachment 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

View attachment 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.

@kgp Yor are right!!! After I removed the lines in the SSDT-X299-XHC.aml or totally removed SSDT-X299-XHC.aml from the patched folder, the PCI list in system report correctly shows the GC-Titan Ridge TB 3 NHI information (screenshot A). But USB-C information only shows when there is a USB-C device plugged before the OS boots (screenshot B).

And I found out that one guess from your previous post is correct. HS09 and HS10 on ASUS Prime X299 Deluxe II are for the USB 2.0 ports of the onboard TB/USB-C port. (screenshot C) But like what you have said, the USB-C ports are mainly for USB 3.1 devices, the USB 2.0 port (HS09&HS10) is not really important at all.

I do not know how to adapt the XHC.aml for the Deluxe II and I think I need your help on this, Thank you in advance!!!

Also, I am facing a new problem now... After I clean installed 10.14.3, strangely, the USB kext I created does not work anymore. I know there are three new USB port limit patches for 10.14.3 and enabled them, but still, the USB 3.0 ports work at USB 2.0 speed... Can this problem be also related to incorrect XHC.aml implementation?
 

Attachments

  • A.png
    A.png
    797.9 KB · Views: 61
  • AsEvil's Hackintosh (with USB kext).ioreg
    14.4 MB · Views: 70
  • AsEvil's Hackintosh (Without USB kext).ioreg
    15.2 MB · Views: 64
  • B.png
    B.png
    551.3 KB · Views: 61
  • C.png
    C.png
    2.2 MB · Views: 68
  • AsEvil-10.14.3-EFI.zip
    35.6 MB · Views: 181
The VII, is exactly the same as the Vega 20 (same product id btw), just higher clock rate. Same Vega architecture (just 7nm print). New model is coming soon. I'd wait anyway, even if the waterblocks were available.

Yeah I hate the Vega fan curve and from reviews it seems it hasn’t changed much in terms of noise.

Also from what we have seen AMD has said there won’t be custom PCBs from AIBs so the reference design is what we get.
 
@kgp Yor are right!!! After I removed the lines in the SSDT-X299-XHC.aml or totally removed SSDT-X299-XHC.aml from the patched folder, the PCI list in system report correctly shows the GC-Titan Ridge TB 3 NHI information (screenshot A). But USB-C information only shows when there is a USB-C device plugged before the OS boots (screenshot B).

And I found out that one guess from your previous post is correct. HS09 and HS10 on ASUS Prime X299 Deluxe II are for the USB 2.0 ports of the onboard TB/USB-C port. (screenshot C) But like what you have said, the USB-C ports are mainly for USB 3.1 devices, the USB 2.0 port (HS09&HS10) is not really important at all.

I do not know how to adapt the XHC.aml for the Deluxe II and I think I need your help on this, Thank you in advance!!!

Also, I am facing a new problem now... After I clean installed 10.14.3, strangely, the USB kext I created does not work anymore. I know there are three new USB port limit patches for 10.14.3 and enabled them, but still, the USB 3.0 ports work at USB 2.0 speed... Can this problem be also related to incorrect XHC.aml implementation?

One thing after the other my friend. Let's focus first on the onboard TTR controller and then investigate your USB issues.

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

Also disable Thunderbolt USB Support, Thunderbolt Boot Support and Wake From Thunderbolt(TM Devices).

Does this remove the XHCI HS09/HS10 relation of the onboard TTR controller? See respective ACPI table in IOREG!

What about TB Hotplug?
 
@AsEvil , also please upload an IROEG.save of your system's ACPI table without WEG.kext and without any SSDT in your EFI-Folder at boot.
 
Status
Not open for further replies.
Back
Top