Contribute
Register

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

Status
Not open for further replies.
@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:
Code:
Scope (\_SB.PCI0.ETH0)
    {
      ...

NEW | While implementing with the expanded header as seen in the new SSDT from you, does not work:
Code:
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.

Code:
    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!
 
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.

Code:
    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!
 
  • Like
Reactions: 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:

Code:
    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.
 
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
 
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.
 
  • Like
Reactions: 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:

Code:
    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.. ;)
 
If it's kernel panics in Premiere, it also happens with Vega, FYI.

This seems to be related to the iMac Pro SMBIOS/macOS/Adobe

nah I get KPs doing things like quicklook or even just letting the computer sit for a few hours. every time it's the exact same KP issue and the Nvidia drivers are always in the backtrace. I actually DON'T generally get KPs triggered by anything that taxes the GPU, weirdly enough. It's all completely anodyne things like playing a video in VLC or, like I said, Quick Look-ing something.
 
nah I get KPs doing things like quicklook or even just letting the computer sit for a few hours. every time it's the exact same KP issue and the Nvidia drivers are always in the backtrace. I actually DON'T generally get KPs triggered by anything that taxes the GPU, weirdly enough. It's all completely anodyne things like playing a video in VLC or, like I said, Quick Look-ing something.

NVIDIA I could understand, but not Vega.

Do you have CUDA installed? Try removing and see if the issue goes away.

Delete the following:

/System/Library/Extensions/CUDA.kext
/Library/Frameworks/CUDA.framework
/Library/LaunchAgents/com.nvidia.CUDASoftwareUpdate.plist
/Library/PreferencePanes/CUDA/Preferences.prefPane
/System/Library/StartupItems/CUDA/

If you installed the tookits and samples, delete the following also:

/Developer/NVIDIA/CUDA-5.0
/usr/local/cuda
 
Last edited:
I'm thinking of setting up a 2nd SSD with Sierra (well maybe I'll try Mojave first)

These Premiere Pro crashes are getting ridiculous. I got 4 system freezes lockups.

Two types of system freezes, which can easily be replicated.

1) Scrub timeline with MP4 or ProRes or RED footage.
2) Export to any codec and move the mouse continuously.

If you have a YT video playing in Chrome and exporting/scrubbing in Premiere you will have a guaranteed system lock up.
 
Last edited:
That's absolutely true.. and that's why I am eagerly looking forward to the release of a LG 38 inch with the same properties as the LG 34 inch currently under discussion.. ;)

Just added a 38 inch LG (3840x1600) to my portable hack. Love it.
 
  • Like
Reactions: kgp
Status
Not open for further replies.
Back
Top