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

maleorderbride · February 4, 2018

Thanks for updating patches.txt! I now get a 3rd patch applied (instead of the two earlier), but decompression error remains and no BIOS file is created.

parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseFile: non-empty pad-file contents will be destroyed after volume modifications
patch: replaced 8 bytes at offset 4125h 81E10080000033C1 -> 9090909090909090
patch: replaced 45 bytes at offset 1507h B9E20000000F328BC8BE0080000023CE0BCF75190BC6894424088954240C8B54240C8B442408B9E20000000F30 -> BA00000000B800000000B93B0000000F3090909090909090909090909090909090909090909090909090909090
reconstructSection: executable section rebase failed
Error ,
bash-3.2#

Renaming to .CAP does not effect the results for my ASRock BIOS. Well shoot! I would like to avoid having to use TSCSync.

February 5, 2018

Hi maleorderbride

Stimolate with a @DSM2 private message I have tried a way to apply all patches proposed by @interferenc

2 steps method

I don't post here because I can't test by myself with a flash and because I am sure this is not a solution for x299 problem

No need to renaming nothing but I do not advice people to touch these things!

Thanks for updating patches.txt! I now get a 3rd patch applied (instead of the two earlier), but decompression error remains and no BIOS file is created.

parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseFile: non-empty pad-file contents will be destroyed after volume modifications
patch: replaced 8 bytes at offset 4125h 81E10080000033C1 -> 9090909090909090
patch: replaced 45 bytes at offset 1507h B9E20000000F328BC8BE0080000023CE0BCF75190BC6894424088954240C8B54240C8B442408B9E20000000F30 -> BA00000000B800000000B93B0000000F3090909090909090909090909090909090909090909090909090909090
reconstructSection: executable section rebase failed
Error ,
bash-3.2#

Renaming to .CAP does not effect the results for my ASRock BIOS. Well shoot! I would like to avoid having to use TSCSync.

KGP-iMacPro · February 5, 2018

Thanks for updating patches.txt! I now get a 3rd patch applied (instead of the two earlier), but decompression error remains and no BIOS file is created.

parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseSection: decompression failed with error "Standard decompression failed"
parseFile: non-empty pad-file contents will be destroyed after volume modifications
patch: replaced 8 bytes at offset 4125h 81E10080000033C1 -> 9090909090909090
patch: replaced 45 bytes at offset 1507h B9E20000000F328BC8BE0080000023CE0BCF75190BC6894424088954240C8B54240C8B442408B9E20000000F30 -> BA00000000B800000000B93B0000000F3090909090909090909090909090909090909090909090909090909090
reconstructSection: executable section rebase failed
Error ,
bash-3.2#

Renaming to .CAP does not effect the results for my ASRock BIOS. Well shoot! I would like to avoid having to use TSCSync.

UEFIPatch and Patches.txt are meant for unlocking the MSR 0xE2 register on ASUS boards! BIOS Firware and BIOS Firware Structure for mainboards of different brands can be totally different from ASUS. A simple rename of the BIOS firmware filename extension does not help at all. UEFIPatch and Patches.txt might simply fail and also might be simply inadequate for patching the firmware of mainboards different from ASUS..

February 5, 2018

#1

Multi vendors motherboard as specified by Uefitool creator (@coderush)

Maybe patches posted here are Asus related (one tsc related is also patchable in different way for Gigabyte and Asrock x299 I see here but I do not advice to do it)

UEFIPatch and Patches.txt are meant for unlocking the MSR 0xE2 register on ASUS boards! BIOS Firware and BIOS Firware Structure for mainboards of different brands can be totally different from ASUS. A simple rename of the BIOS firmware filename extension does not help at all. UEFIPatch and Patches.txt might simply fail and also might be simply inadequate for patching the firmware of mainboards different from ASUS..

KGP-iMacPro · February 5, 2018

That‘s exactly what I say.. the patches of @interference are currently exclusively for Asus mobo bios firmware! I don‘t know what is so difficult in understanding what that means and which implications this has...

maleorderbride · February 5, 2018

That‘s exactly what I say.. the patches of @interference are currently exclusively for Asus mobo bios firmware! I don‘t know what is so difficult in understanding what that means and which implications this has...

KGP--in earlier versions of this guide and posts you suggested that all X299 board should apply these patches and that it might work. I followed your suggestion.

Granted, your original assumption does make a certain amount of sense given that UEFI Tool was designed based upon motherboard BIOS vendors (i.e AMI, Phoenix, etc) not exclusively certain motherboard manufacturers. The patches are aimed at specific modules, that could be different across boards and vendors, but are not necessarily so. I'll take a look at the modules in question and patch it myself if need be.

I only changed the BIOS name to .CAP because you seemed concerned about it. Of course it doesn't effect UEFI Tools, but I was humoring you.

KGP-iMacPro · February 5, 2018

KGP--in earlier versions of this guide and posts you suggested that all X299 board should apply these patches and that it might work. I followed your suggestion.

Granted, your original assumption does make a certain amount of sense given that UEFI Tool was designed based upon motherboard BIOS vendors (i.e AMI, Phoenix, etc) not exclusively certain motherboard manufacturers. The patches are aimed at specific modules, that could be different across boards and vendors, but are not necessarily so. I'll take a look at the modules in question and patch it myself if need be.

I only changed the BIOS name to .CAP because you seemed concerned about it. Of course it doesn't effect UEFI Tools, but I was humoring you.

Sorry,but that's nonsense. In earlier versions of my guide there where not even Firware patches for the ASUS Prime available. So how could I have suggested to apply non-existent patches to all mainboards..

In the next step, we derived patches for the ASUS mainboards to unlock MSR 0xE2 register. Thus why should I have recommended to patch mainboards with already open MSR 0xE2 register?

Only in the last step we derived BIOS patches, which also fixed the Skylake-X TSC problem for all ASUS mainboards.

I do not want to enter absurd discussions about BIOS firmware patching. I have no clue in what and how much the BIOS Firmware of different brands differ from the one of ASUS.

The UEFI Tool might have been originally designed for many mainboards. Fact is that until December 2017, it was not able to deal with the new BIOS file system of the ASUS Prime X299 Deluxe.

Who says that it is able to properly tread now the BIOS Firmware of your mainboard? I definitely do not claim such things!

And to stress once more the following: The 3 patches provided by @interferenc are for patching ASUS mainboards! Full stop.

Matthew82 · February 5, 2018

Boys..Do not make TonyMac of this place!

KGP-iMacPro · February 5, 2018

Good idea! Thanks! Appreciated comment.

Loloflat6 · February 5, 2018

Most important to me is that this guide provides a simple and easy way to build my own iMacPro.

I just started installing my system five days ago.

I apply the basic settings with a suitable set for my build and have just tried to implement the DSDT replacement patches that are needed for my motherboard.

In fact, my new build 2018 now runs for four days: except when I restarted the system to adjust some settings, I never turn it off.

Everything works as expected, sleep and wake up by in one click.

When I come back this evening I know everything will be fine: it's very important for me not to waste my time.

I will continue to optimize the settings continuously in reading this guide.

Life is good ! Thanks Kgp

To be continued... :wink_anim:

LockDown · February 6, 2018

KGP-iMacPro

Thanks for the guide. keep it coming!

KGP-iMacPro · February 6, 2018

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)

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.

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.

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

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.

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.

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.

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.

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

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 "build-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,

Loloflat6 · February 6, 2018

Nice : what I (we ) needed to understand the process with very important details :

Night will be long for me : seems i will have "hard intellect job" to try to achieve my full PCI implementation.

Thank's !

MGregRS · February 6, 2018

Nice : what I (we ) needed to understand the process with very important details :

Night will be long for me : seems i will have "hard intellect job" to try to achieve my full PCI implementation.

Thank's !

Don"t worry @Loloflat6

Yesterday it was my dream to finish it "some day".., most of implementations, correctly..

and wondering to have a great full beautiful PCi list like KGP

Today after KGP post, few hours later (happy 'comme je sais pas quoi') :drool: I have almost final version

which works great

So again, HUGE Thank You for KGP!!!

That was a great day -by You :thumbsup_anim:

KGP-iMacPro · February 7, 2018

To avoid the loss of analogue onboard audio (S1220A in case of the ASUS Prime X299 Deluxe) on Wake from Sleep, please download, unzip and copy the latest CodecCommander.kext distribution of @Rehabman from bitbucket.org to the /EFI/Clover/kexts/Other directory in the EFI-Folder of your System Disk: https://bitbucket.org/RehabMan/os-x-eapd-codec-commander/downloads/.

KGP-iMacPro · February 7, 2018

@Matthew82, @macandrea,

just updated to 10.13.4 Beta 2 via the Appstore..

The 10.13.4 Beta 2 build number 17E150f still seems to refer to the standard macOS build and not to the special iMacPro macOS build...

The same states for the system profiler: in Apple's System report one finds under "Hardware" and "Model Name" still iMac instead of iMac Pro, in contrary to 10.13.3 17D2047.

Another question refers to the XHCI implementation.

@Matthew82, is the new XHC USB port limit patch you previously distributed still valid for 10.13.4 Beta 2? Although within 10.13.4 Beta 2, the correct AppleUSBXHCIPCI driver 0xa2af8086 gets implemented, I do only have 1 SS Port available. Most of my USB3.0 ports are non-functional without using my XHC USB Kext.

Desperately awaiting your answers.. :wink_anim:

Cheers,

KGP

Matthew82 · February 7, 2018

The 10.13.4 Beta 2 build number 17E150f still seems to refer to the standard macOS build and not to the special iMacPro macOS build...

The same states for the system profiler: in Apple's System report one finds under "Hardware" and "Model Name" still iMac instead of iMac Pro, in contrary to 10.13.3 17D2047.

In my to and I thing in every original iMacPro users to, exept some first osx realest for iMacPro. This is just beta and it have no impact for functioning my machine. Just cometic stuff.

About USB

This is working patch for port limit:

AppleUSBXHCI - 837d940f 0f839704 0000 > 837d941a 90909090 9090

And im using my home made device injector.

https://drive.google.com/file/d/1_1qzR_EJDP0WSCvLKsXt6naOA0Acxo6n/view?usp=sharing

KGP-iMacPro.

Can you send me your Ioreg? I want to check some differences in device loading.

KGP-iMacPro · February 7, 2018

In my to and I thing in every original iMacPro users to, exept some first osx realest for iMacPro. This is just beta and it have no impact for functioning my machine. Just cometic stuff. orginal iMacPro.png

About USB

This is working patch for port limit:

AppleUSBXHCI - 837d940f 0f839704 0000 > 837d941a 90909090 9090

And im using my home made device injector.

https://drive.google.com/file/d/1_1qzR_EJDP0WSCvLKsXt6naOA0Acxo6n/view?usp=sharing

xhc.png

Zrzut ekranu 2018-02-07 o 11.31.49.png

I am using exactly this port limit patch, but I just get 1 SS port implemented without my XHC USB Kext! If I use my XHC USB Kext everything works as expected... Please find my XHC USB Kext for the ASUS Prime X299 Deluxe attached below...

I see that you now also created your own XHC USB Kext, which even accounts for AHCI... Congratulations! BTW.. this XHC USB kext is valid for which motherboard?

However, how is the native OSX 10.13.4 Beta 2 XHC USB implementation, without your XHC USB Kext by only considering the port limit patch and nothing else?

Are in this case all USB3.0 ports properly implemented? Do you get more then just one SS port natively implemented without your XHC UBS Kext?

KGP-iMacPro-XHCI.kext.zip

Matthew82 · February 7, 2018

I have only 19 ports without injector.

Can you send me your Ioreg? I want to check some differences in device loading.

Ahci injector making good job to

KGP-iMacPro · February 7, 2018

I have only 19 ports without injector.

Can you send me your Ioreg? I want to check some differences in device loading.

Ahci injector making good job to

Zrzut ekranu 2018-02-07 o 14.39.42.png

which IOREG version do you prefer?

Matthew82 · February 7, 2018

I have installed Version 3.0.2 (14)

KGP-iMacPro · February 7, 2018

I have installed Version 3.0.2 (14)

How to modify your port limit patch that it works for more than 19 ports?

Don't you use 1a which means in principle 26 instead of 15?

I mean if I just take 837d940f -> 837d941a ...

I will send you my IOREG dump soon once the thing with the port limit patch is clarified..

Matthew82 · February 7, 2018

Now I boot whiteout my kext. This is the result.

I only add this patch from previous post

February 7, 2018

Hi

you should read on IM where these patches are discovered by fredwst and then by PmHeart

She shared a patch which delete port limit at all so it is not important write your correct port number with her patch

also @Matthew82 posted it here

original post below

#109

How to modify your port limit patch that it works for more than 19 ports?

Don't you use 1a which means in principle 26 instead of 15?

I mean if I just take 837d940f -> 837d941a ...

I will send you my IOREG dump soon once the thing with the port limit patch is clarified..

Edited February 7, 2018 by Guest

KGP-iMacPro · February 7, 2018

Now I boot whiteout my kext. This is the result.

Zrzut ekranu 2018-02-07 o 14.50.54.png

I only add this patch from previous post

That's strange.. you have all SS ports natively available.. I just get 1 SS port natively implemented under 10.13.4 Beta 2..

Back to your port limit patch:

The former port limit patch was:

837d8c10 -> 837d8c19 (10 ports vs. 19)

Your new patch seems:

837d940f -> 837d941a (15 ports vs. 26)

15 seems at odd with the OSX port limit of 10...

is the second part:

0f839704 0000 -> 90909090 9090

really needed?

BTW, I guess I already know well the originating thread where these patches were discovered by fredwst and PmHeart...

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

iMacPro Build/Guide Feedback 26 members have voted

1. Does this guide help you in your endeavour?

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

iMacPro Build/Guide Feedback
26 members have voted