Clover General discussion

[yapan4]

In my case: 

 

after boot

 

Version: Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz

Voltage: 1.6 V

External Clock: 25 MHz

Max Speed: 3601 MHz

Current Speed: 3600 MHz

 

before boot

 

Version: Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz

Voltage: 1.6 V

External Clock: 25 MHz

Max Speed: 3600 MHz

Current Speed: 3600 MHz

 

for before boot used Github release v.5133

Edited April 25, 2021 by yapan4

[Jief_Machak]

10 minutes ago, yapan4 said:

In my case after boot

 

Version: Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz

Voltage: 1.6 V

External Clock: 25 MHz

Max Speed: 3601 MHz

Current Speed: 3600 MHz

Fine, I don't need your clock. I was just explaining what can be ok to be different in dmidecode produced output.

Did you use dmidecode with "normal" Clover and with my version ?

[yapan4]

6 minutes ago, Jief_Machak said:

Did you use dmidecode with "normal" Clover and with my version ?

Yes, for "normal" used release v.5133, for "after boot" - your version.  Upload full dmidecode dump?

Edited April 25, 2021 by yapan4

[Jief_Machak]

2 minutes ago, yapan4 said:

Yes, for "normal" used release v.5133, for "after boot" - your version.  Upload full dmidecode dump?

Great. You can compare it if you have a file diff software. I can also compare them myself. You can send me them here or on private message.

[Jief_Machak]

1 minute ago, yapan4 said:

 

yapan4_dmidecode_dumps.zip 13.44 kB · 0 downloads

Good, exact same (except buildid) !

Thanks for the test.

[Jief_Machak]

New version. Solve a small thing when SmUUID is not defined.

@Slice You'll probably see a difference in Qemu as your config.plist doesn't have a SMBIOS section. The SmUUID was swapped compare to current Clover version.

 

CloverX64-2021-04-26-01-34-12-afa09cc-dirty-jief.zip

[Slice]

4 hours ago, Jief_Machak said:

New version. Solve a small thing when SmUUID is not defined.

@Slice You'll probably see a difference in Qemu as your config.plist doesn't have a SMBIOS section. The SmUUID was swapped compare to current Clover version.

 

CloverX64-2021-04-26-01-34-12-afa09cc-dirty-jief.zip 818.68 kB · 2 downloads

Booting to real hardware #1 in sig.

There are two major differences:

1. MaxSpeed in table 4 can be redefined by config.plist

-    Max Speed: 3300 MHz
+    Max Speed: 2712 MHz

            <key>FrequencyMHz</key>
            <integer>3300</integer>

2. There is no table 132.

DMIdiff.txt.zip

[Matgen84]

14 hours ago, Jief_Machak said:

New version !

CloverX64-2021-04-25-19-03-21-afa09cc-dirty-jief.zip 820.23 kB · 3 downloads

 

@Slice smcRevision is fixed, and some others.

 

@everyone, SMBIOS was a particularly pain ! So if you'd like to help, use dmidecode before and after booting this version and tell me if there is a difference.

Thanks.

@Jief_Machak I use bootloader chooser for test. At boot before Clover GUI, there is a warning message: ask to check with configplistValidator, and to put boolean <true> for InjectKexts instead of usual <string>Yes</string> in Z390 config.plist. Why ?

 

iMac-de-Mathieu:~ mathieu$ /Users/mathieu/Downloads/Outils_Bootloader/Outils\ Clover/Outils\ New\ Clover\ +\ BootloaderChooser/CloverConfigPlistValidator0.7 '/Users/mathieu/Desktop/config.plist' 
Your plist looks so wonderful. Well done!
iMac-de-Mathieu:~ mathieu$ /Users/mathieu/Downloads/Outils_Bootloader/Outils\ Clover/Outils\ New\ Clover\ +\ BootloaderChooser/CloverConfigPlistValidator0.8 '/Users/mathieu/Desktop/config.plist' 
Cannot stat file 'config-nowarning-noerror.plist'

This commit boot fine Big Sur 11.4 Beta 1. SMBIOS is correct in Clover-Options and macOS SystemInfo with the good smcRevision 

One issue remains: can't wake up after sleep (press space bar or mouse not working) 

 

Spoiler

 

Dmidecode_out.txt 2021-4-24_16-20_CloverX64-2021-04-25-19-03-21-afa09cc-dirty-jief.efi.log

Edited April 26, 2021 by Matgen84

[Jief_Machak]

8 hours ago, Slice said:

Booting to real hardware #1 in sig.

There are two major differences:

1. MaxSpeed in table 4 can be redefined by config.plist

-    Max Speed: 3300 MHz
+    Max Speed: 2712 MHz

            <key>FrequencyMHz</key>
            <integer>3300</integer>

2. There is no table 132.

DMIdiff.txt.zip 1.54 kB · 0 downloads

To get table 132 I had to define QPI CloverX64-2021-04-26-15-06-03-afa09cc-dirty-jief.zip, but I have it now.

Max Speed too.

Thanks for the test.

4 hours ago, Matgen84 said:

put boolean <true> for InjectKexts instead of usual <string>Yes</string> in Z390 config.plist. Why ?

I personally think it's best to be more restrictive in technical files. A boolean is supposed to be <true/> or <false/>. Avoiding many ways to say the same thing ( <true/>, <string>yes</string>, <string>true</string>, <integer>1<integer> ) is always easier in the code.

It's still recognize, for historic reason, but I thought the new validation capabilities could help as it can tell exactly where and what to do.

If many voices are against that, I can remove that warning, of course.

[Matgen84]

23 minutes ago, Jief_Machak said:

I personally think it's best to be more restrictive in technical files. A boolean is supposed to be <true/> or <false/>. Avoiding many ways to say the same thing ( <true/>, <string>yes</string>, <string>true</string>, <integer>1<integer> ) is always easier in the code.

It's still recognize, for historic reason, but I thought the new validation capabilities could help as it can tell exactly where and what to do.

If many voices are against that, I can remove that warning, of course.

@Jief_Machak The latest CloverconfiguratorPlist does not recognize the need for a boolean for InjectKext.
If you think, it's best to be more restrictive in technical files. You can introduce a boolean <true/> or <false/> for InjectKext directly in the repo config sample.plist. 

What do you think about sleep/wake up issue with your dirty_efi (2021-04-25-19-03-21-afa09cc-dirty-jief)? My Z390 rig can't wake up after sleep ! Please tell me.

Edited April 26, 2021 by Matgen84

[Jief_Machak]

3 hours ago, Matgen84 said:

@Jief_Machak The latest CloverconfiguratorPlist does not recognize the need for a boolean for InjectKext.
If you think, it's best to be more restrictive in technical files. You can introduce a boolean <true/> or <false/> for InjectKext directly in the repo config sample.plist. 

What do you think about sleep/wake up issue with your dirty_efi (2021-04-25-19-03-21-afa09cc-dirty-jief)? My Z390 rig can't wake up after sleep ! Please tell me.

Do you have the problem with this one : https://github.com/jief666/CloverCommits/blob/master/C-20210423175459-afa09cc.efi ?

CloverconfiguratorPlist will be up to date when I'll first commit this version with the new parser.

[Slice]

3 hours ago, Jief_Machak said:

To get table 132 I had to define QPI CloverX64-2021-04-26-15-06-03-afa09cc-dirty-jief.zip, but I have it now.

Max Speed too.

Thanks for the test.

I personally think it's best to be more restrictive in technical files. A boolean is supposed to be <true/> or <false/>. Avoiding many ways to say the same thing ( <true/>, <string>yes</string>, <string>true</string>, <integer>1<integer> ) is always easier in the code.

It's still recognize, for historic reason, but I thought the new validation capabilities could help as it can tell exactly where and what to do.

If many voices are against that, I can remove that warning, of course.

OK, SMBIOS is the same as early except table 11, you already know.

ACPI is good too.

Then I look into boot.log and see GetDevices() was called twice

=== [ GetDefaultCpuSettings ] ===================
=== [ GetDevices ] ==============================
GOP found at: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010304)
PCI (00|00:00.00) : 8086 191F class=060000
PCI (00|00:01.00) : 8086 1901 class=060400
PCI (00|01:00.00) : 1002 67DF class=030000
 - GOP: Provided by device
 - GFX: Model=AMD Radeon RX 480/570/580 (ATI/AMD)
PCI (00|01:00.01) : 1002 AAF0 class=040300
 - HDMI Audio: 
PCI (00|00:02.00) : 8086 1912 class=038000
 - GFX: Model=Intel HD Graphics 530 (Intel)
PCI (00|00:14.00) : 8086 A12F class=0C0330
PCI (00|00:16.00) : 8086 A13A class=078000
PCI (00|00:17.00) : 8086 A102 class=010601
PCI (00|00:1B.00) : 8086 A167 class=060400
PCI (00|00:1B.02) : 8086 A169 class=060400
PCI (00|00:1B.03) : 8086 A16A class=060400
PCI (00|00:1C.00) : 8086 A110 class=060400
PCI (00|00:1C.02) : 8086 A112 class=060400
PCI (00|00:1C.04) : 8086 A114 class=060400
PCI (00|00:1D.00) : 8086 A118 class=060400
PCI (00|00:1F.00) : 8086 A145 class=060100
PCI (00|00:1F.02) : 8086 A121 class=058000
PCI (00|00:1F.03) : 8086 A170 class=040300
PCI (00|00:1F.04) : 8086 A123 class=0C0500
PCI (00|00:1F.06) : 8086 15B8 class=020000
 - LAN: 0 Vendor=Intel
_checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Z170X-UD5 TH--00-00-00-00-00-00'. Dir doesn't exist.
_checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Z170X-UD5 TH-CF\UEFI'. Dir doesn't exist.
_checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Z170X-UD5 TH'. Dir doesn't exist.
_checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Z170X-UD5 TH-3100'. Dir doesn't exist.
_checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Z170X-UD5 TH-CF'. Dir doesn't exist.
_checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Z170X-UD5 TH-CF-3100'. Dir doesn't exist.
Kexts dir = '\EFI\CLOVER\Kexts'
=== [ GetUserSettings ] =========================
Using config.plist at path: \EFI\CLOVER
Cannot find smbios.plist at path '\EFI\CLOVER' : Not Found
'\EFI\CLOVER\smbios.plist' not loaded. Efi error Not Found
BiosVersion: not set, Using BiosVersion from clover
BiosVersion: IM171.88Z.F000.B00.2004240904
BiosReleaseDate: not set, Using BiosReleaseDate from clover
BiosReleaseDate: 04/24/2020

Using EfiVersion from clover: 178.0.0.0.0
=== [ GetDevices ] ==============================
GOP found at: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010304)
PCI (00|00:00.00) : 8086 191F class=060000
PCI (00|00:01.00) : 8086 1901 class=060400
PCI (00|01:00.00) : 1002 67DF class=030000
 - GOP: Provided by device
 - GFX: Model=AMD Radeon RX 480/570/580 (ATI/AMD)
PCI (00|01:00.01) : 1002 AAF0 class=040300
 - HDMI Audio: 
PCI (00|00:02.00) : 8086 1912 class=038000
 - GFX: Model=Intel HD Graphics 530 (Intel)
PCI (00|00:14.00) : 8086 A12F class=0C0330
PCI (00|00:16.00) : 8086 A13A class=078000
PCI (00|00:17.00) : 8086 A102 class=010601
PCI (00|00:1B.00) : 8086 A167 class=060400
PCI (00|00:1B.02) : 8086 A169 class=060400
PCI (00|00:1B.03) : 8086 A16A class=060400
PCI (00|00:1C.00) : 8086 A110 class=060400
PCI (00|00:1C.02) : 8086 A112 class=060400
PCI (00|00:1C.04) : 8086 A114 class=060400
PCI (00|00:1D.00) : 8086 A118 class=060400
PCI (00|00:1F.00) : 8086 A145 class=060100
PCI (00|00:1F.02) : 8086 A121 class=058000
PCI (00|00:1F.03) : 8086 A170 class=040300
PCI (00|00:1F.04) : 8086 A123 class=0C0500
PCI (00|00:1F.06) : 8086 15B8 class=020000
 - LAN: 1 Vendor=Intel
Calibrated TSC Frequency = 2712398330 = 2712MHz

And then

=== [ GetMacAddress ] ===========================
 get legacy LAN MAC, 2 card found
Legacy MAC address of LAN #0= 1C:1B:0D:66:5B:71:
Legacy MAC address of LAN #1= 00:00:00:00:00:00:
=== [ ScanSPD ] =================================

No! I have one LAN.

[Jief_Machak]

4 minutes ago, Slice said:

Then I look into boot.log and see GetDevices() was called twice

Yes, as a quick fix, I had to called again getDevices(). Because the "reading config layer" and the "discover devices and settings" are not 100% separated, I had a problem of the result of GetDevices() being overwritten.

The goal is that all user settings from config plist goes in one data struct (that is already done, not committed) and discovered devices and settings goes in an other one.

I think it's ok like that for now, except if there is a specific problem to discover devices twice. Anyway, that will go away very soon.

 

For a Lan with 00:00:00:00:00:00: mac address, I don't know, I'll try to reproduce here. Does it happen in Qemu ?

[Slice]

5 minutes ago, Jief_Machak said:

Yes, as a quick fix, I had to called again getDevices(). Because the "reading config layer" and the "discover devices and settings" are not 100% separated, I had a problem of the result of GetDevices() being overwritten.

The goal is that all user settings from config plist goes in one data struct (that is already done, not committed) and discovered devices and settings goes in an other one.

I think it's ok like that for now, except if there is a specific problem to discover devices twice. Anyway, that will go away very soon.

 

For a Lan with 00:00:00:00:00:00: mac address, I don't know, I'll try to reproduce here. Does it happen in Qemu ?

Double LAN because of double GetDevices().

But in Qemu we can't see legacy LAN address. It is not emulated by Qemu yet.

=== [ GetMacAddress ] ===========================
=== [ ScanSPD ] =================================
Scanning SMBus [8086:2930], mmio: 0x0, ioport: 0xB100, hostc: 0x1
=== [ GetAcpiTablesList ] =======================

 

[Slice]

I splitted reading of config.plist into two stages GetEarlyUserSettings and GetUserSettings because of calculation order.

Don't remember exactly but 

1. Get Early...

2. Start calculation knowing some user setttings and prepare default values

3. Get UserSettings with taking into account the default values calculated in 1. and 2.

4. We can change some values in GUI and the change must be applied before OS started.

 

[Jief_Machak]

11 minutes ago, Slice said:

I splitted reading of config.plist into two stages GetEarlyUserSettings and GetUserSettings because of calculation order.

Don't remember exactly but 

1. Get Early...

2. Start calculation knowing some user setttings and prepare default values

3. Get UserSettings with taking into account the default values calculated in 1. and 2.

4. We can change some values in GUI and the change must be applied before OS started.

 

Yep, I got that.

I take it a bit further : we'll have a configPlist object that'll hold all settings. No modification allowed once read. Then I'll finished a "discoveredSettings" (or whatever name) data struct that'll hold all current hardware settings. The 2 will be totally independent.

Then, a in a "merge" function, we'll select what goes into gSettings.

In case of a config plist change by menu, we'll just re-read the configPlist. In case of device change (is it possible ?), we'll just discover again. Then calling "merge".

For example, currently, reading settings also might modify gCPUStructure. But gCPUStructure is initialised with discovered settings. That's why order is important. Separating into 2 differents independent data structure make it easier to know what to choose because both value are available and we know where they come from, so we know which one has precedence.

 

The fact that configPlist is 100% independent of the current hardware discovered config is also needed to be able to have the validator working on any platform.

[Matgen84]

1 hour ago, Jief_Machak said:

Do you have the problem with this one : https://github.com/jief666/CloverCommits/blob/master/C-20210423175459-afa09cc.efi ?

CloverconfiguratorPlist will be up to date when I'll first commit this version with the new parser.

@Jief_Machak the commit  b0e70e0   / C-20210423175459-afa09cc.efi boot Big Sur 11.4 Beta 1, BUT WAKE ISSUE from sleep  

Edited April 26, 2021 by Matgen84

[Slice]

1 hour ago, Matgen84 said:

@Jief_Machak the commit  b0e70e0   / C-20210423175459-afa09cc.efi boot Big Sur 11.4 Beta 1, BUT WAKE ISSUE from sleep  

What is the commit?

[Jief_Machak]

1 hour ago, Matgen84 said:

@Jief_Machak the commit  b0e70e0   / C-20210423175459-afa09cc.efi boot Big Sur 11.4 Beta 1, BUT WAKE ISSUE from sleep  

As usual, the way to debug, a bit annoying I know, is to find at which exact point it started to not work anymore.

In https://github.com/jief666/CloverCommits, you'll find all my DEBUG compilations. File name format is C-YYYYMMDDHHMMSS-{sha 7 chars}.efi.

You just tried C-20210423175459-afa09cc.efi, right ? And it doesn't work. It's already a valuable information as I know that it's not my current refactoring that introduced the problem !.

May I suggest you try : https://github.com/jief666/CloverCommits/blob/master/C-20210411074317-fd3b09c-5133.efi. It's about 22 commits earlier.

The principle is simple. If it works, we'll move 11 commits later, if it doesn't we'll go even earlier.

[Slice]

8 hours ago, Jief_Machak said:

To get table 132 I had to define QPI CloverX64-2021-04-26-15-06-03-afa09cc-dirty-jief.zip, but I have it now.

Max Speed too.

Thanks for the test.

I personally think it's best to be more restrictive in technical files. A boolean is supposed to be <true/> or <false/>. Avoiding many ways to say the same thing ( <true/>, <string>yes</string>, <string>true</string>, <integer>1<integer> ) is always easier in the code.

It's still recognize, for historic reason, but I thought the new validation capabilities could help as it can tell exactly where and what to do.

If many voices are against that, I can remove that warning, of course.

One more observation. I can't put computer to sleep while it was good with older Clover.

[Jief_Machak]

39 minutes ago, Slice said:

One more observation. I can't put computer to sleep while it was good with older Clover.

Is it ok with the last commit : https://github.com/jief666/CloverCommits/blob/master/C-20210423175459-afa09cc.efi ? MatGen84 seems to have wake problem with this version (which is still an "older" clover).

Any idea what can mess up with sleep (and maybe wake for MatGen84) ? Shouldn't be Smbios, you've compared. A device properties ? A kext patch ?

[Slice]

5 hours ago, Jief_Machak said:

Is it ok with the last commit : https://github.com/jief666/CloverCommits/blob/master/C-20210423175459-afa09cc.efi ? MatGen84 seems to have wake problem with this version (which is still an "older" clover).

Any idea what can mess up with sleep (and maybe wake for MatGen84) ? Shouldn't be Smbios, you've compared. A device properties ? A kext patch ?

Double GetDevices() is the reason.

[Slice]

6 hours ago, Jief_Machak said:

Is it ok with the last commit : https://github.com/jief666/CloverCommits/blob/master/C-20210423175459-afa09cc.efi ? MatGen84 seems to have wake problem with this version (which is still an "older" clover).

Any idea what can mess up with sleep (and maybe wake for MatGen84) ? Shouldn't be Smbios, you've compared. A device properties ? A kext patch ?

Sleep-wake success.

[Matgen84]

18 hours ago, Jief_Machak said:

As usual, the way to debug, a bit annoying I know, is to find at which exact point it started to not work anymore.

In https://github.com/jief666/CloverCommits, you'll find all my DEBUG compilations. File name format is C-YYYYMMDDHHMMSS-{sha 7 chars}.efi.

You just tried C-20210423175459-afa09cc.efi, right ? And it doesn't work. It's already a valuable information as I know that it's not my current refactoring that introduced the problem !.

May I suggest you try : https://github.com/jief666/CloverCommits/blob/master/C-20210411074317-fd3b09c-5133.efi. It's about 22 commits earlier.

The principle is simple. If it works, we'll move 11 commits later, if it doesn't we'll go even earlier.

@Jief_Machak 

Test: Z390 config Big Sur 11.4 Beta 1

BootLoaderChooser: Usb pen drive 1

 

C-20210423175459-afa09cc.efi / b0e70e0  ----> Boot fine ---> NO WAKE UP

C-20210411074317-fd3b09c-5133.efi / 9b283e97 --->  Boot fine ---> NO WAKE UP 
C-20210401110653-69a47c5.efi / 8da1df2 ----> Boot fine ----> NO WAKE UP 

CLOVERX64_5133_afa09ccb4 (my local GitHub build) ----> Boot fine ----> NO WAKE UP

C-20210402104623-9690966.efi / 9ded6b4 ---> Boot fine ----> NO WAKE UP

Without BootloaderChooser

CLOVER r5133 (commit: 541762427) - 20210416 ---> Boot fine ---->     WAKE UP is OK

From HDD

CLOVER r5132 commit 9690966 (my local GitHub build) ---> Boot   fine  --->   WAKE UP is     OK

 

Without BootloaderChooser: USB pen drive 2

 

r5133 (commit: 541762427) - 20210416 ---> Boot fine ----> WAKE UP is OK (+Force eject, +USB not mounted at wake)     My local build.

CloverX64-2021-04-25-19-03-21-afa09cc-dirty-jief 2.efi  (Rename CLOVERX64.EFI)----> Boot fine    ->WAKE UP is OK (+Force eject, +USB not mounted at wake) - No debug.log generated - Clover Info not verified in GUI
First test:
C-20210423175459-afa09cc.efi / b0e70e0 (Rename CLOVERX64.efi)---> Boot fine ----> WAKE UP is OK (+Force eject +USB not mounted at wake )- Clover keep info of r    5133 (commit: 541762427) ? Despite F11 x 3 times

Second test:
C-20210423175459-afa09cc.efi / b0e70e0 (Rename CLOVERX64.efi)---> Boot fine ----> WAKE UP is OK (+Force eject +USB not mounted at wake )- Clover keep info of r    5133 (commit: 541762427) ? Despite F11 x 6 times

 

2021-4-26_16-46_C-20210411074317-fd3b09c-5133.efi.log 2021-4-27_6-14_C-20210401110653-69a47c5.efi.log 2021-4-27_7-2_541762427_BOOTX64.EFI.log

Edited April 27, 2021 by Matgen84

[Jief_Machak]

4 hours ago, Slice said:

Double GetDevices() is the reason.

How's that ? What's in it that makes that ?