Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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

  • Like 1
Link to comment
Share on other sites

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 :thumbsup_anim: (Z390 Big Sur 11.4 Beta 1). Don't verify macOS System Info

Little details: UpdateSmbiosString SerialNr= twice en debug.log

 

Spoiler

screenshot0.thumb.png.8bd16c2db3d17d59b6d513b37be21ee9.png

 

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

  • Like 1
Link to comment
Share on other sites

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.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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 ?

 

 

  • Like 1
Link to comment
Share on other sites

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 <

  • Like 1
Link to comment
Share on other sites

9 hours 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

Same stop

 

2021-4-22_19-11_CLOVERX64.EFI.log.zip

Link to comment
Share on other sites

hello team

 

I am always following the good path of Clover and I always testify when time allows me

 

I tested it last night and today the boot that Jief disposes here in an

All In One Asus A4310-BB020T
intel core i3-4160T
intel HD4400 GT1,5 (just the 'apercu' of the photos I can't use because of this GT1,5 but here I have an i5-4590T to put and move to the HD4600 GT2)
8 go RAM
HDD 500 go 7200rpm (maybe change to SSD)

the boot and usage tests work perfect here

I leave my thanks to you for always continuing this fight and putting my favorite bootloader better and better with you only this is possible

I will always be here for the tests even if I don’t answer it doesn’t mean I’ve abandoned the opposite always present

if at a moment there is a lack of tests on a particular machine that I have, just tell me that I will do it

 

good continuation and strength that CLOVER is always in high shape

 

Google translate !

 

Spoiler

134183349_Capturedecran2021-04-22a22_38_13.thumb.png.c2bfa2a203a74723dc66c6dc18c9acb2.png788847496_Capturedecran2021-04-22a22_40_57.thumb.png.8e497d1a7bd467cbc880010bd5de8543.png

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

44 minutes ago, naiclub said:

What happened? Now built at 5129.

ภาพถ่ายหน้าจอ 2564-04-23 เวลา 20.20.29.png

Fixed.

17 minutes ago, MifJpn said:

as information.
In fact, if you edit config.plist with
<true/> is replaced with <true />
<false/> will be replaced with <false />.
In fact, I don't know how much is acceptable as correct XML.
However, OpenCore seems to allow it, but in the case of Clover, the following display appears and it does not work.
IMG20210423222312.thumb.jpg.148cf9e296f906e2cf5a3d75c8972dd4.jpg

To me, PlistEDplus seems to use a dialect.
Therefore, I think that PlistEDplus will not be able to support a lot of XML, so I will tell the author.
I will write it as information.

Sorry.

It is fix at new release1.0.50!!
Thank you.

That's interesting.

Panicking because of a problem in config.plist is a sign a technical bug somewhere. Wrong input must ignored, corrected or whatever, but not cause a panic.

Could you send me this config.plist that causes this bug ?

Link to comment
Share on other sites

@Jief_Machak

I've got problem with cloverbootloader/opencorepkg commit version:
 

iMac-de-Mathieu:cloverbootloader mathieu$ git pull --recurse-submodules origin master
From https://github.com/CloverHackyColor/CloverBootloader
 * branch                master     -> FETCH_HEAD
Fetching submodule OpenCorePkg
Already up to date.
Submodule path 'OpenCorePkg': checked out '444a41b15eee65123be0b47b2f4813c6b11a0520'

In the repo, CloverHackycolor/Cloverbootloader/Opencorepkg ---->   commit   444a41b15eee65123be0b47b2f4813c6b11a0520

In the repo, CloverHackycolor/Opencorepkg ---->  commit    2378f2b5ee97ed31333d49881620af447e2b3095

Do you have a solution !

Link to comment
Share on other sites

16 minutes ago, MifJpn said:

Thank you for picking it up.
This is it.

config.plist 39.01 kB · 2 downloads

If you actually replace ”true /” with ”true/” and ”false /” with ”false/” in CotEditer, it will work.

Thank you.

Sorry, my bad. The problem is with the plist of the theme. Could you send me a zip of the theme, preferably with the problem.

9 minutes ago, Matgen84 said:

@Jief_Machak

I've got problem with cloverbootloader/opencorepkg commit version:
 


iMac-de-Mathieu:cloverbootloader mathieu$ git pull --recurse-submodules origin master
From https://github.com/CloverHackyColor/CloverBootloader
 * branch                master     -> FETCH_HEAD
Fetching submodule OpenCorePkg
Already up to date.
Submodule path 'OpenCorePkg': checked out '444a41b15eee65123be0b47b2f4813c6b11a0520'

In the repo, CloverHackycolor/Cloverbootloader/Opencorepkg ---->   commit   444a41b15eee65123be0b47b2f4813c6b11a0520

In the repo, CloverHackycolor/Opencorepkg ---->  commit    2378f2b5ee97ed31333d49881620af447e2b3095

Do you have a solution !

cd OpencorePkg

git checkout master

git fetch

git pull

cd ..

 

Link to comment
Share on other sites

×
×
  • Create New...