Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

kushwavez
kushwavez
Posted
Posted
On 3/3/2021 at 7:13 PM, Slice said:

First one 


            <key>RenameDevices</key>
            <dict>
                <key>_SB.PCI0.RP09._PS0</key>
                <string>XPS0</string>
            </dict>

Same for others but look your DSDT for exact names/pathes.

Count and Skip are not correct because we must rename all occurence of the name.

Long path in Clover guaranties that rename will be only where needed.

Thanks! that did the trick!

My eGPU over Thunderbolt 3 is working now finally :) 

 

I still need to tweak it tho, now the eGPU only showing up as an internal PCIe device, and it says Thunderbolt 3 driver not found.

This isn't a big problem, but because of that I can't select "Prefer eGPU" option on apps and I have to connect a monitor to the card for apps to utilise the card. 

  • Like 2
Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted
On 2/28/2021 at 8:37 AM, Slice said:

Install OpenRuntime.efi.

 

@Jief_Machak

See. For legacy boot we lived without AptioMemoryFix and all was good.

Then we switch to OpenRuntime that does almost same functions switched on-off by Quirks.

Then we switch to Clover+OC and now legacy boot can't works without OpenRuntime. Red Screen panic. Why?

The problem seems related to ConsoleGop?

Can we reproduce this in QEMU ? 

Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted
1 hour ago, Slice said:

We celebrate 10th anniversary of Clover project!

Quite an achievement despite the many Big Sur obstacles along the way. A project to be proud of, well done to all the Devs who made it possible. Clover is still alive!!!!!!! :thumbsup_anim:

  • Like 4
Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted

I can see you replaced a memset by ZeroMem. That means there is a bug in memset, right ? So should we fix that bug instead ?

 

I also don't understand why you test if self.getCloverDirFullPath() is empty because it cannot be. Else, you'll get a panic at Self object initialization "if ( m_CloverDirFullPath.isEmpty() ) panic("m_CloverDirFullPath.isEmpty()");"

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
8 hours ago, Jief_Machak said:

I can see you replaced a memset by ZeroMem. That means there is a bug in memset, right ? So should we fix that bug instead ?

 

I also don't understand why you test if self.getCloverDirFullPath() is empty because it cannot be. Else, you'll get a panic at Self object initialization "if ( m_CloverDirFullPath.isEmpty() ) panic("m_CloverDirFullPath.isEmpty()");"

The key change is I move pointer calculation from args to local variable. 

ZeroMem was not the key. It had no influence.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

This line 

FPath = XFP.wc_str();

was the key feature that prevented the panics. 

So I must calculate the pointer before use it as arg. 

Status = OcStorageInitFromFs(&mOpenCoreStorage, FileSystem, FPath, NULL);

It means that when I do

Status = OcStorageInitFromFs(&mOpenCoreStorage, FileSystem, XFP.wc_str(), NULL);

then it will crash.

When the driver OpenRuntime.efi is installed there is no crash at this place.

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

Hello @Slice and happy birthday for Clover and its 10 years! Amazing... when I used Chameleon I thought Clover was complex, but all these years we got to love it!

 

Please, I am trying to see if the configuration value for ROM that is set to be UseMacAddr0 works as expected.

I am trying to find where and how this value (in RtVariables) is injected but I cannot find a trace in IORegistry.

If we use the value UseMacAddr0 can you kindly point us to where we are supposed to confirm this RtVariables value? Thank you.

(trying to validate all steps for a working iMessage service that fails, for now)

 

Edited by MacKonsti
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
58 minutes ago, MacKonsti said:

Hello @Slice and happy birthday for Clover and its 10 years! Amazing... when I used Chameleon I thought Clover was complex, but all these years we got to love it!

 

Please, I am trying to see if the configuration value for ROM that is set to be UseMacAddr0 works as expected.

I am trying to find where and how this value (in RtVariables) is injected but I cannot find a trace in IORegistry.

If we use the value UseMacAddr0 can you kindly point us to where we are supposed to confirm this RtVariables value? Thank you.

(trying to validate all steps for a working iMessage service that fails, for now)

 

Hello, MacKonsti

You may type in terminal the command

nvram -x 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM >rom.plist

and got the result like 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM</key>
	<data>
	HBsNZltx
	</data>
</dict>
</plist>

Then you know what to do.

 

  • Like 1
Link to comment
Share on other sites
MacKonsti
MacKonsti
Posted
Posted (edited)

Hi @Slice thank you for your tip. I was afraid something is wrong... My result on Catalina is: 

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM</key>
        <data>
        ////////
        </data>
</dict>
</plist>

This is not normal :( This translates to ff ff ff ff ff ff that is not my MAC address obviously.

In Hackintool and Peripherals tab, I do see my Intel I219-V connection be marked as en0 so not sure what's going on.

Could it be something wrong with Clover r5131?

My related Clover setting is (I have masked my MLB): 

	<key>RtVariables</key>
	<dict>
		<key>BooterConfig</key>
		<string>0x00</string>
		<key>CsrActiveConfig</key>
		<string>0x00</string>
		<key>MLB</key>
		<string>BOARDSERIALNEEDED</string>
		<key>ROM</key>
		<string>UseMacAddr0</string>
	</dict>

CSR and Booter values have no impact in this, yes?

In Hackintool > Boot > Clover log I do not see any "ROM" or other mention.

Can I please ask you to have a look at the Clover code or help me debug this on my system to help you?

Thank you.

 

Edited by MacKonsti
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@MacKonsti

It means Clover can't catch MAC-address of your LAN. Clover's preboot.log (by F2) can clarify this.

Nothing wrong with Clover 5131 because the same will be with any other Clover version. 

  • Like 1
Link to comment
Share on other sites
MacKonsti
MacKonsti
Posted
Posted (edited)
44 minutes ago, Slice said:

@MacKonsti

It means Clover can't catch MAC-address of your LAN. Clover's preboot.log (by F2) can clarify this.

Oh, that's interesting. Why on earth wouldn't Clover detect my LAN properly I wonder?

Here is my preboot.log file @Slice I cannot find a reference for ROM except for LAN:  - LAN: 0 Vendor=Intel

and:

0:716  0:000  === [ GetMacAddress ] ===========================
0:716  0:000   get legacy LAN MAC, 1 card found
0:716  0:000  Legacy MAC address of LAN #0= FF:FF:FF:FF:FF:FF:
 

Does this depend on some device name in ACPI? Some BIOS/firmware feature that Intel NUC doesn't support? Why "legacy" any idea?

Does this mean I need to declare my MAC address to ROM by hand then? :-(

Do you see anything else "worrying" in my preboot.log perhaps?

 

P.S. Why is official r5131 Clover reporting "Build id: 20210221183006-949da63-5131-dirty" ? Dirty? :D Спасибо

preboot.log

Edited by MacKonsti
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Yes, I see.

Your LAN card is Intel and Clover has algo to catch its MAC-address by two ways.

First one using UEFI BIOS. But in your case UEFI BIOS does not supply services for reading MAC.

Second one is legacy way developed for very old cards. It seems for your case the procedure is no more working.

So write into config digits you know

<key>ROM</key>

<data>112233445566</data>

It may be <string> as well.

  • Like 1
Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted (edited)
On 3/6/2021 at 10:22 PM, Slice said:

The key change is I move pointer calculation from args to local variable.

I cannot yet understand how come using a local variable would give a different result ??!

if that is true, we have a serious compiler problem.

in top of that, this var is probably optimized out.

We definitely have have to investigate this because if it’s true, it means the language is broken.

If I revert that commit, can I reproduce the problem in Qemu ?

Edited by Jief_Machak
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
3 hours ago, Jief_Machak said:

I cannot yet understand how come using a local variable would give a different result ??!

if that is true, we have a serious compiler problem.

in top of that, this var is probably optimized out.

We definitely have have to investigate this because if it’s true, it means the language is broken.

If I revert that commit, can I reproduce the problem in Qemu ?

I placed "test 1\n", "test 2\n"... to catch the problem in QEMU. Yes, this is strictly reproducible. As well as I am not a first person encountered this crash. The discussion was on russian forum https://www.applelife.ru/threads/clover.42089/page-1352#post-928163

It looks like a compiler bug. :unsure:

If you want to reproduce then take into acoount:

1. It is legacy boot. Version of boot6 file has no matter. Works similarly.

2. Boot by timeout. There is a problem to do this in QEMU so I made special Clover always booted by timeout. In the procedure FindStartupDiskVolume(...) I place return 3; where 3 in the my third entry to start.

3. The clover compiled by gcc-10.3, not sure about Clang compilation.

4. With OpenRuntime there is no crash. There is a crash without it.

5. First wrong commit is 5de09acb3. Fixed in 45801ef.

 

Last commit 235f13a3 cures another crash. This is also legacy boot encountered by jsl2000 at this thread. But it also looks like the same compiler bug.

The crash is here 

// MsgLog("test 1\n");
     Status = GraphicsOutput->SetMode(GraphicsOutput, ModeNumber);
 //  MsgLog("test 2\n");

The procedure SetMode is in boot6 file which works 10 years at thousand computers. So? Some virtualisation problem... This bug I can't reproduce in Qemu. I catch the bug is probably related to debugging procedures. See the commit.

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

Any idea why RenameDevices can't rename _GPE.NTFY to XTFY? Am I missing something? 

I put _GPE.NTFY to XTFY into RenameDevices and rebooted.

Looked at the log: 

[...]
0:712  0:000  NTFY:_GPE:->will be renamed to XTFY
[...]
4:851  0:003  Name: NTFY, Bridge: _GPE, Replace: XTFY
4:852  0:001    0 replacements
[...]

It is not renamed, but I don't know why. 

 

This should be renamed:

882666615_Kpernyfot2021-03-10-14_00_50.thumb.png.7a52576a868db050e8fa2b4dae9e6869.png

DSDT.dsl.zip

Edited by kushwavez
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted (edited)
16 minutes ago, kushwavez said:

Any idea why RenameDevices can't rename _GPE.NTFY to XTFY? Am I missing something? 

I put _GPE.NTFY to XTFY into RenameDevices and rebooted.

Looked at the log: 



[...]
0:712  0:000  NTFY:_GPE:->will be renamed to XTFY
[...]
4:851  0:003  Name: NTFY, Bridge: _GPE, Replace: XTFY
4:852  0:001    0 replacements
[...]

It is not renamed, but I don't know why. 

 

 

Only my modest opinion, because _GPE is a Scope, not a device. And NTFY is a method. I suppose you're talking about RenameDevices in config.plist.
Unless I'm mistaken

 

Edited by Matgen84
  • Like 1
Link to comment
Share on other sites
kushwavez
kushwavez
Posted
Posted (edited)

But for example another rename is working. _INI is a method too.

_SB.PCI0.RP09._INI -> XINI

  • _SB.PCI0 (Scope)
  • RP09 (Device)
  • _INI (Method) 
[...]
4:250  0:000  Name: _INI, Bridge: RP09, Replace: XINI
4:253  0:003    1 replacements
[...]

1053987695_Kpernyfot2021-03-10-14_43_46.thumb.png.53ab0693b19aee4fed57c7e8b5253209.png

 

So I suppose _GPE.NTFY -> XTFY should work too, but it doesn't.

Edited by kushwavez
  • Sad 2
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...