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

[Matthew82]

 

Would that be compatible with what I have implemented anyway in my SSDT-X299-iMacPro.aml? 

            OperationRegion (PCIS, PCI_Config, Zero, 0x0100)
            Field (PCIS, AnyAcc, NoLock, Preserve)
            {
                PVID,   16, 
                PDID,   16
            }

            Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
            {
                Return (GPRW (0x69, 0x04))
            }

If this corresponding to USB port should be OK. Just make sleep test and You will se. 

[Guest]

I know just a curiosity to try a new way also because I am using ImacPro Smbios happily :-)

because now also with it it is possible to not patch anymore apple policy for Nvidia users

 

 

I have earlier X99 Deluxe. It is totally different story. 

[oSxFr33k]

There is another method that can be used to disable MSR lock.   Most manufacturers will hide advanced menus in the AMI UEFI bios because either they don't test many of these options or they don't know the consequences of these changes especially in laptops with more concern while most modern day Asus motherboards have FLashback Bios in case you completely brick your Bios.

 

Your only going to unhide CPU menu and nothing else and once you do that you will see the option CFG lock enable/disable.  Whoever attempts this should be extremely cautious and thoroughly read the guide a few times before attempting this method.

 

I have successfully used this method several times in my laptops, never found any issues in any of my Asus Desktop Motherboards where I needed to modify the Bios binary or unlock hidden menus since the option was always readily available for me.

 

I have linked the guide and another link where a few users have run across some situation enabling the advanced menus along with comments from Coderush.

 

http://voltground.com/haven/threads/102/

 

https://forums.mydigitallife.net/threads/tutorial-ami-aptio-uefi-advanced-menu-unlock-bonus-msr-unlock.54523/

[KGP-iMacPro]

New EFI-Folder attached at the bottom of the originating post of this thread (guide):

 

EFI-Folder related changes:

• New Ethernet ACPU DSDT Replacement Patch: Using GBE1 -> ETH0 instead of GBE1 -> XGBE

New SSDT-X299-iMacPro.aml attached to and implemented in the originating post of this thread (guide)

 

SSDT-X299-iMacPro.aml related changes:

• Update of LPCB, IMEI and PMCR PCI Device implementation, compatible with 10.13.2 SA (17C2205) and 10.13.3 public beta 6 (17D2046a). Main changes: new "device-id" and "compatible" definitions.​
• New I219-V Ethernet PCI device implementation, using ETH0 instead of XGBE.

 

Everything works again as expected:

 

 

Note however that this update does not resolve yet the USB3.0 related issues witnessed with 10.13.3 public beta 6 (17D2046a).

 

Enjoy and have fun 

 

 

 

[KGP-iMacPro]

Anybody willing to do Sleep/Wake Tests?

 

It seems that @Matthew82 found some workaround for the sleep/wake problem (Error E3 on Wake)

The workaround consists of the following:

1.) Add again a XCPM KernelToPatch entry to the config.plist in Section "Kernel and Kext Patches" of Clover Configurator (which I partly dislike as we just got rid of all XCPM patches):

Find* [Hex]                   Replace* [Hex]                 Comment

be030000 0031d2e8 72fcffff    be030000 0031d290 90909090     xcpm_idle patch by PikeAlpha

2.) Download, unzip and copy the SSDT-XHCI-Sleep.aml (which I adopted to work with XHCI instead of XHC1) to the /EFI/Clover/ACPI/patched/ folder in the EFI-partition of your system disk. You can use it in line with the SSDT-X299-iMacPro.aml.

Sleep/wake should now work again after reboot.

Warning! I witness problems with my RPW Fans after wake, which seem not to behave as expected (sporadic dropouts and irregular rpms after wake). Carefully watch your system and especially the CPU frequencies, power and temps in IPG after wake when doing this sleep/wake test! Yet you could severely damage your system if you are careless. Don't leave your system unwatched.  

Please provide your feedback and if possible further fruitful ideas how to proceed in this issue.

 

Edit: simplified version of SSDT-XHCI-Sleep.aml for XHCI instead of XHC1 implemented. Thanks to @Matthew82! 

[Matthew82]

You should use version from previous post. I delete unnecessary information https://drive.google.com/file/d/1Uehw5g1j5l38ktg7NJLOLAKXq-YEe7Ur/view?usp=sharing

Anybody willing to do Sleep/Wake Tests?

 

It seems that @Matthew82 found some workaround for the sleep/wake problem (Error E3 on Wake)

The workaround consists of the following:

1.) Add again a XCPM KernelToPatch entry to the config.plist in Section "Kernel and Kext Patches" of Clover Configurator (which I partly dislike as we just got rid of all XCPM patches):

Find* [Hex]                   Replace* [Hex]                 Comment

be030000 0031d2e8 72fcffff    be030000 0031d290 90909090     xcpm_idle patch by PikeAlpha

2.) Download, unzip and copy the SSDT-XHCI-Sleep.aml (which I adopted to work with XHCI instead of XHC1) to the /EFI/Clover/ACPI/patched/ folder in the EFI-partition of your system disk. You can use it in line with the SSDT-X299-iMacPro.aml.

Sleep/wake should now work again after reboot.

Warning! I witness problems with my RPW Fans after wake, which seem not to behave as expected (sporadic dropouts and irregular rpms after wake). Carefully watch your system and especially the CPU frequencies, power and temps in IPG after wake when doing this sleep/wake test! Yet you could severely damage your system if you are careless. Don't leave your system unwatched.  

Please provide your feedback and if possible further fruitful ideas how to proceed in this issue.

I insert this power method to Your ssdt. You can check if it work. I have different device configuration. https://drive.google.com/file/d/15U10uL7eQPddgQBhBB9KYVX4hISQ0CEb/view?usp=sharing

[KGP-iMacPro]

You should use version from previous post. I delete unnecessary information https://drive.google.com/file/d/1Uehw5g1j5l38ktg7NJLOLAKXq-YEe7Ur/view?usp=sharing

I insert this power method to Your ssdt. You can check if it work. I have different device configuration. https://drive.google.com/file/d/15U10uL7eQPddgQBhBB9KYVX4hISQ0CEb/view?usp=sharing

 

Simplified version for XHCI implemented in post #60. Thanks, man!

 

Note that we cannot use @Matthew82's SSDT-10.aml XHC1 version on our iMacPro Hackintosh Systems. His SSDT-10.am version of SSDT-XHCI-Sleep.aml is incompatible with SSDT-X299-iMacPro.aml, which bases on a XHCI and not on XHC1 implementation. When implementing XHC1 instead of XHCI, one would loose functionality of two external USB2.0 back port connectors on the ASUS Prime X299 Deluxe. 

 

Question to @Matthew82: Do we really need the part with XHC2 and XHC3? In my opinion this is just for the TB USB port implementation on the real iMacPro.. 

[Matthew82]

Simplified version for XHCI implemented in post #60. Thanks, man!

 

Question: Do we really need the part with XHC2 and XHC3? In my opinion this is just for the TB USB ports of the iMacPro.. 

Is no need. 

[KGP-iMacPro]

Is no need. 

 

Thus we can further simplify the file and drop the XHC2 and XHC3 part? 

[Matthew82]

Thus we can further simplify the file and drop the XHC2 and XHC3 part? 

yes

I make mod of your ssdt. Try did it work https://drive.google.com/file/d/15U10uL7eQPddgQBhBB9KYVX4hISQ0CEb/view?usp=sharing

[KGP-iMacPro]

yes

I make mod of your ssdt. Try did it work https://drive.google.com/file/d/15U10uL7eQPddgQBhBB9KYVX4hISQ0CEb/view?usp=sharing

 

No does not work.. breaks the entire PCI implementation for all other PCI devices incl. XHCI.. I already tried it myself before and I did not succeed in implementing your part directly in my SSDT-X299-iMacPro.aml.

 

Before: "scope" XHCI implementation

 

 

After: "device" XHCI implementation 

 

 

That's somehow totally weird in any case.. As soon I implement XHCI as device instead of scope, the PCI implementation of XHCI and all other PCI devices fails immediately.

 

However using my modified version of your SSDT-10.aml for XHCI  in line with my SSDT-X299-iMacPro.aml does not break the PCI implementation of XHCI and all other PCI devices.. 

 

Any idea or solution?

 

 

[KGP-iMacPro]

@Matthew82, just discovered why all USB3.0 ports are non-functional under 10.13.3 beta 6.

 

Since 10.13.3 beta 6, XHCI@14000000 uses  an AppleUSBXHCIPCI driver with IOPCIClassMatchID 0x0c033000 instead of 0xa2af8086.

 

I could use my XHC USB kext to force OSX to use the  AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086.

 

However, I would prefer to achieve the latter in the frame of an AML implementation. Is this possible at all? and how to achieve it if possible?

[Matthew82]

0xa2af8086 - this is device id

 

0x0c033000 - it is class id 

 

Two different things 

 

Im on beta 6 and all port works 

[KGP-iMacPro]

0xa2af8086 - this is device id

 

0x0c033000 - it is class id 

 

Two different things 

 

Im on beta 6 and all port works 

 

 I am neither talking about the device id nor the class id.

 

I am talking about the AppleUSBXHCIPCI driver IOPCIClassMatchID used by XHCI@14000000..

 

Not talking about XHCI@14

 

If all your ports work which AppleUSBXHCIPCI driver do you use?

 

USB3.0 stopped working under 10.13.3 beta even within the XHC USB emergency configuration, which means no XHC USB kext nor SSDT.aml 

 

My guess is that in my case the wrong AppleUSBXHCIPCI driver is loaded. 

 

​Formerly it was always the one with IOPCIClassMatchID 0xa2af8086 which was working. Now I have the one with IOPCIClassMatchID 0x0c033000 which does not work. 

 

The device id of XHCI@14 was also previously 0xa2af8086, and the class id as well 0x0c033000. This did not change at all. 

[Matthew82]

I check all my usb 3.0 and everything is ok 

 

[KGP-iMacPro]

I check all my usb 3.0 and everything is ok 

Zrzut ekranu 2018-01-23 o 12.56.19.png Zrzut ekranu 2018-01-23 o 12.56.50.png

 

Which AppleUSBXHCIPCI driver (IOPCIClassMatchID) OSX is using in your case? 

 

I am not the only one with the USB3.0 issue under 10.13.3 beta 6.. Thus the question is, why it is working in your case.. 

 

Which mobo do you use?

[Matthew82]

I dont rename XHC1 and using most native capabilities for my hack. I only add port limit patch and XHCI-200-series-injector.kext to insert device id. 

I thing you are making unnecessary mess with your ssdt 

[KGP-iMacPro]

I dont rename XHC1 and using most native capabilities for my hack. I only add port limit patch and XHCI-200-series-injector.kext to insert device id. 

I thing you are making unnecessary mess with your ssdt 

 

Your USB3.0 work due to injecting the XHCI-200-series-injector.kext, which is a non-native approach! 

 

Until 10.13.2, all USB3.0 ports have been natively implemented by OSX without any need for an additional USB kext like XHCI-200-series-injector.kext! 

 

​Under 10.13.3 beta one suddenly needs an USB Kext to get the correct  AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086, as otherwise OSX suddenly implements the  AppleUSBXHCIPCI driver with IOPCIClassMatchID 0x0c033000, which does not work at all.

 

My question now is, if there is any possibility to inject IOPCIClassMatchID 0xa2af8086 via an SSDT.aml which would make any USB kext again obsolete.. 

 

Do you understand what I am aiming at?

[Matthew82]

Yes. But I don't thing that work this way.

that it works this way

 

that it works this way

 

that it works this way

 

Of course I rename XHCI to XHC1

[KGP-iMacPro]

Yes. But I don't thing that work this way.

that it works this way

 

that it works this way

 

that it works this way

 

Of course I rename XHCI to XHC1

 

That's bad as in this case we have to fall back to XHC USB kexts which can be board specific and not be applied in a general way. 

 

The renaming of XHCI to XHC1 is not the problem. The problem is that since 10.13.3 OSX uses  the AppleUSBXHCIPCI driver with IOPCIClassMatchID 0x0c033000 instead of the AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086.

 

Just force an emergency USB configuration by booting without your Usb kext and you will see what I am talking about. You can do the same for both 10.13.2 and 10.13.3 and you will immediately see the difference. 

[KGP-iMacPro]

iMacPro XHC USB Kext to be tested by all users facing issues with XHC USB3.0 under 10.13.3 beta 6

 

Within the 10.13.3 betas, Apple suddenly assigns to XHCI@14000000 an AppleUSBXHCIPCI driver with IOPCIClassMatchID 0x0c033000 instead of 0xa2af8086. This results in the loss of native XHC USB3.0 support and in the malfunction of all XHC USB3.0 ports at least on the ASUS Prime X299 Deluxe. I don't know if we can find a way to properly inject the AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086 via our SSDT-X299-iMacPro.aml. 

 

However it can be easily injected via the XHC USB kext attached below. With KGP-iMacPro-XHCI.kext, all USB2.0 and USB3.0 ports will become fully functional. This kext should be at least fully compatible with the ASUS Prime X299 Deluxe, but hopefully it will be also compatible with all other mainboards facing the same IOPCIClassMatchID issue. 

 

Under 10.13.2, this kext also properly implements all USB HDDs and SSDs as external drives, where else all USB2.0 and USB3.0 drives are also still correctly and fully natively implemented by OSX, thanks to the AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086.

 

Your user feedback about XHC USB Kext compatibly and functionality is highly desired and appreciated. 

 

KGP-iMacPro-XHCI.kext.zip

[KGP-iMacPro]

front ports for usb 3, as well as one port in the rear on 10.13.3 show up as internal with the injector

 

How do you know if I even forgot to attach the attachment in my post above ??? 

 

Now it is there! 

[Matthew82]

 

iMacPro XHC USB Kext to be tested by all users facing issues with XHC USB3.0 under 10.13.3 beta 6

 

Within the 10.13.3 betas, Apple suddenly assigns to XHCI@14000000 an AppleUSBXHCIPCI driver with IOPCIClassMatchID 0x0c033000 instead of 0xa2af8086. This results in the loss of native XHC USB3.0 support and in the malfunction of all XHC USB3.0 ports at least on the ASUS Prime X299 Deluxe. I don't know if we can find a way to properly inject the AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086 via our SSDT-X299-iMacPro.aml. 

 

However it can be easily injected via the XHC USB kext attached below. With KGP-iMacPro-XHCI.kext, all USB2.0 and USB3.0 ports will become fully functional. This kext should be at least fully compatible with the ASUS Prime X299 Deluxe, but hopefully it will be also compatible with all other mainboards facing the same IOPCIClassMatchID issue. 

 

Under 10.13.2, this kext also properly implements all USB HDDs and SSDs as external drives, where else all USB2.0 and USB3.0 drives are also still correctly and fully natively implemented by OSX, thanks to the AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086.

 

Your user feedback about XHC USB Kext compatibly and functionality is highly desired and appreciated. 

 

 

 

Send your IOreg. I want to check some differences.

[KGP-iMacPro]

Send your IOreg. I want to check some differences.

 

Up and successfully running official release of 10.13.3 (17D2047)

 

 

The good news are that with the official release of 10.13.3 (17D2047) the AppleUSBXHCIPCI driver with IOPCIClassMatchID 0xa2af8086 is back to XHCI@14000000

 

 

and the entire XHC USB 3.0 issue during the 10.13.3 betas has been removed by itself automatically.

 

All XHC USB2.0 and USB3.0 ports are again natively implemented. Apple even solved the previous problem of the internal implementation of USB HDDs and SSDs. All USB drives are now correctly implemented as external.

 

The entire XHC USB Kext discussion is herewith obsolete. Full native XHC USB implementation without any need for additional USB kexts!

 

BTW, @Matthew82, try to remove  XHCI-200-series-injector.kext and you will see to what I am referring to. 

 

Cheers and good night,

 

KGP

[Matthew82]

That's great message.