Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

apianti
apianti
Posted
Posted
13 hours ago, matgeo said:

That is too difficult to understand ....

 

Would you mind taking a look at my debug files , to suggest any droping tables? If there is a way to tell from debug files of course.

 

There's no way to tell without looking at your tables' source, sans a few that are known to cause problems or are unneeded in macOS, mainly DMAR and BGRT. There are plenty of guides on patching ACPI tables, even on this site. But truthfully, if no one has already patched those tables you'll have to either grind through learning ACPI or find someone who has the time, knows ACPI already, and is willing to modify your config to drop and patch tables as needed.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted
6 hours ago, obus said:

No problems @apianti I'm just an old noob and don't even realise that you were sarcastic.

 

For me hackintosh is all about "trial and error". I have zero knowledge in coding or developing so stuff like that is way above my head, but I can still read and hopefully learn how to put things together with some help from people like you.

So please advice me if you have some further input.

 

sysctl -n machdep.xcpm.mode return 1 and yeas I have tried to inject FakeCPUID 0x050654 without success.

 

This is without the fakeid? Or with? Because it looks like you have the original id, and are hitting every p state. I'm not sure what is exactly wrong? 

Processor Brandstring....................: Intel(R) Xeon(R) W-2175 CPU @ 2.50GHz

Processor Signature..................... : 0x50654
------------------------------------------
 - Family............................... : 6
 - Stepping............................. : 4
 - Model................................ : 0x55 (85)

CPU P-States [ 10 11 12 13 14 15 16 17 18 19 20 21 22 24 25 26 28 30 31 32 33 (34) 35 37 41 43 ]

 

Link to comment
Share on other sites
obus
obus
Posted
Posted
1 minute ago, apianti said:

 

This is without the fakeid? Or with? Because it looks like you have the original id, and are hitting every p state. I'm not sure what is exactly wrong? 


Processor Brandstring....................: Intel(R) Xeon(R) W-2175 CPU @ 2.50GHz

Processor Signature..................... : 0x50654
------------------------------------------
 - Family............................... : 6
 - Stepping............................. : 4
 - Model................................ : 0x55 (85)

CPU P-States [ 10 11 12 13 14 15 16 17 18 19 20 21 22 24 25 26 28 30 31 32 33 (34) 35 37 41 43 ]

 

Noop this is with Skylake X fake id 0x5065E4 and with kernel patch: _xcpm_pkg_scope_msrs_PMhart   31 d2 e8 ae fc ff ff -> 31 d2 90 90 90 90 90

Link to comment
Share on other sites
apianti
apianti
Posted
Posted
7 hours ago, Slice said:

This is much more understandable. 

Probably it is true and you really need this patch but I want to say that this is unique situation only for your DSDT. It can't be common.

 

It depends, is it caused by the OEM modifying the firmware or because Aptio was modified and this propagated? He seemed to imply that two OEMs' motherboards with z730 chipset were affected.

 

@Modmike,

 

ACPI tables contain a lot of information related to graphics, it's possible that because the dGPU is there these addresses are corrected when read by macOS from the dGPU's ACPI table(s) instead of the iGPU's ACPI table(s) which then corrects issues.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted
4 minutes ago, obus said:

Noop this is with Skylake X fake id 0x5065E4 and with kernel patch: _xcpm_pkg_scope_msrs_PMhart   31 d2 e8 ae fc ff ff -> 31 d2 90 90 90 90 90

 

Ok, what does sysctl -n machdep.xcpm.vectors_loaded_count say? I imagine what is happening is that there is an MSR not supported by your CPU that is by the mac-only models. You can boot with your original id right? But you're just not getting any actual power management? Pretty sure that there just isn't frequency vector information so it has no information about how to change states. There is a tool script to generate and patch frequency vectors. Also, you have a proper CPU SSDT right?

Link to comment
Share on other sites
obus
obus
Posted
Posted (edited)
27 minutes ago, apianti said:

 

Ok, what does sysctl -n machdep.xcpm.vectors_loaded_count say? I imagine what is happening is that there is an MSR not supported by your CPU that is by the mac-only models. You can boot with your original id right? But you're just not getting any actual power management? Pretty sure that there just isn't frequency vector information so it has no information about how to change states. There is a tool script to generate and patch frequency vectors. Also, you have a proper CPU SSDT right?

sysctl -n machdep.xcpm.vectors_loaded_count return 0

I can NOT boot with my original 1d for Skylake W 0x050654 and that is the weird thing because I can boot with a lot of other Skywell or Broadwell id.

 

Edited by obus
Link to comment
Share on other sites
apianti
apianti
Posted
Posted
1 hour ago, obus said:

sysctl -n machdep.xcpm.vectors_loaded_count return 0

I can NOT boot with my original 1d for Skylake W 0x050654 and that is the weird thing because I can boot with a lot of other Skywell or Broadwell id.

 

 

Can you not with your original id and the patch for scope_msrs? Did you not post two different pics in the other topic, one with pm and one without? I thought the difference was you just didn't use fakeid. What exactly happens when you boot with your original id and the patch?

Link to comment
Share on other sites
Modmike
Modmike
Posted
Posted
5 hours ago, apianti said:

 

It depends, is it caused by the OEM modifying the firmware or because Aptio was modified and this propagated? He seemed to imply that two OEMs' motherboards with z730 chipset were affected.

 

@Modmike,

 

ACPI tables contain a lot of information related to graphics, it's possible that because the dGPU is there these addresses are corrected when read by macOS from the dGPU's ACPI table(s) instead of the iGPU's ACPI table(s) which then corrects issues.

 

So that was embarrassing, turns out it was corrupt config.plist. Started from scratch and all is good again.

Link to comment
Share on other sites
obus
obus
Posted
Posted (edited)
8 hours ago, apianti said:

 

Can you not with your original id and the patch for scope_msrs? Did you not post two different pics in the other topic, one with pm and one without? I thought the difference was you just didn't use fakeid. What exactly happens when you boot with your original id and the patch?

Yes but even if I boot with Skylake X id 0x0506E4 the original id of Skylake W 0x050654 appears in the Darwin dump. The two pics in the other topics showing Darwin dump from my processor 2175 booted with 0x0506E4 and from an original iMac Pro1.1 with a 2140b processor. Both have the same id in Darwin dump 0x050654.

 

Original id gives me Hang at end random seed +++++++++++

 

You wrote in the other topic that: "the problem is because of the specialization of the mac-only CPU models, it has an MSR that is not present in other CPUs."

 

The last million dollar question is that there is a guy here with an ASUS C422 mobo and an original "Mac" Xenon W 2140b and he has exactely the same problem as we have with our processors. How can we explain that?

 

I'm really confused here and unfortunately not qualified to solve the problems with my lack of knowledge. That's why I should be so grateful if you or anybody else could help me to find a solution.

 

Best regards

obus

Edited by obus
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

I was just speculating because that's what _xcpm_pkg_scope_msrs does, and you guys are getting it working by changing the id and skipping the call to that function. It's possible to not setup a device correctly from the firmware if it's not known that it needs setup in a certain way. I'm sorry, I meant the bootstrap patch, not the other. You posted that you used the bootstrap patch and then were able to boot but had full throttle, you had the correct situation then and you just need frequency vectors for your cpu to get pm.

Link to comment
Share on other sites
obus
obus
Posted
Posted (edited)
28 minutes ago, apianti said:

I was just speculating because that's what _xcpm_pkg_scope_msrs does, and you guys are getting it working by changing the id and skipping the call to that function. It's possible to not setup a device correctly from the firmware if it's not known that it needs setup in a certain way. I'm sorry, I meant the bootstrap patch, not the other. You posted that you used the bootstrap patch and then were able to boot but had full throttle, you had the correct situation then and you just need frequency vectors for your cpu to get pm.

So if I understand you correct I can try go with the bootstrap patch (with basically is just a FakeCPUId if I understand things correct) and then use PikerAlpha:s freqVectorsEditors script?

Edited by obus
Link to comment
Share on other sites
yapan4
yapan4
Posted
Posted

 

42 minutes ago, apianti said:

I was just speculating because that's what _xcpm_pkg_scope_msrs does, and you guys are getting it working by changing the id and skipping the call to that function. It's possible to not setup a device correctly from the firmware if it's not known that it needs setup in a certain way. I'm sorry, I meant the bootstrap patch, not the other. You posted that you used the bootstrap patch and then were able to boot but had full throttle, you had the correct situation then and you just need frequency vectors for your cpu to get pm.

The main desire is to get rid of any patches on this "Apple-native" HW. Is this possible?

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

No, the bootstrap patch is not a fakeid unless you are using a patch for a different cpu. As far as I know the boot strap patch was designed for one of the other previous unsupported cpus and it probably wasn't modified since for other cpus since.

5 minutes ago, yapan4 said:

 

The main desire is to get rid of any patches on this "Apple-native" HW. Is this possible?

Not possible, there's patches that happen without you knowing and they must. Adding more isn't a big thing really....

Link to comment
Share on other sites
Modmike
Modmike
Posted
Posted (edited)
On 4/10/2019 at 8:29 AM, Slice said:

This is much more understandable. 

Probably it is true and you really need this patch but I want to say that this is unique situation only for your DSDT. It can't be common.

 

So more Asrock Z390 boards are getting hit with this issue. pupin gave a really clear example of why this is happening:

 

For the record, older versions would contain this in DSDT: 

        Device (RTC)
        {
            Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0070,             // Range Minimum
                    0x0070,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {8}
            })
        }

Newer versions of Asrock and Asus contain this: 


        Device (RTC)
        {
            Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0070,             // Range Minimum
                    0x0070,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                IRQNoFlags ()
                    {8}
            })
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((STAS == One))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }

Asrock and Asus added a status method (_STA), which queries the STAS variable in the newer DSDTs. The problem is that the STAS variable is not initialized, and when the macOS DSDT parser checks Device(RTC) in the DSDT, it does not like this, and freaks out.

Pupins patch changes the condition in the expression "If ((STAS==One))" to an always True condition, thus eliminating the problematic check, and resulting in RTC._STA() always returning 0x0F.

Seeing that this affects 2 different board manufacturers makes him think that the error may possibly come from a newer version of APTIO. If this is the case, it might appear on more boards in the future.

 

Is there a way to fix this in Clovers DSDT patcher?

Edited by Modmike
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Yeah, just compare the two binary tables together in a hex editor and that will give you the patch, just make sure that you search the original table with the source patch to make sure it doesn't repeat or you need to add some more of the data from around the source.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted (edited)

Clover wiki has been migrated back to sourceforge to try to keep it as up to date as possible, and is now live. Please use this wiki as official from now on.

https://sourceforge.net/p/cloverefiboot/wiki/Home/

 

EDIT: You may comment fixes and suggestions to a page, but they are subject to moderation by admin (basically slice and I) unless you are a team member (but ultimately still manually moderated if necessary).

 

EDIT2: Forgot to give a huge shout out to @arsradu for migrating and updating the wiki. Thanks!

Edited by apianti
  • Like 10
  • Thanks 2
Link to comment
Share on other sites
ea dd
ea dd
Posted
Posted (edited)

Hi, all

 

Recently i started using Clover 2.4k rev 4844 and it could not boot Windows 10 with MBR partition + NTFS file system.

Booting process throws below error. Of course, i always choose System Reserved partition for Windows 10 booting.

 

winbooterror.thumb.JPG.1ce7cf50ec418a67554bdd5acffeb75d.JPG

 

 

Before this, i was using    Clover 2.4k rev 4003 for long time and it can boot Windows 10 with MBR partition + NTFS file system without problem.

 

 

Windows 10 with MBR booting feature is intentionally removed from recent clovers or is it bug?

 

 

EDIT:

Also i have r4813 and it has same problem when booting windows 10.

Actually r4813 and r4844 are installed on USB stick and r4003 is installed on HDD partition not EFI. So i installed r4003 on USB and tried to boot Windows 10 from it and it fails as well. Error is same as before.

 

So clover installed on USB could not boot windows 10 legacy? Can anyone check it?

 

 

tnx,

Edited by ea dd
Link to comment
Share on other sites
apianti
apianti
Posted
Posted (edited)

There is an issue with legacy booting from a different device not on the same bus, I am not sure there is a way to fix it because of firmware drive numbers appearing pretty much random to the EFI emulation.

 

EDIT: Typo.

Edited by apianti
Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted
4 hours ago, Maniac10 said:

 thank you guys for moving the wiki, it was a much needed change. Do you have plans to add the translated pages too? I can work on the spanish section and get it up to date. 

I can only speak 2 languages fluently. One of which is my native language. :)) I also speak a bit of Spanish, French, Italian, Russian, and currently learning a bit of Japanese, as well. I definitely know the bad words in some of these. :))) But, for these last ones, I can't say I speak well enough to get a translation done.

 

So, in other words, yeah, that would help. :)

  • Like 2
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...