How to build your own iMac Pro [Successful Build/Extended Guide]

[kgp]

I think I made a mistake with dual ultrawide 38s, but I guess I will see in 1 month haha.

I always saw ultrawides as a gimmick. Dual 27" or 32" 4k would be much nicer.

Well I would not say that a 34 inch 5120 × 2160 WUHD is a gimmick.. I personally love WUHD displays.. but of course taste is different and also always depends on the kind of application.

 

[mm2margaret]

I don't think anyone's doing x2160 with ultrawides yet...maybe one of these days.

AOC is, C4008VU8,......https://www.bhphotovideo.com/c/product/1317281-REG/aoc_40_c4008vu8_4k_ultra.html

As an Editor, I was quite tempted, BUT, it is a VA panel, and I want IPS at a minimum or OLED (that would be just fantastic - but pricey...)

 

[mm2margaret]

AOC is, C4008VU8,......https://www.bhphotovideo.com/c/product/1317281-REG/aoc_40_c4008vu8_4k_ultra.html

As an Editor, I was quite tempted, BUT, it is a VA panel, and I want IPS at a minimum or OLED (that would be just fantastic - but pricey...)

Here's my requirement for my next Monitor, from someone who works in Premiere, Resolve, and After Effects every day....

• 5120 x 2160 (I would consider a 3840x2160)....
• Multiple Refresh rates, equal to 60 hz and some above that level
• 10 bit color
• HDR
• Curved screen
• Greater than or equal to 35 inches
• IPS screen OR Oled
• Speakers (10 watt or greater)

 

[Zephlon]

@kgp I am running into an issue updating the SSDT with your latest updates for PCI implementation.

ORIGINAL | Implementing the SSDT device header like this works:

Scope (\_SB.PCI0.ETH0)
    {
      ...

NEW | While implementing with the expanded header as seen in the new SSDT from you, does not work:

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

        Device (ETH0)
        {
          ...

Any thoughts of why the newer expanded headers are not working?
Is there something different that needs to be applied before the new device headers can function?

I have attached the "Original" and "New" SSDT of a single device being implemented to see if you spot anything. The "original" works, showing ethernet in PCI, while the "new" ssdt shows no ethernet devices in PCI.

Would love to implement newer PCI items found in your latest SSDT (such as HDMI audio and thermal control) which use this new header system.

NOTE: as per your most recent example, the DTPG is found in a seperate .aml file

Thanks for this great build and your help in troubleshooting!

 

[kgp]

@kgp I am running into an issue updating the SSDT with your latest updates for PCI implementation.

ORIGINAL | Implementing the SSDT device header like this works:

Scope (\_SB.PCI0.ETH0)
    {
      ...

NEW | While implementing with the expanded header as seen in the new SSDT from you, does not work:

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

        Device (ETH0)
        {
          ...

Any thoughts of why the newer expanded headers are not working?
Is there something different that needs to be applied before the new device headers can function?

I have attached the "Original" and "New" SSDT of a single device being implemented to see if you spot anything. The "original" works, showing ethernet in PCI, while the "new" ssdt shows no ethernet devices in PCI.

Would love to implement newer PCI items found in your latest SSDT (such as HDMI audio and thermal control) which use this new header system.

NOTE: as per your most recent example, the DTPG is found in a seperate .aml file

Thanks for this great build and your help in troubleshooting!

Pleas note the following:

1.) For editing, please use the MaciASL.app recently attached to my guide.

2.) Further note, that quite some time ago, most ACPI replacements have been part of the config.plist, e.g. also the GBE1 -> ETH0 replacement, while within my latest system SSDT distributions, the ACPI replacements are mostly directly performed within the system SSDT, e.g.

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

        Device (ETH0)

You therefore have to remove the respective ACPI replacements, e.g. GBE1 -> ETH0 from the config.plist! I encourage to simply use my most recent EFI-Folder distribution, which already accounts for the necessary respective changes in the config.plist.

I hope this helps, man.

Good luck!

 

[Zephlon]

Pleas note the following:

1.) For editing, please use the MaciASL.app recently attached to my guide.

2.) Further note, that quite some time ago, most ACPI replacements have been part of the config.plist, e.g. also the GBE1 -> ETH0 replacement, while within my latest system SSDT distributions, the ACPI replacements are mostly directly performed within the system SSDT, e.g.

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

        Device (ETH0)

You therefore have to remove the respective ACPI replacements, e.g. GBE1 -> ETH0 from the config.plist! I encourage to simply use my most recent EFI-Folder distribution, which already accounts for the necessary respective changes in the config.plist.

I hope this helps, man.

Good luck!

Thank you for the quick response @kgp . Copying the entire EFI folder anew worked. The issue was in the ACPI still being implemented within the config.plist and conflicting with the SSDT implementations.

All is working!

 

[apfelnico]

In that case I would rather work with the Clover patch, "GBE1 -> ETH0".
If you only work with the SSDT, the existing device "GBE1" is hidden and a new device "ETH0" is inserted in the same place. This works great with many other devices. The problem here is that there are other connections to this device in the DSDT that will be interrupted:

    Scope (_GPE)
    {
        Method (_L6D, 0, Serialized)  // _Lxx: Level-Triggered GPE
        {
            \_SB.PC00.XHCI.GPEH ()
            \_SB.PC00.CAVS.GPEH ()
            \_SB.PC00.GBE1.GPEH ()
        }
    }

That does not happen with the Clover patch. Here all entries in the ACPI (including DSDT) are exchanged, all links thus remain active.

 

[panos-s]

Hello ppl, im having a problem with audio input,
my headphone microphone isn't identified from the system preferences in sound,
the audio works fine tho, I mean I can hear music all good.
But in the audio input I see the front and rear pink inputs as options but the levels move as creasy and when I plug the microphone its not recognised, anything I can do to fix it?
Also I used the multybeast to install the voodooHDA drivers, can this be the problem???

Thanks

 

[apfelnico]

Also I used the multybeast to install the voodooHDA drivers, can this be the problem???

Exactly. Go to the first page of this thread and read again.

 

[kgp]

In that case I would rather work with the Clover patch, "GBE1 -> ETH0".
If you only work with the SSDT, the existing device "GBE1" is hidden and a new device "ETH0" is inserted in the same place. This works great with many other devices. The problem here is that there are other connections to this device in the DSDT that will be interrupted:

    Scope (_GPE)
    {
        Method (_L6D, 0, Serialized)  // _Lxx: Level-Triggered GPE
        {
            \_SB.PC00.XHCI.GPEH ()
            \_SB.PC00.CAVS.GPEH ()
            \_SB.PC00.GBE1.GPEH ()
        }
    }

That does not happen with the Clover patch. Here all entries in the ACPI (including DSDT) are exchanged, all links thus remain active.

I never faced any issues with the GBE1->ETH0 replacement within the SSDT.. Cannot reproduce your concerns, master Nico..