Contribute
Register

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

Status
Not open for further replies.
IDER is not the only issue, from your DSDT renaming list there are many other variables that are not found in my unpatched ioreg for the R6E. I am the one repeating myself, because I keep asking you what is the methodology you've used to find that these were the correct naming matches and replacements needed for your board... and you're unable to answer this simple question (or are you just avoiding it?).

Nevertheless, I believe I understand now which methodology you've used to come up with this list of replacements.

Have a good night.

Of course you can repeat yourself as often you want and you can continue addressing me in your posts .. But this will not change the fact that I don't know how to help you further.. I will not comment in more detail on each ACPI Replacement or SSDT.aml implementation. I simply do not have the time to do so. This could become endless.. By the way, it is 1 a.m. in the morning here, thus I really have to sleep now.

BTW, if your question would be really as simple as you state above, I would just simply answer your question...

In any case, I applied just the same approach and methodology, which I also used and applied for the XHC USB kext creation, which honestly I described in much more detail within a corresponding guideline.

You still find the former XHC USB Kext Creation Guideline here ... Hope this helps you in your issues in verifying your ACPI Replacements and SSDT.aml implementations..

Good night..
 
Last edited:
Of course you can repeat yourself as often you want and you can continue addressing me in your posts .. But this will not change the fact that I don't know how to help you further.. I will not comment in more detail on each ACPI Replacement or SSDT.aml implementation. I simply do not have the time to do so. This could become endless.. By the way, it is 1 a.m. in the morning here, thus I really have to sleep now.

In any case, I applied just the same approach and methodology, which I also used and applied for the XHC USB kext creation, which honestly I described in much more detail within a corresponding guideline.

You still find the former XHC USB Kext Creation Guideline here ... Hope this helps you in your issues in verifying your ACPI Replacements and SSDT.aml implementations..

Good night..


First of all, nobody is forcing you to stay awake to answer my questions, nor to answer them at all.

Don't get me wrong, but your DSDT replacements seem to come out of nowhere... I'm not saying that they are incorrect, most of them (if not all) seem actually legit!

So, either you perfectly know what you're doing and you have the technical knowledge to match the ioreg entries of your board with those from a real iMacPro1,1 and in which case you don't want to share how you're able to find the correct replacements (that's what I understand from your answers). Or you're getting these replacements from somewhere/someone else, in which case maybe you should mention your source in the guide because people like me tend to think that you are the one who came up with these replacements and therefore assume that you have the technical knowledge to help...

Anyway, I thought that simple questions would have received simple answers. I was not expecting to (again) face your attacks. But I'm starting to see a pattern in your answers (and I hope I'm wrong). It appears that when people post here to ask technical questions for which you don't know the answer, you either get upset quite easily and tend to turn this into personal attacks or you try to revert the situation where others are seen as the idiots for not knowing the answer... I'm not sure this is the right approach to build a community. I have myself written hackintosh guides before, and I've been contributing to the hackintosh community for more than 12 years now, so I believe I know what I'm talking about.

My initial post #4378 could have been answered very simply with a: "I don't know, I found these DSDT patches from user XXXX on Forum YYYY". But instead you preferred to muddy the waters.... and that says a lot.
 


First of all, nobody is forcing you to stay awake to answer my questions, nor to answer them at all.

Don't get me wrong, but your DSDT replacements seem to come out of nowhere... I'm not saying that they are incorrect, most of them (if not all) seem actually legit!

So, either you perfectly know what you're doing and you have the technical knowledge to match the ioreg entries of your board with those from a real iMacPro1,1 and in which case you don't want to share how you're able to find the correct replacements (that's what I understand from your answers). Or you're getting these replacements from somewhere/someone else, in which case maybe you should mention your source in the guide because people like me tend to think that you are the one who came up with these replacements and therefore assume that you have the technical knowledge to help...

Anyway, I thought that simple questions would have received simple answers. I was not expecting to (again) face your attacks. But I'm starting to see a pattern in your answers (and I hope I'm wrong). It appears that when people post here to ask technical questions for which you don't know the answer, you either get upset quite easily and tend to turn this into personal attacks or you try to revert the situation where others are seen as the idiots for not knowing the answer... I'm not sure this is the right approach to build a community. I have myself written hackintosh guides before, and I've been contributing to the hackintosh community for more than 12 years now, so I believe I know what I'm talking about.

My initial post #4378 could have been answered very simply with a: "I don't know, I found these DSDT patches from user XXXX on Forum YYYY". But instead you preferred to muddy the waters.... and that says a lot.

a.) Nobody is attacking you or is mudding waters. I already repeatedly tried to answer your questions. I did not get upset at any point or turned everything into personal attacks (however you do so now above)... I also don't see why anybody should feel like an idiot because of the support I am intending to give. Man, what are you talking about? Along all the 4300 posts, I only faced exceptional disputes with a few special people, and apparently you seem to be one of them. I have no interest that all this again results in a 20 pages discussion with personal insults and ugly disputes in public. So please let's stop at this point. o.k.?

b.) I already implemented section 9., 9.1 and 9.2 with some explanation concerning the entire approach.

c.) I referred in addition to my kext creation guide line and provided you the link to see the details.

d.) Based on a.), b.) c.), one would expect that all this information is tentative enough to understand how IOREG entries, ACPI Replacement patches or individual SSDT-X299.aml implementations relate with each other. I also thought it might be explanation enough to know how to adopt and modify the ACPI patches and SST-X299 implementations originally developed by @apfelnico also for your system (take once more note that IOREG is the corner stone to do so).

d.) I don't see any further "SIMPLE QUESTION" from your side that could be answered just within a simple answer from my side.

e.) I clearly and repeatedly state in my guide who is the originator of the original SSDT-X299.aml and most of the ACPI replacement patches and to whom you can address your questions, in case all information I already delivered does not satisfy your expectations and needs. It should be also tentative enough, what have been my personal contributions. I don't see anything I would have to justify for.

f.) The entire ACPI and SSDT approach cannot be explained or detailed within one "SIMPLE ANSWER". I adopted and further modified the original SST-X299.aml of @apfelnico by learning from doing and I expect you to do the same.

g.) I never asked you to incline for the Rapage VI.. that was basically your decision... Now you have to see what you can do out of it.

Saying that, for me the discussion between me and you is closed.

With my best intention, I wish you all good luck necessary to succeed with your endeavour!

KGP
 
1) kgp already answered that in post #4101
2) Right now I'm on iMacPro 1.1 with patched bios 1004 with unlocked MSR 0xE2. Havent had time to update bios.
And as I stated before, everything was working while I was using imac 17.1 as well.
3) All drivers are in Other only.

Hi @rabish

I am in the process of building a new X299 system that is very similar to your configuration, ASUS X200 Prime-A but with an Intel Core i9-7920X CPU. One of the first things I tried to do was update the BIOS. I followed KGP's guide in secant B1 exactly, everything went as planned, although my Terminal output in part 8 was slightly different, which I didn't think was an issue.

However, when I went to update the BIOS, it states that the file (named X299D.CAP as required) is not a valid BIOS file. I was able to update to an unpatched version or 1102 but not the patched one.

If/when you update your BIOS, I would appreciate any help or insight you could offer as to what you did to make it work.
 
Hi @rabish

I am in the process of building a new X299 system that is very similar to your configuration, ASUS X200 Prime-A but with an Intel Core i9-7920X CPU. One of the first things I tried to do was update the BIOS. I followed KGP's guide in secant B1 exactly, everything went as planned, although my Terminal output in part 8 was slightly different, which I didn't think was an issue.

However, when I went to update the BIOS, it states that the file (named X299D.CAP as required) is not a valid BIOS file. I was able to update to an unpatched version or 1102 but not the patched one.

If/when you update your BIOS, I would appreciate any help or insight you could offer as to what you did to make it work.

You have ASUS X299 Prime-A so your patched bios file name should be X299A.CAP instead of X299D.CAP

X299D.CAP is for ASUS X299 Prime Deluxe motherboard!
 
Just updated to Clover 4392. Here's what I found out:
  • EmuVariableUefi-64.efi: I read reports saying that this was longer necessary with iMacPro1,1 SMBIOS. But without it, the NVidia WebDrivers don't load. So I need this.
  • CsmVideoDxe-64.efi: I read somewhere that this allows for better graphics mode while booting (eg, avoids the stretched Apple logo on 16:9 monitors). But it does not work for me and it causes a text flicker while Clover is loading. This was already noticed on previous version of Clover. So I removed it and have a stretched Apple logo while booting.
  • AptioMemory: I tried OsxAptioFix3Drv-64.efi and AptioMemoryFix.efi and they didn't work. Only the usual OsxAptioFixDrv-64.efi + Test2.efi works.
  • I also got stuck for a while with AptioMemory problems, where no combination of drivers was helping. But only if I booted Clover from the NVME. Booting Clover from the SSD was working. So I reflashed the BIOS, and everything was good again.
In conclusion: I still use the old drivers and if you get stuck in AptioMemory problems where nothing seems to help, reflash/reset the BIOS and try again.

Also note that this is the MSI SLI Plus, so quite a different motherboard than what most people use here. It might be specific to it.
 
If you open the iMacPro ioreg dump, you can browse all the named pci devices. If you select one (IMEI, for example), you will se an IOName key, something like pci8086,a2ba. That identifies the device (8086 being intel, a2ba being the device in question).

If you search for this key in your ioreg (extending the search to key values), you might find a device with exactly the same IOName. If that device has a different name, you can rename it to match.

However, I think this is only needed if you need a kext to load that matches by the device name. You can also check this by selecting the kext in ioreg (for example AppleBusPowerController under EC) that has a key IONameMatch and a value of EC. This kext will not load with EC0 or anything else other that EC.

If a device has no loaded kext in the iMacPro ioreg dump, the rename might be in vain. Perfectionists might want to rename them nevertheless. I even renamed the CPUs, that is like 50 rename rules, probably with no benefit as AppleACPICPU matches by the "processor" device type, so it works with any name.

Thank you @interferenc, this is the methodology I was looking for!

I started comparing both ioreg dumps from my board and the iMacPro1,1 board, and I found patterns in the device descriptions for some already known good replacements, such as EC0 -> EC like you mention.

However, I found that sometimes the same IOName is being used for several names and it requires more guessing/matching with other descriptions.

For AppleBusPowerController for example, will I be able to find the "EC" naming if I decompile the kext? Or is there a better method to know which name corresponds to which kext? What I'm thinking about for instance is to rename "EC" for something else on a real iMacPro1,1 and spot which kext or functionality is impacted, but that would not be very practical. :crazy:
 
Thank you @interferenc, this is the methodology I was looking for!

I started comparing both ioreg dumps from my board and the iMacPro1,1 board, and I found patterns in the device descriptions for some already known good replacements, such as EC0 -> EC like you mention.

However, I found that sometimes the same IOName is being used for several names and it requires more guessing/matching with other descriptions.

For AppleBusPowerController for example, will I be able to find the "EC" naming if I decompile the kext? Or is there a better method to know which name corresponds to which kext? What I'm thinking about for instance is to rename "EC" for something else on a real iMacPro1,1 and spot which kext or functionality is impacted, but that would not be very practical. :crazy:
there is some talk here:
https://www.tonymacx86.com/threads/guide-usb-power-property-injection-for-sierra-and-later.222266/

about EC renaming which may help you
 
Screen Shot 2018-01-28 at 12.59.01.png
Hi guys!

Anyone tried to turn on Intel Quick Sync? I tried Lilu.kext + Shiki.kext but it's still doesn't work... any idea?

Thanks in advance!
 
Status
Not open for further replies.
Back
Top