Help installing Mojave on Xeon W-2175 and Asus WS C422 mobo

[apianti]

Yeah, I am unsure why it's not working straight up, it should be, the only thing I can think of is that there is still a separate software channel for the macOS that is on iMacPros...? Also, if you have it working with your ssdt, and two patches, then it's working and you should just use that, it's not really going to affect anything if it's working. Do you have working cpu power management? Do you have working sleep/wake? If yes, then you're good there's no point in continuing to try to remove patches that give you a working machine.

[obus]

8 hours ago, apianti said:

Yeah, I am unsure why it's not working straight up, it should be, the only thing I can think of is that there is still a separate software channel for the macOS that is on iMacPros...? Also, if you have it working with your ssdt, and two patches, then it's working and you should just use that, it's not really going to affect anything if it's working. Do you have working cpu power management? Do you have working sleep/wake? If yes, then you're good there's no point in continuing to try to remove patches that give you a working machine.

CPU power management with freqVeqtors and sleep/wake is working OOB without any SSDT:s and with dropped oem SSDT. CPU is recognised OOB and everything else in macOS including things like iTunes streaming video is working like a charm so yeas with PMhart:s _xcpm_pkg_scope_msrs patch and FakeCPUid everything is good.

Still it nags me that I need to use those patches. There must be a way to get rid of them and get the system more vanilla like the X299 with Skylake X processors.

 

Is there a way to hardcode the kernel with _xcpm_pkg_scope_msrs patch and FakeCPUid?

 

"the only thing I can think of is that there is still a separate software channel for the macOS that is on iMacPros...? "

From the beginning it was if I understand things correctely. If it's like that is there a way to find out?

If you do a reinstallation from recovery environment it should be reinstalled with the right version if of course the system is recognised as a real iMacPro1,1 or?

Edited April 25, 2019 by obus

[hardcorehenry]

1 hour ago, obus said:

CPU power management with freqVeqtors and sleep/wake is working OOB without any SSDT:s and with dropped oem SSDT. CPU is recognised OOB and everything else in macOS including things like iTunes streaming video is working like a charm so yeas with PMhart:s _xcpm_pkg_scope_msrs patch and FakeCPUid everything is good.

Still it nags me that I need to use those patches. There must be a way to get rid of them and get the system more vanilla like the X299 with Skylake X processors.

 

Is there a way to hardcode the kernel with _xcpm_pkg_scope_msrs patch and FakeCPUid?

 

"the only thing I can think of is that there is still a separate software channel for the macOS that is on iMacPros...? "

From the beginning it was if I understand things correctely. If it's like that is there a way to find out?

If you do a reinstallation from recovery environment it should be reinstalled with the right version if of course the system is recognised as a real iMacPro1,1 or?

In your config.plist you renamed CPxx -> PRxx, but not all, in your generated SSDT CP0E and CP0F remained with original names. It "might" be cosmetics but better double check. I'm looking right now at KGP's renames .

 

[obus]

23 minutes ago, hardcorehenry said:

In your config.plist you renamed CPxx -> PRxx, but not all, in your generated SSDT CP0E and CP0F remained with original names. It "might" be cosmetics but better double check. I'm looking right now at KGP's renames .

 

Cheers!

Another good point I will check that out during the day and report back.......

 

[obus]

41 minutes ago, hardcorehenry said:

In your config.plist you renamed CPxx -> PRxx, but not all, in your generated SSDT CP0E and CP0F remained with original names. It "might" be cosmetics but better double check. I'm looking right now at KGP's renames .

 

Could you please elaborate a little what you mean and how you want it to be?

I don't think it matter because I unchecked all cpu related in ACPI when I was testing. But anyway it should be correct. 

[yapan4]

I also continue to test and report the news if it appears.

[hardcorehenry]

46 minutes ago, obus said:

Could you please elaborate a little what you mean and how you want it to be?

I don't think it matter because I unchecked all cpu related in ACPI when I was testing. But anyway it should be correct. 

This is your generated SSDT, you posted. Uder PR13 there are CP0E and CP0F. That would mean you ommited this renames. I thing that CP0E should be renamed as PR14, CP0F as PR15 and the rest below PR16 ...and so on. There is no CP0E and CP0F in config acpi renames and the rest sould also change names. If my bad english isn't good enough post your config and original CPU OEM extracted with clover F4, because i'm not sure about originals CPU OEM names.

Edited April 25, 2019 by hardcorehenry

[obus]

12 minutes ago, hardcorehenry said:

This is your generated SSDT, you posted. Uder PR13 there are CP0E and CP0F. That would mean you ommited this renames. I thing that CP0E should be renamed as PR14, CP0F as PR15 and the rest below PR16 ...and so on. There is no CP0E and CP0F in config acpi renames and the rest sould also change names. If my bad english isn't good enough post your config.

If I check my ioreg  (booted with disabled cpu renames in config) under cpu I think it's correct.

 

config.plist

MacPro.ioreg

[hardcorehenry]

33 minutes ago, obus said:

If I check my ioreg  (booted with disabled cpu renames in config) under cpu I think it's correct.

 

config.plist

MacPro.ioreg

Check in your ioreg if CP0E and CP0F changed, I'm not 100 % sure if you should do the same with CP1E, CP1F...and so on, for safety dont remove your orginal config.plist, but surely you already know about itconfig(22).plist

[hardcorehenry]

Sorry, I've made mistake when renaming CP0E and CP0F now should be good. Best double check. config(22).plist

[apianti]

Ok, yeah, sorry my bad, I was in a hurry when I told you to rename your CPXX to PRXX, it should convert them from the hex to decimal values, so CP0E is PR14, also you apparently need every single one, no skipping. Are you getting anywhere with verbose boot without those patches two patches? Or does it not even initialize the kernel? Because I don't see any way around that otherwise. There is no need to name the SSDT anything specific, it just searches the directory, you can specify which order though if you need to, so any of that is irrelevant. Patching the kernel directly is a worse solution than patching on the fly. You seems to have a working system, so I would just use it and not worry because those patches are literally nothing, there's more patching going on behind the scenes that you can't disable or you can never boot... I think you have working system the only way you will be able to get working system if the corrected SSDT does not change anything. And there's no point in trying to do better unless someone with the exact hardware can figure out exactly why, usually you need the same apple machine you want to use to do it too so you can compare them. You can check the version number in about this mac and see if it is a known version of macOS or if it is one of the specially known iMacPro only, or that it is not either and that would be weird.

 

EDIT: Unsure about the internet recovery install with iMacPro, don't know what it will do but it would be a better way to get the correct image for whichever SMBIOS you're using since there appears to be some deviations in the software channels going on, unsure if they are permanent though.

Edited April 25, 2019 by apianti

[obus]

31 minutes ago, apianti said:

Ok, yeah, sorry my bad, I was in a hurry when I told you to rename your CPXX to PRXX, it should convert them from the hex to decimal values, so CP0E is PR14, also you apparently need every single one, no skipping. Are you getting anywhere with verbose boot without those patches two patches? Or does it not even initialize the kernel? Because I don't see any way around that otherwise. There is no need to name the SSDT anything specific, it just searches the directory, you can specify which order though if you need to, so any of that is irrelevant. Patching the kernel directly is a worse solution than patching on the fly. You seems to have a working system, so I would just use it and not worry because those patches are literally nothing, there's more patching going on behind the scenes that you can't disable or you can never boot... I think you have working system the only way you will be able to get working system if the corrected SSDT does not change anything. And there's no point in trying to do better unless someone with the exact hardware can figure out exactly why, usually you need the same apple machine you want to use to do it too so you can compare them. You can check the version number in about this mac and see if it is a known version of macOS or if it is one of the specially known iMacPro only, or that it is not either and that would be weird.

 

EDIT: Unsure about the internet recovery install with iMacPro, don't know what it will do but it would be a better way to get the correct image for whichever SMBIOS you're using since there appears to be some deviations in the software channels going on, unsure if they are permanent though.

Just upgraded to macOS 10.14.4 (18E2034) from macOS Mojave 10.14.4 (18E226) no change in booting.

Impossible to boot without_xcpm_pkg_scope_msrs patches (excluded bootstrap patch) and FakeCPUID. without both of them stuck at random seed ++++++++++.

In IORegistryExplorer I found this IOCPUID. The left one is from a original iMacPro and the right one is from my rig.

What kind o CPUID is this? 

 

 

Edited April 25, 2019 by obus

[obus]

58 minutes ago, hardcorehenry said:

Sorry, I've made mistake when renaming CP0E and CP0F now should be good. Best double check. config(22).plist

With config(22) plist I have 29 threads and with my original there is 27 + 0 = 28 threads

config_orig.ioreg

 

config(22).ioreg

Edited April 25, 2019 by obus

[apianti]

Idk what is going on with config someone else gave you. You had fine config from what I saw, you just needed to fix your SSDT. The one thing I see is that at the bottom it says you have MacPro (i386) vs iMac Pro (x86_64) on the original.... I wonder if there is a problem with the SMBIOS.

 

EDIT: Also you fakeid'd so the IOCPUID is going to be different because of that, it's some value that apple uses to determine features probably. It doesn't appear to correlate with the actual cpuid.

 

EDIT2: Actually that is the address of a class that holds information about the cpu.

Edited April 25, 2019 by apianti

[obus]

21 hours ago, apianti said:

Idk what is going on with config someone else gave you. You had fine config from what I saw, you just needed to fix your SSDT. The one thing I see is that at the bottom it says you have MacPro (i386) vs iMac Pro (x86_64) on the original.... I wonder if there is a problem with the SMBIOS.

It's so much going on now so I think I catch the demential too, only 66 years old.

Have to check that @apianti

I have been using the MacPro6,1 SMBIOS before.

Edited April 26, 2019 by obus

[obus]

22 minutes ago, apianti said:

 The one thing I see is that at the bottom it says you have MacPro (i386) vs iMac Pro (x86_64) on the original.... I wonder if there is a problem with the SMBIOS.

 

Funny because for the moment I defenetively have the SMBIOS for iMacPro1,1.

Earlier today I made a clean install of the new version 18E2034 and afterward I imported my old apps and settings from my second MacPro6,1 disk with help of migration assistant. 

I will do a new clean install.

 

Edited April 25, 2019 by obus

[apianti]

You need to change your serial number now.... I can absolutely read what your serial number is: C02TD4LUMX87, the L may be an E. You need to be more vigilant about censoring unique identifiers. In fact I didn't look but did you post all of your ids in your config.plist?

 

EDIT: Actually, you posted all your ids in your config.plist. You will need to change all of them.

Edited April 25, 2019 by apianti

[obus]

32 minutes ago, apianti said:

You need to change your serial number now.... I can absolutely read what your serial number is: C02TD4LUMX87, the L may be an E. You need to be more vigilant about censoring unique identifiers. In fact I didn't look but did you post all of your ids in your config.plist?

 

EDIT: Actually, you posted all your ids in your config.plist. You will need to change all of them.

Thank's @apianti my bad. It all got messed up.

Anyway problem solved. New clean installation macOS 10.14.4 (18E2034) and a new serial.

[yapan4]

I want to go back to ssdPRGen.sh

I think these messages are not normal

Can we be sure that he is doing his job properly?

Edited April 25, 2019 by yapan4

[obus]

9 hours ago, hardcorehenry said:

This is your generated SSDT, you posted. Uder PR13 there are CP0E and CP0F. That would mean you ommited this renames. I thing that CP0E should be renamed as PR14, CP0F as PR15 and the rest below PR16 ...and so on. There is no CP0E and CP0F in config acpi renames and the rest sould also change names. If my bad english isn't good enough post your config and original CPU OEM extracted with clover F4, because i'm not sure about originals CPU OEM names.

Ok @hardcorehenry 

I messed up everything and lost focus. Could you please give it a try again.

origin.zip

config.plist

[apianti]

@yapan4 No, I already know that it is not, but it's giving you the general outline for the way that an CpuPm SSDT is designed, you can easily then change it to be correct. I would prefer that you learned how to do this yourself instead of relying on someone else to do it. Since you should be seeing by this point you must learn a lot to get this to work.

[yapan4]

1 hour ago, apianti said:

@yapan4 No, I already know that it is not, but it's giving you the general outline for the way that an CpuPm SSDT is designed, you can easily then change it to be correct. I would prefer that you learned how to do this yourself instead of relying on someone else to do it. Since you should be seeing by this point you must learn a lot to get this to work.

Ok, then i will try repeat from beginning and now with manually  edited CPU data

[obus]

Now booting with the new boot loader OpenCore (OC). Everything is working as a treat with minor adjustments for CPU like SSDT--CpuPm and freqVectorsEdit (FV). 

Thank's to @vit9696 with the team behind OC, @apianti and @PMheart for patching my CPUID.

 

Edited May 1, 2019 by obus

[skyflying5]

On 4/30/2019 at 10:28 PM, obus said:

Now booting with the new boot loader OpenCore (OC). Everything is working as a treat with minor adjustments for CPU like SSDT--CpuPm and freqVectorsEdit (FV). 

Thank's to @vit9696 with the team behind OC, @apianti and @PMheart for patching my CPUID.

 

i have the w-2150b

i still cannot get the xpcm work

please help me 

ths

[yapan4]

2 hours ago, skyflying5 said:

i have the w-2150b

i still cannot get the xpcm work

please help me 

ths

Hi, @skyflying5

What operating system do you use now?
Is there an open or locked MSR 0xE2 register on your motherboard?
Or better upload please your boot log file