Clover General discussion

[arsradu]

8 minutes ago, apianti said:

 

Can't change something that the developer doesn't want to have collaborators or be part of the project. Can get in contact with him and let him know, but really I'm sick of dealing with it, so I don't understand why it's our responsibility to do it when users can easily go to get support for that where it is. Where ever that is, no idea, but I don't see it as our problem in the least anymore. Also, this software is for advanced users/developers, if you can't figure out all of the things you said were "easy for us," then you SHOULD NOT BE USING CLOVER. It can damage your hardware if you incorrectly set stuff, it may even be possible to brick your motherboard, depending on some circumstances. Also, I know slice has been researching this stuff for probably fifteen+ years, I've been doing it for almost ten. I've seen plenty of people around that whole time and still have not learned the most basic of ways that clover operates. I do this to create an educational opportunity, not so people can get macOS for free. And I'm sorry but I think that you saying you can't read a thread is ridiculous. Search for what you are looking for then, how do you think we know this stuff? We read and research. PLISTs are XML files, literally the easiest file format that exists, if you can't figure out an XML file, oh boy.... As for the wiki, its very hard to code and administrate, then update the wiki, especially since I (we all) have limited time. I also have to go to github and change my settings every time I try to log in to edit the wiki. I have asked for helpers but no one seems to want to help keep it up to date. So.... there is the changes topic, which we hoped would give others the information needed to update the wiki. Truthfully, I wish that people would maybe try to research and contribute instead of complaining about everything, when basically three people are trying to keep up with a task set for a large team of people. There are a few who do but most people just complain and offer absolutely no evidence or solutions. We've had this conversation multiple times, we physically cannot do all of these things, so they get prioritized, and the wiki is the lowest priority because, as I said, you should be learning from this.

 

ok, I'll help with Wiki.

[arsradu]

@Slice and @apianti, thank you guys so much for your work here and for the feedback. I wish I could help on the development side. But, as you could probably tell, I'm not a developer. So I'll help with whatever else I can, so you guys can focus on what you do best.

 

Guys, so I tried to edit the Wiki page last night, and I got this error when trying to log in with my Github account. Similar result with Google Auth. Any idea why does this happen? It kinda looks like a bug to me.

 

 

Obviously the account itself is ok, and of course there is an email attached to it (so it cannot be either "email not provided" nor "empty"). How else would you even create a Github account without an email? So that's not the problem. Or maybe I misunderstood the error.

 

Does it work for anyone else? I'm just curious.

Edited April 6, 2019 by arsradu

[apianti]

It's definitely a bug. This is exactly what happens to me, you have to go and edit your github settings, your email can't be private. Mind you this error will still randomly happen and you have to go back, switch it back, then make it public again. Not sure why github wouldn't provide authentication with your github privatized email in this case..... And I can't get any of the other logins to work either.

[arsradu]

41 minutes ago, apianti said:

It's definitely a bug. This is exactly what happens to me, you have to go and edit your github settings, your email can't be private. Mind you this error will still randomly happen and you have to go back, switch it back, then make it public again. Not sure why github wouldn't provide authentication with your github privatized email in this case..... And I can't get any of the other logins to work either.

 

oook... Well, it wasn't set to private. :)) I didn't even know that you can do that... I added another email to my account (in case it didn't like the first one), made that Primary...and same issue... I'll try to play with the Github settings a little more. See if I can figure out a way to make it work.

 

Update: yeah, looks like private or not private...doesn't wanna log in either way.

 

I'll keep trying.

Edited April 6, 2019 by arsradu

[apianti]

I just tried and I can't log in either. And we come to my infuriating dilemma, the problems are that authentication for that site is terrible, and it's never worked well. JrCs isn't around much anymore and he controls it. The only thing I can do is to re-enable the wiki on sourceforge (since its been updated to use better markup). However, this means migrating everything over to sourceforge and adding you to the members team of the project. Someone previously said they would do this but never did anything....

[arsradu]

11 minutes ago, apianti said:

I just tried and I can't log in either. And we come to my infuriating dilemma, the problems are that authentication for that site is terrible, and it's never worked well. JrCs isn't around much anymore and he controls it. The only thing I can do is to re-enable the wiki on sourceforge (since its been updated to use better markup). However, this means migrating everything over to sourceforge and adding you to the members team of the project. Someone previously said they would do this but never did anything....

 

Apianti, if that has any chance of working, we can do that, too. I have a SF account, as well. So we can use that, if necessary. I don't mind. Later on, we can move it back to zetam.org. Problem is, now people will be confused which one is better, and which one they need to use. Having information scattered through multiple places is not really ideal... I don't know. I'm open to suggestions here. Can we turn off the Wiki on zetam.org once the one on SF is ready? Just so we don't confuse people? And also, to have both source-code and Wiki in the same place?

 

As I said, I wanna help. And I'm open to suggestions.

Edited April 6, 2019 by arsradu

[apianti]

Yeah, we can just get JrCs to deactivate the zetam.org wiki at some later date, and hide the sf.net one until it's ready. As I said though, you'd have to completely start from scratch since you can't log in to get the wiki sources, granted the information is all there you'd just have to re-markup, update and add missing stuff. It's just a lot of work, and man, looking at some of this stuff, I don't know if it's at all relevant anymore. It may just be better to copy only the configuration information because a lot of the other stuff is useless. For instance, a lot of that information is changing and found in better places with more precise guides, and some of it is beyond the scope of what the wiki should explain. Sections 1, 2, 4, 5, 10, and 12 can be removed, they provide nothing useful. There probably only needs to be four sections, Introduction (to provide information to understand terms when referred to later, also FAQs and other relevant preparatory information), Configuration (obviously the configuration file structure), ACPI Patching (DSDT, SSDTs, sleep, SpeedStep, etc, but only pertaining to what can be done with clover, there's no need to explain using/writing/compiling ASL or the sleep entry from zetam.org for instance as it provides nothing useful), and Design (theme based information, there is so much more than is there). It's up to you, PM me your sf username and I'll set it up for you.

[apianti]

@arsradu,

 

Great job, you're moving really fast. One note on the pages, you need to switch your use of = and - for the headers as the top page title is small and the section titles are large, = is for large, - is for small. I also left a note for you on the Home page, there is no need for an extra page for the Contents, it can just be placed on the bottom of the home page. If you need clarification write a comment on a page and we'll discuss it.

 

EDIT: Oh, I see it's actually the formatting of the markdown... You can't put a large header before the table of contents tag?? WTF!?

 

EDIT2:  Before you get too far down the rabbit hole, I know you'll have to go back over some of this to add stuff and remove incorrect stuff and what-not. But, can you make the style look more like this: https://sourceforge.net/p/cloverefiboot/wiki/Boot/?

Edited April 7, 2019 by apianti

[arsradu]

22 minutes ago, apianti said:

@arsradu,

 

Great job, you're moving really fast. One note on the pages, you need to switch your use of = and - for the headers as the top page title is small and the section titles are large, = is for large, - is for small. I also left a note for you on the Home page, there is no need for an extra page for the Contents, it can just be placed on the bottom of the home page. If you need clarification write a comment on a page and we'll discuss it.

 

EDIT: Oh, I see it's actually the formatting of the markdown... You can't put a large header before the table of contents tag?? WTF!?

 

 Glad you like it. I was just about to drop you a message to tell you I just finished moving everything in the Configuration section (including subpages). I didn't get to update anything yet. But we need to establish which exact sections we're gonna keep and which ones are gonna be left there.

 

We can discuss any formatting suggestions you might have. If you think it's not ok the way it is right now. Or if you think we could do it better. So far, I'm pretty happy with the initial result. I hope you are too. My head spins, my back hurts. I need to take a break. :)) But I'll come back soon to continue with the other sections.

 

Just let me know which ones should we keep and which ones should we not.

 

EDIT: I see you started editing the Table of Content text size. I was about to ask for your opinion about it.  I guess now I know it.

Anyway, these are minor changes. Important thing is to have the main content in place. After that, we can tweak it to make it look just right.  

Edited April 7, 2019 by arsradu

[apianti]

Yeah, I like it, looks good, just two things, switch the dividers to be after the entire key section instead of directly after the key, and the table of contents size. I made a mistake and made the table of contents part of the table of contents, lol. You can see that I just changed ** Table of Contents ** to <h1>Table of Contents</h1> and moved the dividers below the section so they are separated equally.

[arsradu]

9 minutes ago, apianti said:

Yeah, I like it, looks good, just two things, switch the dividers to be after the entire key section instead of directly after the key, and the table of contents size. I made a mistake and made the table of contents part of the table of contents, lol. You can see that I just changed ** Table of Contents ** to <h1>Table of Contents</h1> and moved the dividers below the section so they are separated equally.

 

Yeah, I saw what you did there.   Made some changes to ACPI and CPU sections, as well, following your changes.  So we can have more uniformity. I'll do the same to the rest of the pages, as well.

 

It does look better this way, I agree.

 

EDIT: yeah, looks like I've made the same mistake as you, including table of contents under the table of contents. :))) Anyway, it's fixed now.

Edited April 7, 2019 by arsradu

[obus]

On 1/27/2019 at 9:36 PM, Sherlocks said:

  On 1/27/2019 at 8:07 PM,  yapan4 said: 

Long story here 
https://www.insanelymac.com/forum/topic/333229-help-installing-highsierra-on-xeon-w-2175-and-asus-ws-c422-mobo/ 
https://www.insanelymac.com/forum/topic/335193-help-installing-mojave-on-xeon-w-2175-and-asus-ws-c422-mobo/
 
macOS support Xeon W-21xx series CPU, he is native to her

upload your clover preboot or booted log.

Hi @Sherlocks

 

Any new thoughts about this???

 

(Even on hackintosh build:s with original iMac Pro CPU:s Xeon W 2140b and ASUS C422 motherboard needs the kernel patch and fakeCPUID to boot.) 

 

 

 

 

 

 

preboot.log

Edited April 9, 2019 by obus

[matgeo]

Can someone explain to me what clover's SSDT drop tables option is about?
I read the original guide but i didn't understand it.

1) Is there any benefit from droping tables?
2) If yes , how can we know which table to drop?

Thanks in advance.

[apianti]

7 hours ago, obus said:

Hi @Sherlocks

 

Any new thoughts about this???

 

(Even on hackintosh build:s with original iMac Pro CPU:s Xeon W 2140b and ASUS C422 motherboard needs the kernel patch and fakeCPUID to boot.) 

 

Your CPU has an ID of 0x050654, where apparently the CPUs in iMacPros has the ID of 0x0506E4... You need the fake id patch because the xeons that are in iMacPros are apparently specially made and have a different identifier.

 

5 hours ago, matgeo said:

Can someone explain to me what clover's SSDT drop tables option is about?
I read the original guide but i didn't understand it.

1) Is there any benefit from droping tables?
2) If yes , how can we know which table to drop?

Thanks in advance.

 

Dropping tables is to prevent ACPI code from being used in macOS. Some tables cause kernel panics or hangs, where others just have bugs or wrong names and need to be fixed. The first ones you need to drop, the second you can either drop and reinjected patched, or patch on the fly. You need to do some research on ACPI tables and then you will find out which is doing what and which you need original, which you need patched, and which you need dropped.

Edited April 9, 2019 by apianti

[obus]

3 hours ago, apianti said:

 

Your CPU has an ID of 0x050654, where apparently the CPUs in iMacPros has the ID of 0x0506E4... You need the fake id patch because the xeons that are in iMacPros are apparently specially made and have a different identifier.

Thank's for your answer @apianti but I still don't understand.

The CPU id for the original Xenon W 2140b Mac version is  ID: 54 06 05 00 FF FB EB BF or 0x050654 according to a Darwin dump I have from an original iMac Pro1.1 and my 2175 have exactly the same id??  is there other identifier than CPU id?

Booting works for my rig with Skylake X 0x0506E4, Skylake H 0x0506E3 and even with Broadwell H id 0x040670  as long as i have the kernel patch but it's impossible to boot with original Mac id 0x050654 or 0x050652. 

Does this mean that we are stuck with FakeCPUID and kernel patch or is this "problem" possible to solve?

 

Could you please try to give me some further information/explanation.

 

 

Edited April 9, 2019 by obus

[apianti]

1 hour ago, obus said:

Thank's for your answer @apianti but I still don't understand.

The CPU id for the original Xenon W 2140b Mac version is  ID: 54 06 05 00 FF FB EB BF or 0x050654 according to a Darwin dump I have from an original iMac Pro1.1 and my 2175 have exactly the same id??  is there other identifier than CPU id?

Booting works for my rig with Skylake X 0x0506E4, Skylake H 0x0506E3 and even with Broadwell H id 0x040670  as long as i have the kernel patch but it's impossible to boot with original Mac id 0x050654 or 0x050652. 

Does this mean that we are stuck with FakeCPUID and kernel patch or is this "problem" possible to solve?

 

Could you please try to give me some further information/explanation.

 

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?

[matgeo]

11 hours ago, apianti said:

 

Dropping tables is to prevent ACPI code from being used in macOS. Some tables cause kernel panics or hangs, where others just have bugs or wrong names and need to be fixed. The first ones you need to drop, the second you can either drop and reinjected patched, or patch on the fly. You need to do some research on ACPI tables and then you will find out which is doing what and which you need original, which you need patched, and which you need dropped.

Thank you for your answer.

Is there any guide for acpi tables to read ?

 

For example , my origin folder has the attached files. How should i know if any of these causing troubles?

[apianti]

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

Edited April 10, 2019 by apianti

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