Clover General discussion

[Slice]

7 hours ago, Jief_Machak said:

 

Could I simplify and drop that support ? (and re introduce something if a user is asking, one day).

Yes, simply drop. I never understood the idea of this unite.

 

There are bad messages about Xcode12 compilation again. https://www.applelife.ru/threads/clover.42089/page-1378#post-936652

 

[Jief_Machak]

From what I see in the russian thread, Clover seems to work but macos kernel panic...

Hard to debug, but what I can do is going over ALL the objects in Clover and add a default ctor. I'll do that tmo.

 

Also, here is the very first compilation of Clover using the new XML parser : CloverX64-2021-04-21-13-18-28-a1a27d2-dirty-jief.zip

As usual, there should be no difference for you (and that's exactly what I want to test). We already know that the new parser gives the same result... but who knows.

 

As usual, be sure to have a plan B in case this one doesn't boot.

 

PS : please don't ask why I spend so much time to do thing that make no difference for the user...

[kushwavez]

Why are you spending so much time to do thing that make no difference for the user? (jk)

[Jief_Machak]

I have yet to answer that question to myself.

[Matgen84]

Hi @Jief_Machak

The compilation of Clover using new XML Parser 2021-04-21-13-18-28-a1a27d2-dirty-jief boot fine (Z390 config Big Sur 11.3 RC)  I test the CLOVERX64 posted on AppleLife: boot fine too, the same config.

But I notice some problems with new XML Parser: in Clover GUI Options/SMBIOS, there are some difference between Clover and my Imac19,1 SMBIOS config.plist: BiosVersion, BiosRelease date, EFI version
 

No Problem with CloverX64TestNewParser version 13.

EDIT: Why this in debug.log : '\EFI\CLOVER__Test/smbios.plist' not loaded. Efi error Not Found  don't exist before

 

Spoiler

 

2021-4-21_8-10_CloverX64-2021-04-21-13-18-28-a1a27d2-dirty-jief.efi.log 2021-4-21_11-11_CLOVERX64_AppleLife.efi.log

Résultat CLOVERX64TestNewParser.txt

Edited April 21, 2021 by Matgen84

[JorgeMax]

Here also giving error in the SMBIOS information

 

Spoiler

SMBIOS generated by the clover:

 

SMBIOS generated by information from my "config.plist":

 

 

 

Edited April 21, 2021 by JorgeMax

[Jief_Machak]

Yes yes, found it, thanks.

CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip

Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist.

The other are not fixed yet.

[JorgeMax]

20 minutes ago, Jief_Machak said:

Yes yes, found it, thanks.

CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip 824.42 kB · 1 download

Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist.

The other are not fixed yet.

 

I think it's the same way

[Matgen84]

40 minutes ago, Jief_Machak said:

Yes yes, found it, thanks.

CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip 824.42 kB · 1 download

Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist.

The other are not fixed yet.

Hi @Jief_Machak I don't try this efi file. But in previous one, Clover search smbios.plist instead of config.plist. So this line in debug.log: '\EFI\CLOVER__Test/smbios.plist' not loaded. Efi error Not Found 

Edited April 21, 2021 by Matgen84

[Matgen84]

48 minutes ago, Jief_Machak said:

Yes yes, found it, thanks.

CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip 824.42 kB · 1 download

Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist.

The other are not fixed yet.

Hi again @Jief_Machak

ROM version fixed  in Clover GUI only. Not in debug.log BIOSVersion=EFIversion ???

 

2021-4-21_11-39_CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.efi.log

[Jief_Machak]

18 minutes ago, Matgen84 said:

BIOSVersion=EFIversion

When you setup a BiosVersion AND an EfiVersion in your config or smbios plist, EfiVersion will be sent to smbios. It always has been like this. I just recently make the message.

I'll have a look later...

Thanks for the tests.

[Slice]

5 hours ago, Jief_Machak said:

From what I see in the russian thread, Clover seems to work but macos kernel panic...

Hard to debug, but what I can do is going over ALL the objects in Clover and add a default ctor. I'll do that tmo.

 

Also, here is the very first compilation of Clover using the new XML parser : CloverX64-2021-04-21-13-18-28-a1a27d2-dirty-jief.zip

As usual, there should be no difference for you (and that's exactly what I want to test). We already know that the new parser gives the same result... but who knows.

 

As usual, be sure to have a plan B in case this one doesn't boot.

 

PS : please don't ask why I spend so much time to do thing that make no difference for the user...

It sends debug to SerialPort. It is good for QEMU but not for real hardware.

[Jief_Machak]

18 minutes ago, Slice said:

It sends debug to SerialPort. It is good for QEMU but not for real hardware.

Yes, all my own debug build do that. Since always. Normal release build won't.

It's just a way to ask for some tests before I commit things that doesn't work. So I send my own build.

[Slice]

3 hours ago, Jief_Machak said:

Yes yes, found it, thanks.

CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip 824.42 kB · 4 downloads

Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist.

The other are not fixed yet.

Clover started up to GUI but not booted system.

Or I wait too little? You have no timings in the log

 

2021-4-21_15-59_CLOVERX64.EFI.log.zip config.plist.zip

[Slice]

Next command should be SetNvramVariable

129:157  0:099  CurrentMode: Width=1920 Height=1080
129:259  0:102  SetNvramVariable (FirmwareFeaturesMask, guid, 0x6, 4):
129:391  0:131   -> writing new (Success)

 

[Jief_Machak]

6 minutes ago, Slice said:

Next command should be SetNvramVariable

129:157  0:099  CurrentMode: Width=1920 Height=1080
129:259  0:102  SetNvramVariable (FirmwareFeaturesMask, guid, 0x6, 4):
129:391  0:131   -> writing new (Success)

 

Thanks for the tests.

I'll have a look tmo.

Not sure what you mean by "Next command should be SetNvramVariable". You mean after "-> writing new (Success)" there should be another "SetNvramVariable" ?

 

Could send me a log of a successful boot with the last commit ? So I'll compare.
FYI, I'll remove the timing in logs from my builds so I can compare logs with a software easier : I don't have timing reported different at each and every line. When someone send me a normal log, the first I do is "sed -i "" 's/..............//' {file}".

[Slice]

1 hour ago, Jief_Machak said:

Thanks for the tests.

I'll have a look tmo.

Not sure what you mean by "Next command should be SetNvramVariable". You mean after "-> writing new (Success)" there should be another "SetNvramVariable" ?

 

Could send me a log of a successful boot with the last commit ? So I'll compare.
FYI, I'll remove the timing in logs from my builds so I can compare logs with a software easier : I don't have timing reported different at each and every line. When someone send me a normal log, the first I do is "sed -i "" 's/..............//' {file}".

Log, I sent you finished at line

129:157  0:099  CurrentMode: Width=1920 Height=1080

In other log i see next line

129:259  0:102  SetNvramVariable (FirmwareFeaturesMask, guid, 0x6, 4):

So I proposed your Clover stops at this action.

[Slice]

I compiled latest Clover by GCC53 and made a log just now.

 

boot-log.txt

[Jief_Machak]

1 hour ago, Slice said:

I compiled latest Clover by GCC53 and made a log just now.

 

boot-log.txt 53.76 kB · 0 downloads

Yes, I can see the difference. Probably a crash...
I'll look into later.

Thanks.

[Jief_Machak]

@Matgen84 Could you test (BiosVersion, ReleaseData) with this version ?

@Slice No idea why it would stop between  "CurrentMode: Width=1920 Height=1080" and "SetNvramVariable (FirmwareFeaturesMask, guid, 0x6, 4):" I've added few logs. Could you re-test when you can ?

Thanks.
 CloverX64-2021-04-22-12-45-56-a1a27d2-dirty-jief.zip

[Matgen84]

1 hour ago, Jief_Machak said:

@Matgen84 Could you test (BiosVersion, ReleaseData) with this version ?

@Slice No idea why it would stop between  "CurrentMode: Width=1920 Height=1080" and "SetNvramVariable (FirmwareFeaturesMask, guid, 0x6, 4):" I've added few logs. Could you re-test when you can ?

Thanks.
 CloverX64-2021-04-22-12-45-56-a1a27d2-dirty-jief.zip

@Jief_Machak The new Parser works fine  (Z390 Big Sur 11.4 Beta 1). Don't verify macOS System Info

Little details: UpdateSmbiosString SerialNr= twice en debug.log

 

Spoiler

 

2021-4-22_10-5_CloverX64-2021-04-22-12-45-56-a1a27d2-dirty-jief.efi.log

[Jief_Machak]

Thanks for the test.

 

 

1 minute ago, Matgen84 said:

Little details: UpdateSmbiosString SerialNr= twice en debug.log

 

void PatchTableType1() : UpdateSmbiosString SerialNr=blabla
void PatchTableType3() : UpdateSmbiosString SerialNr=blabla

Yes, the serial number is sent into 2 differents smbios tables. That's ok.

 

[Jief_Machak]

A year ago this (commit 01f33f7552be78e9574adbe2b953e4b01e9d9b8c)

      if ((Volume->BootType != BOOTING_BY_PBR) &&
          (Volume->BootType != BOOTING_BY_MBR) &&
          (Volume->BootType != BOOTING_BY_CD)) {

became 

      if (/*(Volume->BootType != BOOTING_BY_PBR) && */
          (Volume->BootType >= BOOTING_BY_MBR) /*&&
          (Volume->BootType != BOOTING_BY_CD)*/ ) {

The result is custom legacy are ignored because they have BootType >= MBR. Should it be < BOOTING_BY_MBR instead ?

Is it a typo ?

 

 

[Jief_Machak]

13 minutes ago, MifJpn said:

I was able to boot on Big Sur 11.3 and Catalina 10.15.7.

2021-4-22_13-57_CloverX64-2021-04-22-12-45-56-a1a27d2-dirty-jief.efi.log 46.61 kB · 0 downloads 2021-4-22_14-3_CloverX64-2021-04-22-12-45-56-a1a27d2-dirty-jief.efi.log 46.24 kB · 0 downloads

Thank you。

 

Thanks for the test.

[Slice]

5 hours ago, Jief_Machak said:

A year ago this (commit 01f33f7552be78e9574adbe2b953e4b01e9d9b8c)

      if ((Volume->BootType != BOOTING_BY_PBR) &&
          (Volume->BootType != BOOTING_BY_MBR) &&
          (Volume->BootType != BOOTING_BY_CD)) {

became 

      if (/*(Volume->BootType != BOOTING_BY_PBR) && */
          (Volume->BootType >= BOOTING_BY_MBR) /*&&
          (Volume->BootType != BOOTING_BY_CD)*/ ) {

The result is custom legacy are ignored because they have BootType >= MBR. Should it be < BOOTING_BY_MBR instead ?

Is it a typo ?

 

 

Yes, must be <