apianti Posted April 24, 2019 Share Posted April 24, 2019 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. Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
hardcorehenry Posted April 25, 2019 Share Posted April 25, 2019 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 . Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 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....... Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 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. Link to comment Share on other sites More sharing options...
yapan4 Posted April 25, 2019 Share Posted April 25, 2019 I also continue to test and report the news if it appears. 1 Link to comment Share on other sites More sharing options...
hardcorehenry Posted April 25, 2019 Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 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 Link to comment Share on other sites More sharing options...
hardcorehenry Posted April 25, 2019 Share Posted April 25, 2019 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 Link to comment Share on other sites More sharing options...
hardcorehenry Posted April 25, 2019 Share Posted April 25, 2019 Sorry, I've made mistake when renaming CP0E and CP0F now should be good. Best double check. config(22).plist Link to comment Share on other sites More sharing options...
apianti Posted April 25, 2019 Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
apianti Posted April 25, 2019 Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
apianti Posted April 25, 2019 Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 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. Link to comment Share on other sites More sharing options...
yapan4 Posted April 25, 2019 Share Posted April 25, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
obus Posted April 25, 2019 Author Share Posted April 25, 2019 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 Link to comment Share on other sites More sharing options...
apianti Posted April 25, 2019 Share Posted April 25, 2019 @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. Link to comment Share on other sites More sharing options...
yapan4 Posted April 25, 2019 Share Posted April 25, 2019 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 Link to comment Share on other sites More sharing options...
obus Posted April 30, 2019 Author Share Posted April 30, 2019 (edited) 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 2 Link to comment Share on other sites More sharing options...
skyflying5 Posted May 8, 2019 Share Posted May 8, 2019 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 Link to comment Share on other sites More sharing options...
yapan4 Posted May 8, 2019 Share Posted May 8, 2019 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 Link to comment Share on other sites More sharing options...
Recommended Posts