Contribute
Register

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

Status
Not open for further replies.
hi KGP, apologise for disturbing this X299 thread but have been following this thread to work my x99 SYSTEM with iMacPro system profiler but always black display or sometimes disturbing white screen. I have successfully created USB installer with your clear and detailed instruction. Appreciated for your knowledge and hardwork. BTW, I have GA-x99 UD4 with 5820k and Saphire Nitro+ RX 580 8GB. I also have GTX 660 in case to test with nVidia GPU. I even don't it is possible with X99 system. Thanks.
 
Last edited:
How to successfully implement/adopt a PCI device implementation (ACPI Replacements/SSDT-X299-iMacPro.aml)

The example below is for the OSXWIFI PCIe Adaptor in PCIe Slot-3. Once you understand the logics and methodology, how to implement the OSXWIFI Airport PCIe device, you should be also able to perform a proper ACPI Replacement and SSDT-X299-iMacPro.aml implementation of the OSXWIFI Airport PCI device in any other PCIe slot different from Slot-3, but also the ACPI Replacement and SSDT-X299-iMacPro.aml implementation of any Bluetooth PCIe Adaptor or any other build-in or slot-specific PCI Device (like GPUs or onboard PCI controllers).

So lets start with the OSXWIFI PCIe Adaptor PCI implementation:

1.) Copy the SSDT-X299-iMacPro.aml to your Desktop and remove it from /EFI/Clover/ACPI/patched/. Start your system without the SSDT-X299-iMacPro.aml. You need to know the original OSX "Airport" PCI implementation in IOREG.

2.) After reboot, open the IOREG explorer and search for “Airport" (1. in the figure below)

IOREG-Airport.png


3. IOREG will show you now where and how the PCI “Airport” driver "Airport_BrcmNIC" (2. in the figure above) is implemented:

It is important to take note of the exact ACPI path where "Airport_BrcmNIC" is child of (a., b., c. In the Figure above):

As you can see, with the OSXWIFI in PCIe Slot 3, the ACPI device patch is:

/PC03/BR3D/SLOC/

The PCI device SLOC, of which the “Airport” PCI driver "Airport_BrcmNIC" is child of, is assigned to /PC03/BR3D/

Note that with the OSXWIFI in a PCIe Slot different from PCIe Slot 3, the device path /PC03/BR3D/ and the Airport PCI Device name SLOC will differ!

With the OSXWifi in PCIe Slot 4, the ACPI device path might be /PC01/BR1A/ and the Airport PCI Device of which the “Airport” PCI Driver "Airport_BrcmNIC" is child of might be termed SL01.

Thus the entire Airport ACPI device path might be: /PC01/BR1A/SL01/ instead of /PC03/BR3D/SLOC/

So far so good...

4.) Following the iMac Pro PCI device name convention, the Airport PCI Device should not be termed SLOC but ARPT.

All users with the OSXWIFI in a PCIe Slot different from 3 have to open now the config.plist with Clover Configurator and adopt the SLOC -> ARPT ACPI Replacement.

ACPI-Patch.png


Note that in case that the OSXWifi is in PCIe Slot 4, the correct ACPI Device Replacement might not be SLOC -> ARPT but
SL01 -> ARPT, following the ACPI Device path we investigated in 3.) above.

How to take account for that?

First, change in the ACPI Replacement (1. in the figure above) the “Comment” entry from SLOC -> ARPT to SL01 -> ARPT.

Then you also have to adopt the Find* and Replace* Hex numbers in the ACPI replacement accordingly.

Therefore you open the HEX converter GUI of Clover Configurator (2. In the figure above).

Once in the Hex Converter GUI (1. in the figure below) go to Text Converter (2. in the figure below) and enter SL01 under text (3. in the figure below). Then click on Convert (4. in the figure below) and you will retrieve the correct HEX value for SL01, i.e. the correct HEX number for the Find* [HEX] entry in the ACPI Replacement.

HexConverterGUI.png


Thus, adopt the Find* [HEX] entry in the ACPI Replacement accordingly.

As you still want to replace SL01 by ARPT, the Replace* [HEX] value for ARPT remains still valid and does not need any additional adaptation.

Thus, the correct ACPI Replacement for the ARPT device with the OSXWIFI in e.g. PCIe Slot 4 would look like the following:

Comment:
SL01 -> ARPT Find* [HEX] 534c3031 Replace* [HEX] 41525054

After correctly adopting the ACPI Replacement in the config.plist, enable the latter ACPI replacement by unchecking “disabled” in the ACPI replacement and save the config plist.

After reboot, SL01 will now be correctly replaced by ARPT.

The "Airport" ACPI path with the OSX Wifi in PCIe slot 4 would appear in the IOREG explorer now correctly as:

/PC01/BR1A/ARPT

as it appears with the OSXWifi in PCIe slot 3 as:

/PC03/BR3D/ARPT


ARPT-ACPI.png


We now successfully adopted the ACPI Replacement in the config.plist and can continue with the

5.) Adaptation of the SSDT-X299-iMacPro.aml ARPT "Airport" Device implementation

To do so, we open our SSDT-X299-iMacPro.aml on the Desktop with MaciASL.

With the OSX Wifi in PCIe slot 4 instead if slot 3, we have to primarily adopt the ARPT ACPI device path in the Definition Block of the SSDT-X299-iMacPro.aml.

SSDT-Definition-block.png


As we have seen before in IOREG, with the OSXWIFI in PCIe slot 3, the APRT ACPI path is:

/PC03/BR3D/ARPT/

and with the OSXWIFI in PCIe slot 4, the APRT PCI path might be:

/PC01/BR1A/ARPT

Thus, please adopt the ARPT entry in the Definition block of your SSDT-X299-iMacPro.aml accordingly to the ACPI path provided by IOREG.

With the OSXWIFI in PCIe slot 3, the ARPT Definition block entry looks the following:

External (_SB_.PC03.BR3D.ARPT, DeviceObj) // (from opcode)

With the OSXWIFI in PCIe slot 4, the ARPT Definition block entry might have to look like the following:

External (_SB_.PC01.BR1A.ARPT, DeviceObj) // (from opcode)

Now lets continue with the ARPT SSDT-X299-iMacPro.aml Device Implementation.

SSDT-Device-Implementation.png


Again at first place we have to implement the correct ARPT ACPI patch [a.) in the figure above], which is

PC03.BR3D.ARPT with the OSXWIFI in PCIe slot 3

and might be

PC01
.BR1A.ARPT with the OSXWIFI in PCIe slot 4.

Now we have to verify and likely adopt the "AAPL, slot-name" [b.) in the figure above], the "device-id" [c.) in the figure above] and the "compatible" [d.) in the figure above] ACPI device implementations.

To do so, we need again IOREG.

IOREG-ARPT-Details.png


If we click on ARPT on the left-hand side, we find the necessary information, such as "compatible" and "device-id" on the right-hand side.

By means of this information, we now can adopt the ARPT SSDT-X299-iMacPro.aml ARPT PCI Device Implementation accordingly. I hope it is evident, that the "AAPL, slot-name" adaptation has to be performed according the PCIe slot nomenclature outlined in the ASUS Prime X299 Deluxe PCIe Figure of Section E.) in my guide, i.e. "Slot-3" with the OSXWIFI in PCIe slot 3 and "Slot-4" with the OSXWIFI in PCIe slot 4. Note that the "compatible" and "device-id" entries might also change in case you use a Bluetooth/WIFI PCI Adaptor different from the OSXWIFI. IOREG always is the base for any SSDT-X299-iMacPro.aml adaptation.

6.) Once the ARPT Device Implementation in the SSDT-X299-iMacPro.aml has been properly adopted, you can now copy again the modified SSDT-X299-iMacPro.aml to the /EFI/Clover/ACPI/patched/ directory of your system disk's EFI-Folder and reboot your System.

If you now open IOREG and again investigate your ARPT IOREG properties in the right-hand side column of IOREG, you will see that everything you defined and implemented within the SSDT-X299-iMacPro.aml, now also appears within the IOREG ARPT device information, i.e. the proper "AAPL,slot-name", the proper "acpi-path", "compatible" and "device-id" entries, as well as also all additional PCI device details you previously implemented within the above SSDT-X299-iMacPro.aml ARPT PCI Device implementation, i.e., "device-type", "model" and "name" (which can be preciously adopted and modified in the SSDT-X299-iMacPro.aml PCI Device implementation depending on the Bluetooth/WIFI Adopter in use). If everything is properly implemented and defined, you will also see in the left hand-side column of IOREG that the "Airport_BrcmNIC" PCI driver, being child of ARPT, is properly loaded.

Final-ARPT-IOREG-Implementation.png


Correspondingly, the "Airport" ARPT OSXWIFI Controller will also be properly implemented under "PCI" of Apple's system report.

Apple-System-Report.png


You will see the ARPT Airport Hardware name, device name, device type, Slot implementation and that the Airport PCI device driver, being child of ARPT, is properly installed and implemented.

The same approach and methodology can be used for any other PCI Device implementation, such as e.g. HDEF and HDAU (IOREG search term "audio"), GFX0 (IOREG search term "display") etc.

General Note: If your PCI Device is called PXSX, you are not able to perform the ACPI replacement within the config.plist, as there might be several PXSX devices along the different ACPI path definitions.

Let me retake again the OSXWIFI example, this time using the PCIe adapter in PCIe Slot-5:

The corresponding ACPI path seems to be PCI0.RP19.PXSX

Instead of the SLOC -> ARPT or SL01 -> ARPT ACPI replacement in the config.plist, which you can simply remove or disable, you MUST directly perform the ACPI replacement PCI0.RP19.PXSX -> PCI0.RP19.ARPT within the SSDT-X299-iMacPro.aml.

As you have several PXSX devices, you cannot perform the PXSX -> ARPT Replacement within the config.plist. You have to do it directly within the SSDT-X299-iMacPro.aml. How to do it, see below:

*********************************************************

DefinitionBlock ("", "SSDT", 1, "NICO", "X299", 0x00000000)
{
External (_SB_.PCI0.RP19.ARPT, DeviceObj) // (from opcode)
External (_SB_.PCI0.RP19.PXSX, DeviceObj) // (from opcode)

Scope (_SB.PCI0.RP19.ARPT)
{
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))
}

Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
Store (Package (0x0E)
{
"built-in",
Buffer (One)
{
0x00
},

"device-id",
Buffer (0x04)
{
0xA0, 0x43, 0x00, 0x00
},

"AAPL,slot-name",
Buffer (0x07)
{
"Slot-5"
},

"device_type",
Buffer (0x13)
{
"AirPort Controller"
},

"model",
Buffer (0x4A)
{
"OSX WIFI Broadcom BCM94360CD 802.11 a/b/g/n/ac + Bluetooth 4.0 Controller"
},

"compatible",
Buffer (0x0D)
{
"pci14e4,43a0"
},

"name",
Buffer (0x10)
{
"AirPort Extreme"
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Name (_SB.PCI0.RP19.PXSX._STA, Zero) // _STA: Status
}
*********************************************************

7.) I hope that now it is also evident, that the correct PCI Device implementation cannot be outlined for each individual "buid-in" or "slot-specific" PCI device within this guide. The complexity and effort would just exceed by far all available capacities and indeed require the implementation of a separate guide and thread in addition. I therefore hope on your skills and flexibility to extend and apply the approach and methodology detailed above to any other "build-in" or "slot-specific" PCI device yet to be adopted or implemented.

Important Note: It is strongly recommend to perform a stepwise PCI Device implementation by means of a minimalistic starter SSDT-X299-iMacPro.aml, which just contains the Definition Block and Device Implementation for one single specific device. Once this PCI device has been successfully implemented, other PCI Device definitions can be added to the SSDT-X299-iMacPro.aml. In case that subsequently the implementation of a specific PCI Device would be erroneous and fail, also all other already successfully implemented PCI devices would disappear from Section "PCI" of Apple's System report and the entire "PCI" Device implementation would fail. Thus a stepwise PCI device implementation/adaptation is highly recommended and sometimes deemed necessary!

Also keep always in mind to modify/adopt the ACPI replacements in your config.plist in parallel when ever necessary!

Good luck and enjoy :thumbup:

kgp.png
 
Last edited:
How to successfully implement/adopt a PCI device implementation (ACPI Replacements/SSDT-X299-iMacPro.aml)

The example below is for the OSXWIFI PCIe Adaptor in PCIe Slot-3. Once you understand the logics and methodology, how to implement the OSXWIFI Airport PCIe device, you should be also able to perform a proper ACPI Replacement and SSDT-X299-iMacPro.aml implementation of the OSXWIFI Airport PCI device in any other PCIe slot different from Slot-3, but also the ACPI Replacement and SSDT-X299-iMacPro.aml implementation of any Bluetooth PCIe Adaptor or any other build-in or slot-specific PCI Device (like GPUs or onboard PCI controllers).

So lets start with the OSXWIFI PCIe Adaptor PCI implementation:

1.) Copy the SSDT-X299-iMacPro.aml to your Desktop and remove it from /EFI/Clover/ACPI/patched/. Start your system without the SSDT-X299-iMacPro.aml. You need to know the original OSX "Airport" PCI implementation in IOREG.

2.) After reboot, open the IOREG explorer and search for “Airport" (1. in the figure below)

View attachment 311297

3. IOREG will show you now where and how the PCI “Airport” driver "Airport_BrcmNIC" (2. in the figure above) is implemented:

It is important to take note of the exact ACPI path where "Airport_BrcmNIC" is child of (a., b., c. In the Figure above):

As you can see, with the OSXWIFI in PCIe Slot 3, the ACPI device patch is:

/PC03/BR3D/SLOC/

The PCI device SLOC, of which the “Airport” PCI driver "Airport_BrcmNIC" is child of, is assigned to /PC03/BR3D/

Note that with the OSXWIFI in a PCIe Slot different from PCIe Slot 3, the device path /PC03/BR3D/ and the Airport PCI Device name SLOC will differ!

With the OSXWifi in PCIe Slot 4, the ACPI device path might be /PC01/BR1A/ and the Airport PCI Device of which the “Airport” PCI Driver "Airport_BrcmNIC" is child of might be termed SL01.

Thus the entire Airport ACPI device path might be: /PC01/BR1A/SL01/ instead of /PC03/BR3D/SLOC/

So far so good...

4.) Following the iMac Pro PCI device name convention, the Airport PCI Device should not be termed SLOC but ARPT.

All users with the OSXWIFI in a PCIe Slot different from 3 have to open now the config.plist with Clover Configurator and adopt the SLOC -> ARPT ACPI Replacement.

View attachment 311299

Note that in case that the OSXWifi is in PCIe Slot 4, the correct ACPI Device Replacement might not be SLOC -> ARPT but
SL01 -> ARPT, following the ACPI Device path we investigated in 3.) above.

How to take account for that?

First, change in the ACPI Replacement (1. in the figure above) the “Comment” entry from SLOC -> ARPT to SL01 -> ARPT.

Then you also have to adopt the Find* and Replace* Hex numbers in the ACPI replacement accordingly.

Therefore you open the HEX converter GUI of Clover Configurator (2. In the figure above).

Once in the Hex Converter GUI (1. in the figure below) go to Text Converter (2. in the figure below) and enter SL01 under text (3. in the figure below). Then click on Convert (4. in the figure below) and you will retrieve the correct HEX value for SL01, i.e. the correct HEX number for the Find* [HEX] entry in the ACPI Replacement.

View attachment 311300

Thus, adopt the Find* [HEX] entry in the ACPI Replacement accordingly.

As you still want to replace SL01 by ARPT, the Replace* [HEX] value for ARPT remains still valid and does not need any additional adaptation.

Thus, the correct ACPI Replacement for the ARPT device with the OSXWIFI in e.g. PCIe Slot 4 would look like the following:

Comment:
SL01 -> ARPT Find* [HEX] 534c3031 Replace* [HEX] 41525054

After correctly adopting the ACPI Replacement in the config.plist, enable the latter ACPI replacement by unchecking “disabled” in the ACPI replacement and save the config plist.

After reboot, SL01 will now be correctly replaced by ARPT.

The "Airport" ACPI path with the OSX Wifi in PCIe slot 4 would appear in the IOREG explorer now correctly as:

/PC01/BR1A/ARPT

as it appears with the OSXWifi in PCIe slot 3 as:

/PC03/BR3D/ARPT


View attachment 311301

We now successfully adopted the ACPI Replacement in the config.plist and can continue with the

5.) Adaptation of the SSDT-X299-iMacPro.aml ARPT "Airport" Device implementation

To do so, we open our SSDT-X299-iMacPro.aml on the Desktop with MaciASL.

With the OSX Wifi in PCIe slot 4 instead if slot 3, we have to primarily adopt the ARPT ACPI device path in the Definition Block of the SSDT-X299-iMacPro.aml.

View attachment 311302

As we have seen before in IOREG, with the OSXWIFI in PCIe slot 3, the APRT ACPI path is:

/PC03/BR3D/ARPT/

and with the OSXWIFI in PCIe slot 4, the APRT PCI path might be:

/PC01/BR1A/ARPT

Thus, please adopt the ARPT entry in the Definition block of your SSDT-X299-iMacPro.aml accordingly to the ACPI path provided by IOREG.

With the OSXWIFI in PCIe slot 3, the ARPT Definition block entry looks the following:

External (_SB_.PC03.BR3D.ARPT, DeviceObj) // (from opcode)

With the OSXWIFI in PCIe slot 4, the ARPT Definition block entry might have to look like the following:

External (_SB_.PC01.BR1A.ARPT, DeviceObj) // (from opcode)

Now lets continue with the ARPT SSDT-X299-iMacPro.aml Device Implementation.

View attachment 311304

Again at first place we have to implement the correct ARPT ACPI patch [a.) in the figure above], which is

PC03.BR3D.ARPT with the OSXWIFI in PCIe slot 3

and might be

PC01
.BR1A.ARPT with the OSXWIFI in PCIe slot 4.

Now we have to verify and likely adopt the "AAPL, slot-name" [b.) in the figure above], the "device-id" [c.) in the figure above] and the "compatible" [d.) in the figure above] ACPI device implementations.

To do so, we need again IOREG.

View attachment 311307

If we click on ARPT on the left-hand side, we find the necessary information, such as "compatible" and "device-id" on the right-hand side.

By means of this information, we now can adopt the ARPT SSDT-X299-iMacPro.aml ARPT PCI Device Implementation accordingly. I hope it is evident, that the "AAPL, slot-name" adaptation has to be performed according the PCIe slot nomenclature outlined in the ASUS Prime X299 Deluxe PCIe Figure of Section E.) in my guide, i.e. "Slot-3" with the OSXWIFI in PCIe slot 3 and "Slot-4" with the OSXWIFI in PCIe slot 4. Note that the "compatible" and "device-id" entries might also change in case you use a Bluetooth/WIFI PCI Adaptor different from the OSXWIFI. IOREG always is the base for any SSDT-X299-iMacPro.aml adaptation.

6.) Once the ARPT Device Implementation in the SSDT-X299-iMacPro.aml has been properly adopted, you can now copy again the modified SSDT-X299-iMacPro.aml to the /EFI/Clover/ACPI/Patched directory of your system disk's EFI-Folder and reboot your System.

If you now open IOREG and again investigate your ARPT IOREG properties in the right-hand side column of IOREG, you will see that everything you defined and implemented within the SSDT-X299-iMacPro.aml, also appear within the IROEG ARPT device information, i.e. the proper "AAPL,slot-name", the proper "acpi-path", "compatible" and "device-id" entries, as well as also all additional PCI device details you previously implemented within the above SSDT-X299-iMacPro.aml ARPT PCI Device implementation, i.e., "device-type", "model" and "name" (which can be preciously adopted and modified in the SSDT-X299-iMacPro.aml PCI Device implementation depending on the Bluetooth/WIFI Adopter in use). If everything is properly implemented and defined, you will also see in the left hand-side column of IOREG that the "Airport_BrcmNIC" PCI driver, being child of ARPT, is properly loaded.

View attachment 311311

Correspondingly, the "Airport" ARPT OSXWIFI Controller will also be properly implemented under "PCI" of Apple's system report.

View attachment 311312

You will see the ARPT Airport Hardware name, device name, device type, Slot implementation and that the Airport PCI device driver, being child of ARPT, is properly installed and implemented.

The same approach and methodology can be used for any other PCI Device implementation, such as e.g. HDEF and HDAU (IOREG search term "audio"), GFX0 (IOREG search term "display") etc.

7.) I hope it is also evident, that the correct PCI Device implementation cannot be outlined for each individual PCI device within this guide. The complexity and effort would just exceed by far all available capacities and indeed require the implementation of a separate guide and thread in addition. I therefore hope on your skills and flexibility to extend and apply the approach and methodology detailed above to any other PCI device yet to be adopted or implemented.

Important Note: It is strongly recommend to perform a stepwise PCI Device implementation by means of a minimalistic starter SSDT-X299-iMacPro.aml, which just contains the Definition Block and Device Implementation for one single specific device. Once this PCI device has been successfully implemented, other PCI Device definitions can be added to the SSDT-X299-iMacPro.aml. In case that subsequently the implementation of a specific PCI Device would be erroneous and fail, also all other already successfully implemented PCI devices would disappear from Section "PCI" of Apple's System report and the entire "PCI" Device implementation would fail. Thus a stepwise PCI device implementation/adaptation is highly recommended and sometimes deemed necessary!

Also keep always in mind to modify/adopt the ACPI replacements in your config.plist on parallel when ever necessary!

Good luck and enjoy :thumbup:

View attachment 311313

Wooow.... this is exactly what we needed (and I couldn't find no where)... to understeand basic process with a few more, very important details. :D

Thank You very much @kgp!!! You Rock! :headbang::headbang::headbang:

and I ask now... where the hell is the button "Love It" next to Like it...? :p
PS: I knew it... it will be a special and great day :D
 
hi KGP, apologise for disturbing this X299 thread but have been following this thread to work my x99 SYSTEM with iMacPro system profiler but always black display or sometimes disturbing white screen. I have successfully created USB installer with your clear and detailed instruction. Appreciated for your knowledge and hardwork. BTW, I have GA-x99 UD4 with 5820k and Saphire Nitro+ RX 580 8GB. I also have GTX 660 in case to test with nVidia GPU. I even don't it is possible with X99 system. Thanks.

My friend, forgive me this straight and direct answer, but I would not see any reason or advantage to use SMBIOS iMacPro1,1 with Broadwell-E/EP, Haswell-E/EP and X99 systems..

All the best,

KGP
 
Should I be able to generate my own ssdt? Or is this normal?

No need to use the former Pike Alpha ssdtPRGen.sh and ssdt.aml approach. It is totally sufficient just to use the CPU plugin-type injector ssdt.aml provided by @interferenc, implemented in and attached to the originating post of this thread (guide).

If you however insist in further using Pike Alpha's ssdt.aml approach, please find attached a ssdtPRGen.sh distribution, which I recently modified for compatibility with SMBIOS iMacPro1,1 and the iMacPro BroadID.

Good luck and all the best,

KGP
 

Attachments

  • ssdtPRGen.sh-iMacPro.zip
    378.9 KB · Views: 159
How to successfully implement/adopt a PCI device implementation (ACPI Replacements/SSDT-X299-iMacPro.aml)

The example below is for the OSXWIFI PCIe Adaptor in PCIe Slot-3. Once you understand the logics and methodology, how to implement the OSXWIFI Airport PCIe device, you should be also able to perform a proper ACPI Replacement and SSDT-X299-iMacPro.aml implementation of the OSXWIFI Airport PCI device in any other PCIe slot different from Slot-3, but also the ACPI Replacement and SSDT-X299-iMacPro.aml implementation of any Bluetooth PCIe Adaptor or any other build-in or slot-specific PCI Device (like GPUs or onboard PCI controllers).

So lets start with the OSXWIFI PCIe Adaptor PCI implementation:

1.) Copy the SSDT-X299-iMacPro.aml to your Desktop and remove it from /EFI/Clover/ACPI/patched/. Start your system without the SSDT-X299-iMacPro.aml. You need to know the original OSX "Airport" PCI implementation in IOREG.

2.) After reboot, open the IOREG explorer and search for “Airport" (1. in the figure below)

View attachment 311297

3. IOREG will show you now where and how the PCI “Airport” driver "Airport_BrcmNIC" (2. in the figure above) is implemented:

It is important to take note of the exact ACPI path where "Airport_BrcmNIC" is child of (a., b., c. In the Figure above):

As you can see, with the OSXWIFI in PCIe Slot 3, the ACPI device patch is:

/PC03/BR3D/SLOC/

The PCI device SLOC, of which the “Airport” PCI driver "Airport_BrcmNIC" is child of, is assigned to /PC03/BR3D/

Note that with the OSXWIFI in a PCIe Slot different from PCIe Slot 3, the device path /PC03/BR3D/ and the Airport PCI Device name SLOC will differ!

With the OSXWifi in PCIe Slot 4, the ACPI device path might be /PC01/BR1A/ and the Airport PCI Device of which the “Airport” PCI Driver "Airport_BrcmNIC" is child of might be termed SL01.

Thus the entire Airport ACPI device path might be: /PC01/BR1A/SL01/ instead of /PC03/BR3D/SLOC/

So far so good...

4.) Following the iMac Pro PCI device name convention, the Airport PCI Device should not be termed SLOC but ARPT.

All users with the OSXWIFI in a PCIe Slot different from 3 have to open now the config.plist with Clover Configurator and adopt the SLOC -> ARPT ACPI Replacement.

View attachment 311299

Note that in case that the OSXWifi is in PCIe Slot 4, the correct ACPI Device Replacement might not be SLOC -> ARPT but
SL01 -> ARPT, following the ACPI Device path we investigated in 3.) above.

How to take account for that?

First, change in the ACPI Replacement (1. in the figure above) the “Comment” entry from SLOC -> ARPT to SL01 -> ARPT.

Then you also have to adopt the Find* and Replace* Hex numbers in the ACPI replacement accordingly.

Therefore you open the HEX converter GUI of Clover Configurator (2. In the figure above).

Once in the Hex Converter GUI (1. in the figure below) go to Text Converter (2. in the figure below) and enter SL01 under text (3. in the figure below). Then click on Convert (4. in the figure below) and you will retrieve the correct HEX value for SL01, i.e. the correct HEX number for the Find* [HEX] entry in the ACPI Replacement.

View attachment 311300

Thus, adopt the Find* [HEX] entry in the ACPI Replacement accordingly.

As you still want to replace SL01 by ARPT, the Replace* [HEX] value for ARPT remains still valid and does not need any additional adaptation.

Thus, the correct ACPI Replacement for the ARPT device with the OSXWIFI in e.g. PCIe Slot 4 would look like the following:

Comment:
SL01 -> ARPT Find* [HEX] 534c3031 Replace* [HEX] 41525054

After correctly adopting the ACPI Replacement in the config.plist, enable the latter ACPI replacement by unchecking “disabled” in the ACPI replacement and save the config plist.

After reboot, SL01 will now be correctly replaced by ARPT.

The "Airport" ACPI path with the OSX Wifi in PCIe slot 4 would appear in the IOREG explorer now correctly as:

/PC01/BR1A/ARPT

as it appears with the OSXWifi in PCIe slot 3 as:

/PC03/BR3D/ARPT


View attachment 311301

We now successfully adopted the ACPI Replacement in the config.plist and can continue with the

5.) Adaptation of the SSDT-X299-iMacPro.aml ARPT "Airport" Device implementation

To do so, we open our SSDT-X299-iMacPro.aml on the Desktop with MaciASL.

With the OSX Wifi in PCIe slot 4 instead if slot 3, we have to primarily adopt the ARPT ACPI device path in the Definition Block of the SSDT-X299-iMacPro.aml.

View attachment 311302

As we have seen before in IOREG, with the OSXWIFI in PCIe slot 3, the APRT ACPI path is:

/PC03/BR3D/ARPT/

and with the OSXWIFI in PCIe slot 4, the APRT PCI path might be:

/PC01/BR1A/ARPT

Thus, please adopt the ARPT entry in the Definition block of your SSDT-X299-iMacPro.aml accordingly to the ACPI path provided by IOREG.

With the OSXWIFI in PCIe slot 3, the ARPT Definition block entry looks the following:

External (_SB_.PC03.BR3D.ARPT, DeviceObj) // (from opcode)

With the OSXWIFI in PCIe slot 4, the ARPT Definition block entry might have to look like the following:

External (_SB_.PC01.BR1A.ARPT, DeviceObj) // (from opcode)

Now lets continue with the ARPT SSDT-X299-iMacPro.aml Device Implementation.

View attachment 311304

Again at first place we have to implement the correct ARPT ACPI patch [a.) in the figure above], which is

PC03.BR3D.ARPT with the OSXWIFI in PCIe slot 3

and might be

PC01
.BR1A.ARPT with the OSXWIFI in PCIe slot 4.

Now we have to verify and likely adopt the "AAPL, slot-name" [b.) in the figure above], the "device-id" [c.) in the figure above] and the "compatible" [d.) in the figure above] ACPI device implementations.

To do so, we need again IOREG.

View attachment 311307

If we click on ARPT on the left-hand side, we find the necessary information, such as "compatible" and "device-id" on the right-hand side.

By means of this information, we now can adopt the ARPT SSDT-X299-iMacPro.aml ARPT PCI Device Implementation accordingly. I hope it is evident, that the "AAPL, slot-name" adaptation has to be performed according the PCIe slot nomenclature outlined in the ASUS Prime X299 Deluxe PCIe Figure of Section E.) in my guide, i.e. "Slot-3" with the OSXWIFI in PCIe slot 3 and "Slot-4" with the OSXWIFI in PCIe slot 4. Note that the "compatible" and "device-id" entries might also change in case you use a Bluetooth/WIFI PCI Adaptor different from the OSXWIFI. IOREG always is the base for any SSDT-X299-iMacPro.aml adaptation.

6.) Once the ARPT Device Implementation in the SSDT-X299-iMacPro.aml has been properly adopted, you can now copy again the modified SSDT-X299-iMacPro.aml to the /EFI/Clover/ACPI/patched/ directory of your system disk's EFI-Folder and reboot your System.

If you now open IOREG and again investigate your ARPT IOREG properties in the right-hand side column of IOREG, you will see that everything you defined and implemented within the SSDT-X299-iMacPro.aml, now also appears within the IOREG ARPT device information, i.e. the proper "AAPL,slot-name", the proper "acpi-path", "compatible" and "device-id" entries, as well as also all additional PCI device details you previously implemented within the above SSDT-X299-iMacPro.aml ARPT PCI Device implementation, i.e., "device-type", "model" and "name" (which can be preciously adopted and modified in the SSDT-X299-iMacPro.aml PCI Device implementation depending on the Bluetooth/WIFI Adopter in use). If everything is properly implemented and defined, you will also see in the left hand-side column of IOREG that the "Airport_BrcmNIC" PCI driver, being child of ARPT, is properly loaded.

View attachment 311311

Correspondingly, the "Airport" ARPT OSXWIFI Controller will also be properly implemented under "PCI" of Apple's system report.

View attachment 311312

You will see the ARPT Airport Hardware name, device name, device type, Slot implementation and that the Airport PCI device driver, being child of ARPT, is properly installed and implemented.

The same approach and methodology can be used for any other PCI Device implementation, such as e.g. HDEF and HDAU (IOREG search term "audio"), GFX0 (IOREG search term "display") etc.

7.) I hope that now it is also evident, that the correct PCI Device implementation cannot be outlined for each individual "buid-in" or "slot-specific" PCI device within this guide. The complexity and effort would just exceed by far all available capacities and indeed require the implementation of a separate guide and thread in addition. I therefore hope on your skills and flexibility to extend and apply the approach and methodology detailed above to any other "build-in" or "slot-specific" PCI device yet to be adopted or implemented.

Important Note: It is strongly recommend to perform a stepwise PCI Device implementation by means of a minimalistic starter SSDT-X299-iMacPro.aml, which just contains the Definition Block and Device Implementation for one single specific device. Once this PCI device has been successfully implemented, other PCI Device definitions can be added to the SSDT-X299-iMacPro.aml. In case that subsequently the implementation of a specific PCI Device would be erroneous and fail, also all other already successfully implemented PCI devices would disappear from Section "PCI" of Apple's System report and the entire "PCI" Device implementation would fail. Thus a stepwise PCI device implementation/adaptation is highly recommended and sometimes deemed necessary!

Also keep always in mind to modify/adopt the ACPI replacements in your config.plist in parallel when ever necessary!

Good luck and enjoy :thumbup:

View attachment 311313
thank you very much~~!!Very very great job~!!!!
i have a problem like this , i used slot 6 pcie,and there is no slc01,there is PXSX`````›
 
thank you very much~~!!Very very great job~!!!!
i have a problem like this , i used slot 6 pcie,and there is no slc01,there is PXSX`````›


Then you have to do the following:

Instead of the SLOC -> ARPT or SL01 -> ARPT ACPI replacement in the config.plist, which you can simply remove, you MUST directly perform the ACPI replacement PCI0.RP19.PXSX -> PCI0.RP19.ARPT within the SSDT-X299-iMacPro.aml.

As you have several PXSX devices, you cannot perform the PXSX -> ARPT Replacement within the config.plist. You have to do it directly within the SSDT-X299-iMacPro.aml. How to do it, see below!

Note that yet you have to check your "device-id" and "compatible" entries with IOREG. I don't see this information in your picture above and therefore I could not implement or consider it yet in the SSDT coding below!

**************

DefinitionBlock ("", "SSDT", 1, "NICO", "X299", 0x00000000)
{
External (_SB_.PCI0.RP19.ARPT, DeviceObj) // (from opcode)
External (_SB_.PCI0.RP19.PXSX, DeviceObj) // (from opcode)

Scope (_SB.PCI0.RP19.ARPT)
{
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))
}

Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
Store (Package (0x0E)
{
"built-in",
Buffer (One)
{
0x00
},

"device-id",
Buffer (0x04)
{
0xA0, 0x43, 0x00, 0x00
},

"AAPL,slot-name",
Buffer (0x07)
{
"Slot-5"
},

"device_type",
Buffer (0x13)
{
"AirPort Controller"
},

"model",
Buffer (0x4A)
{
"OSX WIFI Broadcom BCM94360CD 802.11 a/b/g/n/ac + Bluetooth 4.0 Controller"
},

"compatible",
Buffer (0x0D)
{
"pci14e4,43a0"
},

"name",
Buffer (0x10)
{
"AirPort Extreme"
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Name (_SB.PCI0.RP19.PXSX._STA, Zero) // _STA: Status
}
**************
 
Last edited:
Then you have to do the following:

Instead of the SLOC -> ARPT or SL01 -> ARPT ACPI replacement in the config.plist, which you can simply remove, you MUST directly perform the ACPI replacement PCI0.RP17.PXSX -> PCI0.RP17.ARPT within the SSDT-X299-iMacPro.aml.

As you have several PXSX devices, you cannot perform the PXSX -> ARPT Replacement within the config.plist. You have to do it directly within the SSDT-X299-iMacPro.aml. How to do it, see below!

Note that yet you have to check your "device-id" and "compatible" entries with IOREG. I don't see this information in your picture above and therefore I could not implement or consider it yet in the SSDT coding below!

**************

DefinitionBlock ("", "SSDT", 1, "NICO", "X299", 0x00000000)
{
External (_SB_.PCI0.RP17.ARPT, DeviceObj) // (from opcode)
External (_SB_.PCI0.RP17.PXSX, DeviceObj) // (from opcode)

Scope (_SB.PCI0.RP17.ARPT)
{
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))
}

Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
Store (Package (0x0E)
{
"built-in",
Buffer (One)
{
0x00
},

"device-id",
Buffer (0x04)
{
0xA0, 0x43, 0x00, 0x00
},

"AAPL,slot-name",
Buffer (0x07)
{
"Slot-6"
},

"device_type",
Buffer (0x13)
{
"AirPort Controller"
},

"model",
Buffer (0x4A)
{
"OSX WIFI Broadcom BCM94360CD 802.11 a/b/g/n/ac + Bluetooth 4.0 Controller"
},

"compatible",
Buffer (0x0D)
{
"pci14e4,43a0"
},

"name",
Buffer (0x10)
{
"AirPort Extreme"
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}

Name (_SB.PCI0.RP17.PXSX._STA, Zero) // _STA: Status

**************
here it is
屏幕快照 2018-02-06 下午10.42.35.png
 
Then you have to do the following:

As you have several PXSX devices, you cannot perform the PXSX -> ARPT Replacement within the config.plist. You have to do it directly within the SSDT-X299-iMacPro.aml. How to do it, see below!
...
This is next very very important detail :thumbup::thumbup::thumbup: which I was trying to do 2 minutes ago :p and I found weird X times PXSX while preparation all ASMedia implementations :p

It's quite fun because I had 80% of .aml prepared correctly, but changes wasn't visible cause few mistakes...
like for example my GFX0
the last thing it will be a Vega implementation
I changed block Scope (\_SB.PC02.BR2A.GFX0) - instead of GFXA and GFXB I will use only A because I have only 1 Vega at this moment, but weird thing is "ATY,Part#" which in example is:

"ATY,Part#",
Buffer (0x0C)
{
"113-3E366DU"
},


and on my IOreg:

only - ' r '
Capture d’écran 2018-02-06 à 14.49.42.png

so I'm not sure if it's OK/important..., without device-id needed etc... so... maybe it will works like that :p
we will see in 30-40 minutes when I will finish to check the other entries etc :)
 
Last edited:
Status
Not open for further replies.
Back
Top