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

[ImaPirate]

Hey KGP, It's been a while since I'm busy working using my machine. I'm currently using 10.3.2 just fine, but noticed you updated to 10.3.3. Now I'm finding out about the new beta 10.3.4. I saw this link and wanted your thoughts about it:

http://appleinsider.com/articles/18...users-about-32-bit-softwares-impending-demise

Somebody might have shared something on here already about it and if they did, just let me know what post number it is and I'll go and read it. If not, then this might be something to talk about. I haven't looked into it much, but I hope it doesn't affect using apps like Photoshop, Illustrator, InDesign, Premier and like kind apps. Look forward to hearing your response, later...

PS - I see you reached 65,000+ on your GB score - GOOD FOR YOU! How'd you get there? Just curious.

 

[kgp]

@kgp did you get the latest Nvidia web drivers working without the UI lags? I get lagging, and I'm wondering if rolling back to an older driver would work on SMBIOS MacPro1,1?

Did you read Section E.2) - Graphics Configuration at all? I mean there is a detailed description how to roll back from Web Driver xxx.157 to Web Driver xxx.106?

Web Driver xxx.157 works flawless with my Gigabyte AORUS GeForce GTX 1080 Ti WaterForce WB 11GB Xtreme Edition. No lag at all!

Anybody witnessing a lag with Web Driver xxx.157 can easily roll back to Web Driver xxx.106. He/She just needs to read my guide.

Cheers and good luck,

KGP

 

[kgp]

@kgp - found a weird thing. If i install FakeSMC into /L/E, I can't boot. I can only have it installed in the EFI volume. Is this normal? Lol

Thanks!

Well I don't understand why you want to have FakeSMC in /L/E instead of /EFI/Clover/kexts/Other....

In any case, did you perform the following steps after installing FakeSMC in /L/E with admin permission?

sudo chmod -R 755 /Library/Extensions/FakeSMC.kext
sudo chown -R root:wheel /Library/Extensions/FakeSMC.kext
sudo touch /Library/Extensions && sudo kextcache -u /

 

[kgp]

It's a guide... I'm interested in knowing if it remains valid with a different mobo. it ain't rocket science and it ain't a general Desktop compatibility question.

Let me provide you with straight and simple answers.

I guess it is obvious and clear that this guide bases on the ASUS Prime X299 Deluxe! The same states for any BIOS settings recommendation and attached EFI-Folder distribution. I opted for this board after a careful and in-depth OSX compatibility assessment and careful and in-depth OSX compatibility consideration. Anybody opting for a mainboard different from the ASUS Prime X299 Deluxe takes own responsibility on that.

Note that it is simply impossible to provide a guide with BIOS settings recommendations, EFI-Folder distributions and system configurations, compatible with all X299 mainboards already available on the market. Especially my EFI-Folder distributions are kept on purpose as general as possible and need to be completed and adopted by considering the respective guidelines. Additional necessary adaptations/modifications for deviating hardware configurations are definitely not excluded.

The more your hardware configuration deviates from the original hardware configuration constituting the baseline of this guide , the more your own personal technical skills will be asked to adopt my individual guidelines for your personal needs.

If you feel that your personal technical qualifications are insufficient to adopt my guidelines for your personal needs and personal implications, I guess you have the following options.

1.) Search along this thread, if somebody has been able to successfully run the specific hardware with my guide. If so, ask the specific person, if he/she is willing to provide you support and if he/she is also willing to share with you the likely necessary modifications/adaptations.

2.) If not already available, you are also free to open in the correct "Desktop Compatibility" forum a sub-thread, discussing the necessary adaptations of my guidelines to successfully run your particular hardware, as already gratefully suggested in post #5304 above.

3.) If all necessary adaptations are identified, I can implement the most important findings for the particular hardware also within my guide, as long it does not unnecessarily extend the already extensive guidelines. I also could just implement a link the the respective sub-thread. This certainly would stepwise increase the general compatibility of my guide with all available hardware.

4.) As long your contributions are constructive and help to improve the general flexibility and applicability of this guide, they are welcome and moreover appreciated. If possible, they also shall be accounted within the guide. However, complains and any spamming with incompatibility issues due to a yet incompatible or not approved hardware configuration should be strictly avoided along this thread. I also kindly ask not to extend problems witnessed with a particular hardware component to all Skylake-X/X299 systems or to the hardware and system configuration, which constitutes the baseline of this guide.

5.) With respect to the ASUS X299 Rampage VI and the Gigabyte X299 Designare EX, I would like to stress that both mainboards apparently have been already successfully implemented after some likely adaptation/modification of my guidelines. With respect to the ASUS X299 Rampage VI, I would like to refer to user @Ramalama. With respect to the Gigabyte X299 Designare EX, I would like to refer to user @DSM2. If these users have the temporal resources and are also willing to share their experience and knowledge to officially provide all necessary adaptations/modifications is out of my hands and influence. I cannot force anybody to do so.

I hope that this answer is sufficiently clear to avoid any further unnecessary claims, discussions or requests along this thread.

A happy and constructive hacking for anybody and all the best for your individual endeavours,

KGP

 

[macs_forever]

Let me provide you with straight and simple answers.

I guess it is obvious and clear that this guide bases on the ASUS Prime X299 Deluxe! The same states for any BIOS settings recommendation and attached EFI-Folder distribution. I opted for this board after a careful and in-depth OSX compatibility assessment and careful and in-depth OSX compatibility consideration. Anybody opting for a mainboard different from the ASUS Prime X299 Deluxe takes own responsibility on that.

Note that it is simply impossible to provide a guide with BIOS settings recommendations, EFI-Folder distributions and system configurations, compatible with all X299 mainboards already available on the market. Especially my EFI-Folder distributions are kept on purpose as general as possible and need to be completed and adopted by considering the respective guidelines. Additional necessary adaptations/modifications for deviating hardware configurations are definitely not excluded.

The more your hardware configuration deviates from the original hardware configuration constituting the baseline of this guide , the more your own personal technical skills will be asked to adopt my individual guidelines for your personal needs.

If you feel that your personal technical qualifications are insufficient to adopt my guidelines for your personal needs and personal implications, I guess you have the following options.

1.) Search along this thread, if somebody has been able to successfully run the specific hardware with my guide. If so, ask the specific person, if he/she is willing to provide you support and if he/she is also willing to share with you the likely necessary modifications/adaptations.

2.) If not already available, you are also free to open in the correct "Desktop Compatibility" forum a sub-thread, discussing the necessary adaptations of my guidelines to successfully run your particular hardware, as already gratefully suggested in post #5304 above.

3.) If all necessary adaptations are identified, I can implement the most important findings for the particular hardware also within my guide, as long it does not unnecessarily extend the already extensive guidelines. I also could just implement a link the the respective sub-thread. This certainly would stepwise increase the general compatibility of my guide with all available hardware.

4.) As long your contributions are constructive and help to improve the general flexibility and applicability of this guide, they are welcome and moreover appreciated. If possible, they also shall be accounted within the guide. However, complains and any spamming with incompatibility issues due to a yet incompatible or not approved hardware configuration should be strictly avoided along this thread. I also kindly ask not to extend problems witnessed with a particular hardware component to all Skylake-X/X299 systems or to the hardware and system configuration, which constitutes the baseline of this guide.

5.) With respect to the ASUS X299 Rampage VI and the Gigabyte X299 Designare EX, I would like to stress that both mainboards apparently have been already successfully implemented after some likely adaptation/modification of my guidelines. With respect to the ASUS X299 Rampage VI, I would like to refer to user @Ramalama. With respect to the Gigabyte X299 Designare EX, I would like to refer to user @DSM2. If these users have the temporal resources and are also willing to share their experience and knowledge to officially provide all necessary adaptations/modifications is out of my hands and influence. I cannot force anybody to do so.

I hope that this answer is sufficiently clear to avoid any further unnecessary claims, discussions or requests along this thread.

A happy and constructive hacking for anybody and all the best for your individual endeavours,

KGP

1.) I searched first. Designare pops up in a lot of signatures without a lot of good information. I did finally find some good info.
2.) your #5 was really what I needed for an answer. Sorry you spent so much time on detail.

I have a great deal of technical knowledge and analytical skills, even a Computer Science degree. I'll apply those skills as needed but they are geared toward my job, not hackintoshes. I've built 6 hackintoshes to date, but usually stick with known builds and tools because I don't have a lot of time to develop clover/kexts/etc. expertise. What I have built so far:

• i5 NUC
• i5 Z68 MATX
• i7 Z68 MATX
• i7 H61 ITX
• i7 Z77 ITX
• i7 Z170 ITX -- in the tiny Lian-Li PC-TU100 case -- my favorite

I need the 18 core hackintosh for work related tasks. My VM farms are now requiring 8 vCores per VM. my old Mac Pro is maxed out at 12 cores (24 threads/vCores). The i9-7980XE will allow 4 - 8 vCore VMs with a couple of real cores left over to run the MacOS. If it all goes sideways, I'll convert the machine to RedHat or Windows but that would suck. I wanted the 18 core iMacPro but $11,000 for what I need is just too much.

I'm not going to gripe or complain on your topic. There's too much pissyness and snark as it is on the forums IMHO.

Thank You.

 

[kgp]

Agreed about the catalog of device available on the market is so large it would be hard to account for everything in an automated way.

I just updated the script to produce an AML for someone to be able to copy and paste the contents into their customized AML, the script does produce a syntacticly correct AML but before using it directly you would need to modify it heavily as it does not account for all the other devices beyond PCI ones.

RoadBlocks to automation

AML Compatible field
The logic for obtaining the correct "Compatible" field is loss on me. Perhaps if someone could explain in detail what this field is for and why it is important to the AML I could figure out some logic to correctly parse it from Ioreg, as of right now though I am not clear on why the second "compatible" item is the valid entry and why we need to use it?

View attachment 312589

Apple Naming conventions
I hope someone could help me with, but right now I don't know what the Apple typically names all the devices and what convention they use across all Apple Machines? As an example with my script you can easily see that a device type is an ethernet controller, one could infer from that the proper device name for apple would be "ETH1" if it happens to be the first Nic in the configuration. If someone could provide maybe a database of Apple naming conventions I could enhance the script to at least prompt the user to select an apple device name from a list of qualified names sorted by device types.

Other Devices
KGP mentions in his guide that any device sitting at the PXSX position needs to be defined in the AML only and not patched in the clover config, I think this is doable to write into the script, but I am having difficulty understanding why these devices are different. Perhaps if I had more background on what makes these devices unique then I could wrap a parser around identifying them from the onset and provide more detailed information on them. I think if I added these devices to the script the script could generate a 80-90% complete AML.

Physical slots devices are install in
Although the script is able to tell you what "AAPL,slot-name" is currently set in ioreg, most motherboards do not report this information as it is seems to be apple specific, that is to say the slot-name field does not get filled in ioreg until it is added to the AML files in the patched directory. All that being said, I think the tool could help users by walking them through a series of prompts that ask the user to enter in the name of the slot that the device is physically plugged into. I could be wrong but the "AAPL,slot-name" seems largely cosmetic and could potentially not be required, however I have not tested that theory.

1.) AML "Compatible" field: in my understanding, the "Compatible" field provides information about the compatible OSX device/driver for the respective device. Many times the compatible OSX device/driver is also once more reflected under "device ID" or "IOName" (see e.g. again the OSXWIFI example). Usually it is the second entry in the "Compatible" field. Note that the "compatible" device implementation is also not always deemed necessary within each SSDT.aml device implementation. This mainly depends on the particular necessity of the "Compatible" device implementation for each PCI device, which can be simply experimentally confirmed by the successful PCI driver implementation.

2.) I already intended to outline, detail and describe the Apple device naming conventions and necessary ACPI replacements in Section E.9.1). If you feel that some variables are not adequately renamed or implemented, feel free to provide improvements or suggestions. Wherever possible, I also tried to account for the IOREG information of the iMac Pro dump provided by @TheOfficialGypsy. Deviations are e.g. the XHCI and ETH0 implementations, which are rather in line with the usual OSX variable naming conventions.

3.) A config.plist ACPI replacement is only possible, if the respective variable is exclusively used along one articular ACPI path implementation. SL01 or SL05 might be typical examples. The PXSX variable however is used along different device and ACPI path implementations. A PXSX config.plist ACPI replacement would rename all PXSX variables in the same way for all devices and along all ACPI path implementations. This is the last thing we want. Note that e.g. /PCI0/RP01/PXSX, /PCI0/RP05/PXSX, /PCI0/RP07/PXSX addressees and implements different XHC controllers. Thus to particularly rename /PCI0/RP01/PXSX to XHC2, /PCI0/RP05/PXSX to XHC3 and /PCI0/RP07/PXSX to XHC4, we have to directly implement and apply each PXSX variable replacement in the frame of the XHC2, XHC3 and XHC4 device implementation within the SSDT.aml instead of performing a general PXSX variable replacement in the config.plist, which would result in a global replacement of all PXSX variables to either XHC2, XHC3 or XHC4.

4.) The "AAPL,slot-name" device implementation is up to my knowledge indeed of purely cosmetic nature.

For know I could implement a link to your script in my guide with the clear message, that this script is able to provide some basic ACPI/PCI information for a user specific and particular hardware/system configuration, which however yet has to be manually implemented in the original SSDT-X299-iMacPro.aml. The information provided by the script might also be incomplete depending on the PCI device implementation. Thus, the proper SSDT-X299-iMacPro.aml device implementation still needs to be adopted/modified manually for each particular deviating hardware/system/slot configuration with the help of IOREG.

Let me know if this answers your questions and if the current resuming conclusion/idea would be in line with your personal endeavours/ideas.

Kind regards,

KGP

 

[kgp]

1.) I searched first. Designare pops up in a lot of signatures without a lot of good information. I did finally find some good info.
2.) your #5 was really what I needed for an answer. Sorry you spent so much time on detail.

I have a great deal of technical knowledge and analytical skills, even a Computer Science degree. I'll apply those skills as needed but they are geared toward my job, not hackintoshes. I've built 6 hackintoshes to date, but usually stick with known builds and tools because I don't have a lot of time to develop clover/kexts/etc. expertise. What I have built so far:

• i5 NUC
• i5 Z68 MATX
• i7 Z68 MATX
• i7 H61 ITX
• i7 Z77 ITX
• i7 Z170 ITX -- in the tiny Lian-Li PC-TU100 case -- my favorite

I need the 18 core hackintosh for work related tasks. My VM farms are now requiring 8 vCores per VM. my old Mac Pro is maxed out at 12 cores (24 threads/vCores). The i9-7980XE will allow 4 - 8 vCore VMs with a couple of real cores left over to run the MacOS. If it all goes sideways, I'll convert the machine to RedHat or Windows but that would suck. I wanted the 18 core iMacPro but $11,000 for what I need is just too much.

I'm not going to gripe or complain on your topic. There's too much pissyness and snark as it is on the forums IMHO.

Thank You.

Just to clarify one important thing for everybody in summary and conclusion. Something, which still seems deemed necessary to avoid any further misunderstanding and confusion along this thread. It was never my intention to question anybody's skills. This would be something totally outside all my intentions, competencies and responsibilities. Moreover, for me it is even totally impossible to estimate the skills of all estimated and sometimes even to me totally unknown users. Every user must be conscious about the technical requisites when implementing a yet unknown or not fully controlled hardware component, which has not been fully or sufficiently addressed by this guide or along this thread. Every user has to decide by himself/herself whether or not he/she would be able to do so. However, I have to interfere as soon the particular claims and complains of specific users start to affect or endanger the entire thread and start to deviate from reality or other reported user experience. This is not at all any bad intention from my side and should not be interpreted as a personal attack towards the respective user. I deeply regret for any occurrence, which might have let to this impression and I would like to outline once more that any constructive user feedback that helps in the further evolution of this guide and thread in contrary is highly appreciated and more than welcome.

Thus, @macs_forever , from my side there is also absolutely no need that you have to outline and justify your personal technical abilities and skills at this point as you did above... Anyway, as already done, I appreciate to know now about your background, skills and experience formerly totally unknown to me.

This just to avoid any further misunderstanding..

A good hacking and all the best,

KGP

 

[kgp]

Hey KGP, It's been a while since I'm busy working using my machine. I'm currently using 10.3.2 just fine, but noticed you updated to 10.3.3. Now I'm finding out about the new beta 10.3.4. I saw this link and wanted your thoughts about it:

http://appleinsider.com/articles/18...users-about-32-bit-softwares-impending-demise

Somebody might have shared something on here already about it and if they did, just let me know what post number it is and I'll go and read it. If not, then this might be something to talk about. I haven't looked into it much, but I hope it doesn't affect using apps like Photoshop, Illustrator, InDesign, Premier and like kind apps. Look forward to hearing your response, later...

PS - I see you reached 65,000+ on your GB score - GOOD FOR YOU! How'd you get there? Just curious.

My personal opinion to the topic addressed in the contribution you linked above is the following. As we passed already nearly a decade after introducing the first 64-bit systems, I think it is really time to start discarding 32-bit software for 64-bit systems. Apparently, 10.13.4 is just a first step towards this direction and still seems no to have any further major implications against running likely outdated 32-bit software on 64-bit systems, apart from a first simple warning that you are running 32-bit software instead of 64-bit software on a 64-bit system. I would rather interpret the latter in my opinion yet tiny novel implication as some clear signal of Apple towards all software developers. I just want to stress that all this is really my personal opinion and impression, which might be totally at odd with the opinion of other estimated users.

To your other question. After delidding my i9-7980XE and with my current water blocking system, I am successfully able to run the latter processor on my system @ 4.7GHz with "CPU Core Ratio" set to "Sync all Cores". All other related BIOS settings have been outlined just a few posts ago. However, I want to clearly advice against running the delidded i9-7980XE @ 4.8GHz, as occasionally intended during one of my benchmark runs. The latter might result in an exponential increase of the CPU Core Voltage and might result in a severe damage of either your CPU or mainboard. If at all, always increase the CPU Core Voltage stepwise and manually and take care that it never exceeds 1.25V by far. When running the CPU at @4.7GHz, a manual CPU Core Voltage of 1.22V seems sufficient. When applying OC, always carefully watch your CPU Temps! The CPU Temps might not only strongly depend on your water blocking implementation but also on the processor frequency and especially on the tightly related CPU Core Voltage implementation!

A good hacking and OC,

KGP

 

[rudey]

1.) AML "Compatible" field: in my understanding, the "Compatible" field provides information about the compatible OSX device/driver for the respective device. Many times the compatible OSX device/driver is also once more reflected under "device ID" or "IOName" (see e.g. again the OSXWIFI example). Usually it is the second entry in the "Compatible" field. Note that the "compatible" device implementation is also not always deemed necessary within each SSDT.aml device implementation. This mainly depends on the particular necessity of the "Compatible" device implementation for each PCI device, which can be simply experimentally confirmed by the successful PCI driver implementation.

2.) I already intended to outline, detail and describe the Apple device naming conventions and necessary ACPI replacements in Section E.9.1). If you feel that some variables are not adequately renamed or implemented, feel free to provide improvements or suggestions. Wherever possible, I also tried to account for the IOREG information of the iMac Pro dump provided by @TheOfficialGypsy. Deviations are e.g. the XHCI and ETH0 implementations, which are rather in line with the usual OSX variable naming conventions.

3.) A config.plist ACPI replacement is only possible, if the respective variable is exclusively used along one articular ACPI path implementation. SL01 or SL05 might be typical examples. The PXSX variable however is used along different device and ACPI path implementations. A PXSX config.plist ACPI replacement would rename all PXSX variables in the same way for all devices and along all ACPI path implementations. This is the last thing we want. Note that e.g. /PCI0/RP01/PXSX, /PCI0/RP05/PXSX, /PCI0/RP07/PXSX addressees and implements different XHC controllers. Thus to particularly rename /PCI0/RP01/PXSX to XHC2, /PCI0/RP05/PXSX to XHC3 and /PCI0/RP07/PXSX to XHC4, we have to directly implement and apply each PXSX variable replacement in the frame of the XHC2, XHC3 and XHC4 device implementation within the SSDT.aml instead of performing a general PXSX variable replacement in the config.plist, which would result in a global replacement of all PXSX variables to either XHC2, XHC3 or XHC4.

4.) The "AAPL,slot-name" device implementation is up to my knowledge indeed of purely cosmetic nature.

For know I could implement a link to your script in my guide with the clear message, that this script is able to provide some basic ACPI/PCI information for a user specific and particular hardware/system configuration, which however yet has to be manually implemented in the original SSDT-X299-iMacPro.aml. The information provided by the script might also be incomplete depending on the PCI device implementation. Thus, the proper SSDT-X299-iMacPro.aml device implementation still needs to be adopted/modified manually for each particular deviating hardware/system/slot configuration with the help of IOREG.

Let me know if this answers your questions and if the current resuming conclusion/idea would be in line with your personal endeavours/ideas.

Kind regards,

KGP

Thanks for the clarification. I think the script in its current state should provide at least rudimentary information to new users. Any enhancements to it I’ll start in a new branch. Any work with PXSX entries is going to be a bit complicated so it might take some time to parse these out of ioreg. Feel free to include it in your guide, I would just of course caution that the script is WIP and should be tested by others as it may not account for all use cases. Currently the script works fine on the Asus X299 Deluxe, I have no idea how it works on other boards.

 

[gxsolace]

Well I don't understand why you want to have FakeSMC in /L/E instead of /EFI/Clover/kexts/Other....

In any case, did you perform the following steps after installing FakeSMC in /L/E with admin permission?

sudo chmod -R 755 /Library/Extensions/FakeSMC.kext
sudo chown -R root:wheel /Library/Extensions/FakeSMC.kext
sudo touch /Library/Extensions && sudo kextcache -u /

@kgp - I did yeah.

For the FakeSMC with plugins, do I just install that into /EFI/Clover/kexts/Other where they're embedded inside the FakeSMC.kext? Or do I install the sensor plugins separately?