Clover General discussion

[MacKonsti]

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 March 7, 2021 by MacKonsti

[Slice]

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.

 

[MacKonsti]

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 March 7, 2021 by MacKonsti

[Slice]

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

[MacKonsti]

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?  Спасибо

preboot.log

Edited March 7, 2021 by MacKonsti

[Slice]

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.

[Jief_Machak]

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 March 8, 2021 by Jief_Machak

[Slice]

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. 

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.

[kushwavez]

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:

DSDT.dsl.zip

Edited March 10, 2021 by kushwavez

[Matgen84]

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 March 10, 2021 by Matgen84

[kushwavez]

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

 

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

Edited March 10, 2021 by kushwavez

[Matgen84]

38 minutes ago, kushwavez said:

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

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

 

I suppose  that Bridge must be a device: Scope/Device/Method works for INI --> XINI. Maybe this is the reason why RenameDevice don't work for _GPE

 

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

 

[kushwavez]

Hmm.. yes that must be it. I tried with _SB.PCI0.RP09._PS3 too, but that doesn't work either.

• _SB.PCI0.RP09 (Scope)
• _PS3 (Method)

0:742  0:000  _PS3:RP09:PCI0:_SB_:->will be renamed to XPS3
[...]
7:700  0:001  Name: _PS3, Bridge: RP09, Replace: XPS3
7:705  0:003    0 replacements

But then any idea how can I rename them? 

I need to patch ONLY one match, so I can't use hex rename patch because that will rename all matches.

 

Any idea @Slice?

_GPE.NTFY is the reason why my TB3 SSDT can't load up.

 

[Slice]

4 hours ago, kushwavez said:

Hmm.. yes that must be it. I tried with _SB.PCI0.RP09._PS3 too, but that doesn't work either.

• _SB.PCI0.RP09 (Scope)
• _PS3 (Method)

0:742  0:000  _PS3:RP09:PCI0:_SB_:->will be renamed to XPS3
[...]
7:700  0:001  Name: _PS3, Bridge: RP09, Replace: XPS3
7:705  0:003    0 replacements

But then any idea how can I rename them? 

I need to patch ONLY one match, so I can't use hex rename patch because that will rename all matches.

 

Any idea @Slice?

_GPE.NTFY is the reason why my TB3 SSDT can't load up.

 

What is your Clover version? It was repaired recently https://github.com/CloverHackyColor/CloverBootloader/commit/e1a49a85b9f644e718f8d042444ea52a2e37f570

But may be you have a new bug.

I will check a little later.

[kushwavez]

@Slice Latest, Clover v5131

[Slice]

Sorry, no. The procedure is RenameDevices. It can't rename methods.

So rename _SB.PCI0.RP09._INI -> XINI shouldn't work.

Ok, I will look if it is possible to extend functionality.

The problem will be with the method call. You probably want the method will never called? You probably can to Find/Replace this call.

[kushwavez]

4 hours ago, Slice said:

Sorry, no. The procedure is RenameDevices. It can't rename methods.

So rename _SB.PCI0.RP09._INI -> XINI shouldn't work.

unfortunate. But it's working for now, even if because a bug.  

4 hours ago, Slice said:

Ok, I will look if it is possible to extend functionality.

That would be neat, thanks.

 

4 hours ago, Slice said:

The problem will be with the method call. You probably want the method will never called? You probably can to Find/Replace this call.

Yes, I want to replace NTFY to XTFY inside _GPE scope. The problem is, if I simply use find/replace, that is replacing all matches, not just inside the _GPE Scope. 

Hmm.. well, I'll locate that exact NTFY with HexFiend in the .aml, see what before or after and add that to find/replace. That could work.

[kushwavez]

So yes, HexFiend worked, but I found some (cosmetic I guess) issue.

 

If I rename something that is not in DSDT, but in SSDT, log says "bin not found / already patched" even if it's being patched.

For example _UPC to XUPC (_UPC is ONLY in SSDT's, not in DSDT): I looked up my SSDT-4.aml with HexFiend to find the pattern, found:

• _UPC? (5F555043 08A4)
• 6_UPC (365F5550 43)
• %_UPC (255F5550 43)

If I look at the log, it says:

10:786  0:000   - [_UPC? to XUPC]: pattern 5F555043, bin not found / already patched!
10:786  0:000   - [6_UPC to XUPC]: pattern 365F5550, bin not found / already patched!
10:786  0:000   - [%_UPC to XUPC]: pattern 255F5550, bin not found / already patched!

In this case this msg is at the first attempt for patch, so it isn't "already patched"

 

But they're patched, looking at my SSDT-4, so that's why I say it's cosmetic issue:

 

If it's in my DSDT, for example _GPE.NTFY (CGNTFY: 43474E54 4659) to XTFY it says:

10:787  0:000   - [GPE_NTFY to XTFY]: pattern 43474E54, patched at: [ (16B81) ]

So, in DSDT it's reporting correctly.

 

I think I'm gonna report these on GitHub, just for better tracking.

 

But at least finally my Thunderbolt Hot-Plug is working fine!

 

EDIT: reported them on Github for better tracking:

#379 Binpatch: "bin not found / already patched" if the pattern is in SSDT, but it's being patched even so

#378 [Enhancement] Use RenameDevices for Methods too

 

Edited March 11, 2021 by kushwavez

[MacKonsti]

Hi @Jief_Machak hope you are well. Can I kindly ask you to update your CloverValidator excellent tool to change the expected tags for <key>RenameDevices</key> ?

I get now  Error: Expecting tag 'dict' at line 244.

According to @Slice post in the Clover updates:

New Clover proposes to rewrite this as:
            <key>RenameDevices</key>
            <array>
            	<dict>
                	<key>_SB.PCI0.RP05.PXSX</key>
                	<string>UPSB</string>
            	</dict>
             	<dict>
                	<key>_SB.PCI0.RP05.UPSB.DSB1.NHI0</key>
                	<string>UPS0</string>
                </dict>
           		<dict>
                	<key>_SB.PCI0.RP03.PXSX</key>
                	<string>BRG3</string>
            	</dict>
            </array>
In this case the order will be guaranteed.

Thank you!
(it's also a good opportunity to put a version in your too, too! Your safe bet is the date like iasl tool )

[Slice]

@kushwavez

Thanks for your reports. When I will have a time I will study  what I can to do.

 

@MacKonsti

It is because of format of RenameDevices changed while CloverValidator no.

[MacKonsti]

Hi @Slice yes I am aware that now you allow <arrays> and afterwards inside <dict> entries, so I was hoping @Jief_Machak would be able to update his CloverValidator tool for Clover r5131+ for us
Many thanks to both.

P.S. Perhaps it would be a good idea to package CloverValidator with the newer Clover releases? It's extremely useful...

 

Edited March 13, 2021 by MacKonsti

[Jief_Machak]

On 3/8/2021 at 10:43 PM, Slice said:

2. Boot by timeout.

@Slice : do you mean that boot with pressing a key always works, and boot with timeout crash (before commit 45801ef2da07a163d27e513559fc5125b0546d67 "correct use of virtual pointer" ) ?

[Jief_Machak]

@Slice I tried to boot with timeout but cannot reproduce yet.

How did you compile gcc 10.3 ? Could you send me the zip of that gcc folder, so I can test with the exact same compiler you used ?

Could you send me the qemu img ? And the launch command ? Maybe there is something in my config that make it work...

 

[Slice]

11 hours ago, Jief_Machak said:

@Slice : do you mean that boot with pressing a key always works, and boot with timeout crash (before commit 45801ef2da07a163d27e513559fc5125b0546d67 "correct use of virtual pointer" ) ?

Yes, there are user's reports about this. I just reproduce this with qemu.

[Jief_Machak]

1 minute ago, Slice said:

Yes, there are user's reports about this. I just reproduce this with qemu.

I did too, but no problem.

 

If it's just a GCC 10.3 bug, I think we should just ban that version that brings nothing more to Clover, instead of doing strange fix that just clutters the code. That's why I'd like to test and reproduce.

 

Could you send me your compiler ?