Clover General discussion

[Modmike]

Hello Clover developers, I write technical documentation and guides several times a week.  I would be happy to pitch in and maintain the Wiki when you get the access sorted out, if you like.

 

Meanwhile there is a BIOS cancer spreading among Asus and Asrock Z390 motherboards in the form of, you guessed it, BIOS upgrades!  

 

Pupin published an ACPI patch that so far works for Z390s with discrete graphics cards.  Unfortunately, those using the onboard IGPU experience a reboot after the first Apple screen completes and the screen flickers, which usually indicates the second progress bar is supposed to start. Z390s started experiencing these issues right after BIOS Ver. 2202 was released. All of them tried 10.14.4 to no avail and were doing clean installs.

 

According to pupin, the problem is an uninitialized variable in Device(RTC) that makes the OSX DSDT parser freak out.

 

Another member complained of the same issue on a different board that was fixed by turning system time from ACPI back to legacy.  Unfortunately I could not locate the post and the setting is not available on the Z390.

 

I remember you fixed an RTC issue in 4911 that caused a reboot boot to post screen, not sure if this issue is related.

 

Any ideas?

 

        <dict>
          <key>Comment</key>
          <string>Fix AsRock Z390 BIOS DSDT Device(RTC) bug</string>
          <key>Disabled</key>
          <false/>
          <key>Find</key>
          <data>
          oAqTU1RBUwE=
          </data>
          <key>Replace</key>
          <data>
          oAqRCv8L//8=
          </data>
        </dict>

 

 

[Slice]

1 hour ago, Modmike said:

Hello Clover developers, I write technical documentation and guides several times a week.  I would be happy to pitch in and maintain the Wiki when you get the access sorted out, if you like.

 

Meanwhile there is a BIOS cancer spreading among Asus and Asrock Z390 motherboards in the form of, you guessed it, BIOS upgrades!  

 

Pupin published an ACPI patch that so far works for Z390s with discrete graphics cards.  Unfortunately, those using the onboard IGPU experience a reboot after the first Apple screen completes and the screen flickers, which usually indicates the second progress bar is supposed to start. Z390s started experiencing these issues right after BIOS Ver. 2202 was released. All of them tried 10.14.4 to no avail and were doing clean installs.

 

According to pupin, the problem is an uninitialized variable in Device(RTC) that makes the OSX DSDT parser freak out.

 

Another member complained of the same issue on a different board that was fixed by turning system time from ACPI back to legacy.  Unfortunately I could not locate the post and the setting is not available on the Z390.

 

I remember you fixed an RTC issue in 4911 that caused a reboot boot to post screen, not sure if this issue is related.

 

Any ideas?

 

        <dict>
          <key>Comment</key>
          <string>Fix AsRock Z390 BIOS DSDT Device(RTC) bug</string>
          <key>Disabled</key>
          <false/>
          <key>Find</key>
          <data>
          oAqTU1RBUwE=
          </data>
          <key>Replace</key>
          <data>
          oAqRCv8L//8=
          </data>
        </dict>

 

 

This is a patch for... {kernel, boot.efi, AppleRTC.kext, DSDT, others}

Choose one.

[matgeo]

1 hour ago, apianti said:

You can find pretty much everything about ACPI here, https://uefi.org/acpi. You'll probably want to start with the ACPI specification though, https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf. Be prepared to read a ton of stuff that won't make any sense.... lol.

 

EDIT: You will need iASL tools to decompile the tables to source and compile the tables from source. You either need to build from the source, https://acpica.org/downloads, or https://github.com/acpica/acpica, or you can get RehabMan's prebuilt binaries, https://bitbucket.org/RehabMan/acpica/downloads/.

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.

debug_26535.zip

[Modmike]

6 hours ago, Slice said:

This is a patch for... {kernel, boot.efi, AppleRTC.kext, DSDT, others}

Choose one.

I am going to say DSDT because that what it says in the description but trying to confirm with Pupin. Found more info from him:

 

They are using an uninitialized variable "STAS" in Device(RTC), which makes macOS parser freak out. The patch disables the "If (LEqual (STAS, One)) call from Device(RTC). This call doesn't exist in earlier BIOS versions.

[Slice]

9 minutes ago, Modmike said:

I am going to say DSDT because that what it says in the description but trying to confirm with Pupin. Found more info from him:

 

They are using an uninitialized variable "STAS" in Device(RTC), which makes macOS parser freak out. The patch disables the "If (LEqual (STAS, One)) call from Device(RTC). This call doesn't exist in earlier BIOS versions.

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.

[obus]

16 hours ago, apianti said:

 

I was just being sarcastic. Most likely there is no information for your cpu in the frequency vectors for xcpm, have you tried looking at the output of sysctl machdep.cpu and sysctl machdep.xcpm? Have you tried injecting your exact same cpuid?

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.

 

AppleIntelinfo.rtf

Edited April 10, 2019 by obus

[Modmike]

2 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.

 

I am fine with the patch but it does seem common with Asus and Asrock.  I guess the million dollars question is what BIOS change could cause IGPU Z390-i systems to reboot at the second progress bar but work fine for DGPU users? What parameter or subsystem does the discrete graphics card affect?

 

Crazy as it seems, we couldn't get audio on these boards at the beginning until we installed a video card. Now we are ok but I wonder if that is a clue.

 

I will try to get a user to send me a video of the verbose boot and post to see if it has any more clues.

 

Thanks.

[apianti]

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.

[apianti]

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 ]

 

[obus]

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

[apianti]

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.

[apianti]

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?

[obus]

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 April 10, 2019 by obus

[apianti]

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?

[Modmike]

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.

[obus]

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 April 11, 2019 by obus

[apianti]

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.

[obus]

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 April 11, 2019 by obus

[yapan4]

 

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?

[apianti]

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....

[yapan4]

15 minutes ago, apianti said:

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

Thank you very much!

[Modmike]

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 April 12, 2019 by Modmike

[apianti]

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.

[apianti]

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 April 14, 2019 by apianti

[blackosx]

Great job guys