iMac Pro X299 - Live the Future now with macOS 10.14 Mojave [Successful Build/Extended Guide]

[Loloflatsix]

@kgp
This is may be interesting me because suddenly after installing Mojave 10.14.3 on my NVMe SSD , I have black screen issue with my RX 580 after wake on my Gigabyte build.

 

[kgp]

@kgp
This is may be interesting me because suddenly after installing Mojave 10.14.3 on my NVMe SSD , I have black screen issue with my RX 580 after wake on my Gigabyte build.

Thus are you saying that the MSR register on X299 GA motherboards is suddenly locked and one needs to enable a correct XCPM core scope kernel patch, which is disabled by default for more than one year in my EFI-Folder distributions as it is not longer required on any X299 motherboards, as for all X299 motherboards the MSR register is either unlocked by factory default or can be at least unlocked within the BIOS settings? Your GA system suddenly does not boot without an appropriate XCPM core scope kernel patch, or what is the reason for your current considerations?

E.g. my system perfectly works for more than one year including/sleep wake and I do not use the XCPM core scope kernel patch or any other xcpm kernel patch for Skylake-X at all, even on my ASUS board where I still have to disable the MSR lock manually in my BIOS settings.

The sleep/wake issues of @nmano also have been apparently related to his use of a bootstrap kernel patch, he should have never used at all.

Everything can be discussed and investigated if really necessary. But certainly not in the way above. And please, also do not start mixing up things. Broken sleep/wake can have many reasons one has to carefully investigate based on the EFI-Folder in use on each respective system, also in your case.

All resent sleep/wake discussions covering the last 300 posts basically popped up because @nmano never applied what I was providing to him from the very beginning.

And I just try to avoid here a spreading of likely unjustified or inappropriate assumptions after more than one year likely without any need or reason.

 

[Loloflatsix]

Thus are you saying that the MSR register on X299 GA motherboards is suddenly locked and one needs to enable a correct XCPM core scope kernel patch, which is disabled by default for more than one year as it is not longer required on any X299 motherboards, as for all X299 motherboards the MSR register is either unlocked by factory default or can be at least disabled within the BIOS settings?

The sleep/wake issues of @nmano also have been related to his use of the boot strap patch, he should have never used at all.

Everything can be discussed and investigated if really necessary. But certainly not in the way above. And please, also do not need to mix up things. Broken sleep/wake can have many reasons one has to carefully investigate, based on the EFI-Folder in use on each respective system.

No sorry I was not precise enough, my issue isn't about MSR register on X299 GA related, but about RX 580 and black screen issue : I think there is some problem when using HDMi or Dvi port.

edit :
The Dvi port delivers a strange red coloured display on screen , HDMi works fine but with both I've got black screen after wake , I need not USB port limit patch because my GA mobo only have 11 USB ports.

 

[nmano]

Wrong! See post #2,122 !

The XCPM core scope patch is only required for motherboards with locked MSR register, which is definitely not the case on GA motherboards and it is also not the case for all other motherboards different from GA, as even now ASUS BIOS firmware allows after my efforts at ASUS to disable the MSR lock in the BIOS settings.

My entire guidelines base on using an unlocked MSR register for kernel write and therefore the XCPM core scope patch is also by default disabled in my default EFI-Folder distributions! Always provided an unlocked MSR register, Syklake-X is implemented by macOS fully vanilla! No need for any xcpm kernel patches!

It is true that apparently I was implementing the wrong XCPM core scope patch since 10.14 public beta 3, and I did not even realise this flaw, as neither me nor anybody else with unlocked MSR register has any need to enable this remaining XCPM core scope patch, which is anyway DISABLED by default in my default 10.14 EFI-Folder distributions!

Anyway, I wonder why you did not come up much earlier with a friendly advice to correct this flaw, which is anyway totally unimportant for anybody following my guidelines to unlock the MSR register! Many thanks for outpointing this apparent but negligible flaw in my 10.14 EFI-Folder distributions at least now.

Well.. apparently on your X299 GA AORUS GAMING 7, the ACPI device path for Slot-1 changes when also populating Slot-5, no idea why this might be the case. However, anyway one has to consider and verify the correct device path implementation for SSDT creation or adaptation at any time. Thus, in your case one certainly and apparently needs to properly readapt the GPU SSDT implementation after adding or removing a device in Slot-5.

As in any of my iterations for providing the appropriate SSDTs for @nmano, I always revised and considered respective ACPI tables provided in his updated IOREG.saves and also revised in addition after each step his provided PCI snapshots, I don't see any relevance for this never ending and weird discussion from your side, moreover as @mano just confirmed that his former sleep/wake issues have been induced by a xcpm patch I never implemented for Skylake-X and he should not have used at all! Thus his entire sleep/wake issues have not been SSDT related, which we also confirmed by several tests along the last 300 posts.

The last year, I configured hundreds of EFI-Folders and SSDTs for different people and all systems are perfectly working including sleep/wake. I guess, I really know what I do and I really do not need your respective advises. However, nobody is perfect and e.g. the actual flaw in the XCPM core scope patch implemented in my 10.14 EFI-Folder distributions, although anyway always disabled by default and not needed at all if one properly follows my guidelines, clearly shows that also I do commit errors within the anyway manyfold information and material I provide or distirubtue to the community. And I am indeed grateful to anybody for any related corrections or friendly advises.

However, you repeatedly confronted with people along this thread due to your way of transmitting things and opinions. That you now also crash up with me seems just to be another consequence of the latter. The latter was btw also the final reason apart from many other reasons, why I finally decided to abandon the Hackinosh community for a while.

Despite all my unpaid efforts for the community, I feel that my work is neither respected nor appreciated by some of my followers, as I am still continuously questioned and offended for all the free and voluntary non-profit work I am doing here. The initial idea of my guides and threads was also to establish a fruitful collaboration with active contributions and help also provided by others. My guides and threads where never meant to be a place for people not contributing at all and just polishing and manifesting their egos at costs of others. Despite all contributions by few really estimated users, I am performing all work and support here lately basically alone, which finally occupies my entire life and was never intended such by myself from the very beginning.

Finally I don't reject your useful inputs to the community, the opposite is the case:

View attachment 389272

But I certainly do not need your advises for doing my own work and I dislike that you permanently question or interfere my own work moreover!

Thus, I leave it up to you, if your above post was your last post here or anywhere else. This is your personal decision and neither related with me nor anybody else. However, if you keep on posting here, try to relativise your ego and importance. If you continue with posts like the last one above, which in my personal opinion basically has primarily the intention to discredit me and my work in the community by polishing and justifying your own ego at the same time, I indeed would prefer personally that you keep-on posting somewhere else.

All the best,

KGP

Thanks KGP
I test xcpm_core_scope_msrs © Pike R. Alpha patch
My system not wake up.
I noted when core is straight line that time system wake up.

 

[kgp]

Thanks KGP
I test xcpm_core_scope_msrs © Pike R. Alpha patch
My system not wake up.
I noted when core is straight line that time system wake up.

You should not need use any xcpm kernel patch for Skylake-X, also not the core scope patch as your MSR is unlocked by factory default.

 

[pieropontra]

Thanks KGP
I test xcpm_core_scope_msrs © Pike R. Alpha patch
My system not wake up.
I noted when core is straight line that time system wake up.

C'mon mate you're really pissing off @kgp now and this is compromising all of us here! Are you at least able to read properly? please stick to his advice and stop it, just disable that patch and check your msr is unlocked.

I'm a total newbie too but following @kgp ended with a golden vanilla build for me!

Hope you'll solve you problems (without causing @kgp wraith anymore)!

 

[kgp]

Updated X299 10.14.3 and 10.14.4 EFI-Folder distributions

Note just modified X299 10.14.3 and 10.14.4 EFI-Folder distributions EFI-X299-10.14.3-Release-iMacPro1,1-250119.zip and EFI-X299-10.14.4-Beta1-Release-iMacPro1,1-250119.zip which account for a bug in the XCPM core scope kernel patch, as kindly advised by user @Ellybz.

By error, the formerly implemented XCPM core scope kernel patch although anyway disabled by default (as for all X299 motherboards the MSR register can now be fully enabled for kernel write and this one and only remaining disabled XCPM kernel patch in my EFI-Folder distributions is not required at all) was still the one for 10.13, while the proper XCPM core scope kernel patch for 10.14 properly reads:

xcpm_core_scope_msrs © Pike R. Alpha
Find: 31D2E891 FCFFFF
Replace: 31D29090 909090

In all my X99 10.14 EFI-Folder distributions, I however properly implemented the correct core scope kernel patch for 10.14 from the very beginning and the correct 10.14 xcpm core scope patch was also always properly outlined in my respective guidelines

thus there is absolutely no need for any posthum correction in this case . The 10.13 core scope patch bug in my recent X299 10.14 EFI-Folder distributions apparently has just been introduced accidentally in one of my former X299 10.14 EFI-Folder distributions and thus also all subsequent X299 10.14 EFI-Folder distributions continued using the wrong patch up to know.

I therefor regret for any related inconvenience by this unwanted error, likely affecting all users not being able to properly read my guidelines and still working with a locked MSR register or who enabled the erroneous XCPM core scope kernel patch for no reason.

 

[Loloflatsix]

Juste a question :

• according to the previous patch find : BE030000 0031D2E8 94FCFFFF replace : BE030000 0031D290 90909090
• the patch for 10.14 is Find: 31D2E891 FCFFFF Replace: 31D29090 909090 but find : BE030000 1D2E891 FCFFFF replace : BE030000 31D29090 909090 seems more in concordance with the previous ?

 

[nmano]

Updated X299 10.14.3 and 10.14.4 EFI-Folder distributions

Note just modified X299 10.14.3 and 10.14.4 EFI-Folder distributions EFI-X299-10.14.3-Release-iMacPro1,1-250119.zip and EFI-X299-10.14.4-Beta1-Release-iMacPro1,1-250119.zip which account for a bug in the XCPM core scope kernel patch, as kindly advised by user @Ellybz.

By error, the formerly implemented XCPM core scope kernel patch although anyway disabled by default (as for all X299 motherboards the MSR register can now be fully enabled for kernel write and this one and only remaining disabled XCPM kernel patch in my EFI-Folder distributions is not required at all) was still the one for 10.13, while the proper XCPM core scope kernel patch for 10.14 properly reads:

xcpm_core_scope_msrs © Pike R. Alpha
Find: 31D2E891 FCFFFF
Replace: 31D29090 909090

In all my X99 10.14 EFI-Folder distributions, I however properly implemented the correct core scope kernel patch for 10.14 from the very beginning and the correct 10.14 xcpm core scope patch was also always properly outlined in my respective guidelines

View attachment 389289

thus there is absolutely no need for any posthum correction in this case . The 10.13 core scope patch bug in my recent X299 10.14 EFI-Folder distributions apparently has just been introduced accidentally in one of my former X299 10.14 EFI-Folder distributions and thus also all subsequent X299 10.14 EFI-Folder distributions continued using the wrong patch up to know.

I therefor regret for any related inconvenience by this unwanted error, likely affecting all users not being able to properly read my guidelines and still working with a locked MSR register or who enabled the erroneous XCPM core scope kernel patch for no reason.

View attachment 389287

You are man
I love you ummmaaa
Its worked now.Sleep & wake
Find 31D2E891 FCFFFF
Replace 31D29090 909090
After this patched.
I update ioreg after wakeup.
Thanks Friend.

 

[izo1]

Thanks KGP
I test xcpm_core_scope_msrs © Pike R. Alpha patch
My system not wake up.
I noted when core is straight line that time system wake up.

Did you set up your system following the guide on page 1? It’s very clear and straight forward.

I realized there’s about 30 pages of you having trouble with this setup. It really must be at fault on your end imo.

Edit: glad you fixed the issue.

This is my 10th install on a 4th system using this guide but customizing to my own liking and it’s very easy once you understand how vanilla setups work.