Clover General discussion

[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 ?

 

[Slice]

You found 2 LANs and the power management tree appears to be broken.

[Matgen84]

6 hours ago, Matgen84 said:

@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 74.35 kB · 0 downloads 2021-4-27_6-14_C-20210401110653-69a47c5.efi.log 73.69 kB · 0 downloads 2021-4-27_7-2_541762427_BOOTX64.EFI.log 116.54 kB · 0 downloads

@Jief_Machak One more test (Z390 config Big Sur 11.4 Beta 1)

 

Without BootloaderChooser:

C-20210423175459-afa09cc.efi / b0e70e0 (Rename CLOVERX64/BOOTX64)  ----> Boot fine --->     WAKE UP is OK

The same version do not wake up with CloverBootloaderChooser. Maybe the tool has a problem ?

Edited April 27, 2021 by Matgen84

[kushwavez]

very interesting. It has nothing to do with Clover or the system. The Chooser is just a simple bootmanager choosing an .efi

[Jief_Machak]

1 hour ago, kushwavez said:

very interesting. It has nothing to do with Clover or the system. The Chooser is just a simple bootmanager choosing an .efi

Yes exactly.

BootloaderChooser doesn't initialise anything, doesn't override or install any protocol, etc etc.

 

5 hours ago, Matgen84 said:

@Jief_Machak One more test (Z390 config Big Sur 11.4 Beta 1)

 

Without BootloaderChooser:

C-20210423175459-afa09cc.efi / b0e70e0 (Rename CLOVERX64/BOOTX64)  ----> Boot fine --->     WAKE UP is OK

The same version do not wake up with CloverBootloaderChooser. Maybe the tool has a problem ?

But that's interesting. But to be sure, we have to rule out some possibility.

For example, could it be for some other reason that wake works or not. Like cold boot vs warn boot. Or if you boot another in the middle. Or if wifi is connected. Or god knows what. Or just intermittent problem.

So if you can, it'll be extremely interesting if you can repeat the test 5/6 times, confirm that each time without BootloaderChooser it'ok and each time with it it's broken.

But the best, I think, is to use your hack normally. Like you boot in the morning with BootLoaderChooser and use your hack as usual. If it doesn't wake. Reboot and use it again normally. After 5/6 times (which could be 5/6 days), you'll know if it never works.

Then, boot each morning without BootLoaderChooser. See how it goes.

6 hours ago, Slice said:

You found 2 LANs and the power management tree appears to be broken.

Ok, I understand. How do I dump and compare power management tree ? ioreg ?

I'm doing some final testing on the version that doesn't call GetDevices twice...

[tluck]

FWIW: had a compile issue with Xcode 12.5 (12.4 is ok)

[CPP] Settings

In file included from /opt/Source/edk2/Clover/rEFIt_UEFI/Platform/Settings.cpp:6:

In file included from /opt/Source/edk2/Clover/rEFIt_UEFI/gui/../Platform/Settings.h:5:

In file included from /opt/Source/edk2/Clover/rEFIt_UEFI/entry_scan/../gui/menu_items/menu_items.h:39:

In file included from /opt/Source/edk2/Clover/rEFIt_UEFI/Platform/KERNEL_AND_KEXT_PATCHES.h:12:

In file included from /opt/Source/edk2/Clover/rEFIt_UEFI/refit/../libeg/libeg.h:43:

  XStringArray_(const XStringArray_& other) : array() {

  ^

/opt/Source/edk2/Clover/rEFIt_UEFI/gui/../cpp_foundation/XStringArray.h:322:7: note: in implicit copy assignment operator for 'XStringArray_<XStringW, XStringWArray>' first required here

class XStringWArray : public XStringArray_<XStringW, XStringWArray>

      ^

/opt/Source/edk2/Clover/rEFIt_UEFI/Platform/KERNEL_AND_KEXT_PATCHES.h:143:7: note: in implicit copy assignment operator for 'XStringWArray' first required here

class KERNEL_AND_KEXT_PATCHES

      ^

/opt/Source/edk2/Clover/rEFIt_UEFI/Platform/Settings.cpp:227:24: note: in implicit copy assignment operator for 'KERNEL_AND_KEXT_PATCHES' first required here

  KernelAndKextPatches = gSettings.KernelAndKextPatches; // Jief : why do we have a duplicated KernelAndKextPatches var inside CUSTOM_LOADER_ENTRY ?

                       ^

1 error generated.

make: *** [/opt/Source/edk2/Clover/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit/OUTPUT/Platform/Settings.obj] Error 1

[makk]

Slice Clover 5133 on my system is not injecting kexts what could be wrong that I am doing?

 

It works in 5127 and 5128 to inject kexts.
What other method can I use to inject?

I don't recall the way to do it Kernel and KextPatches>ForceKextsToLoad

 

Thank you for everything you have done

Have a great day!

 

[Jief_Machak]

1 hour ago, makk said:

Slice Clover 5133 on my system is not injecting kexts what could be wrong that I am doing?

 

It works in 5127 and 5128 to inject kexts.
What other method can I use to inject?

I don't recall the way to do it Kernel and KextPatches>ForceKextsToLoad

 

Thank you for everything you have done

Have a great day!

 

Try this efi file : https://github.com/jief666/CloverCommits/blob/master/C-20210328105819-0035ed3-5132.efi

Does it work ?

[Jief_Machak]

@everyone : could test this : CloverX64-2021-04-28-02-03-18-afa09cc-dirty-jief.zip Please.

 

28 minutes ago, jinbingmao said:

2021-04-28 06:59:15.624632+0800 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2021-04-28 06:59:15.624633+0800 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2021-04-28 06:59:15.624797+0800 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2021-04-28 06:59:15.624797+0800 0x71       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
 

bootlog.txt 28.3 kB · 0 downloads

Sorry, I don't understand what you want.

 

If you want help, you'll have to describe the problem. If it something that was working before, you'll have to find which commit broke by trying efi file from here : https://github.com/jief666/CloverCommits

[makk]

7 hours ago, Jief_Machak said:

Try this efi file : https://github.com/jief666/CloverCommits/blob/master/C-20210328105819-0035ed3-5132.efi

Does it work ?

 

I was able to get 5133 after replacing with older version and then putting back 5133 to kick in!

Thank You!

Works!  Some hiccup on EFI partition possibly how to have happy coexistence of Catalina and Big Sur on same Drive?

how to hide each other after boot up? 

Is there a guide on how to do this?

Thank you!

 

[Matgen84]

21 hours ago, Matgen84 said:

@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 74.35 kB · 0 downloads 2021-4-27_6-14_C-20210401110653-69a47c5.efi.log 73.69 kB · 0 downloads 2021-4-27_7-2_541762427_BOOTX64.EFI.log 116.54 kB · 0 downloads

 

9 hours ago, Jief_Machak said:

Yes exactly.

BootloaderChooser doesn't initialise anything, doesn't override or install any protocol, etc etc.

 

But that's interesting. But to be sure, we have to rule out some possibility.

For example, could it be for some other reason that wake works or not. Like cold boot vs warn boot. Or if you boot another in the middle. Or if wifi is connected. Or god knows what. Or just intermittent problem.

So if you can, it'll be extremely interesting if you can repeat the test 5/6 times, confirm that each time without BootloaderChooser it'ok and each time with it it's broken.

But the best, I think, is to use your hack normally. Like you boot in the morning with BootLoaderChooser and use your hack as usual. If it doesn't wake. Reboot and use it again normally. After 5/6 times (which could be 5/6 days), you'll know if it never works.

Then, boot each morning without BootLoaderChooser. See how it goes...

Hi @Jief_Machak I understand your process but it is a bit heavy to achieve. Especially since I have already performed 10 tests including 5 with BootloaderChooser.  I can still do what you recommend.

One question: Is it normal that every time I change Cloverx64 efi, I have to do F11 several times, to be able to boot. It's the same when I update with the pkg

[Jief_Machak]

1 hour ago, Matgen84 said:

your process but it is a bit heavy to achieve. Especially since I have already performed 10 tests including 5 with BootloaderChooser

Yes, I know. It's a pain. But I need to be sure that the wake issue is really created by BootloaderChooser...

1 hour ago, Matgen84 said:

Is it normal that every time I change Cloverx64 efi, I have to do F11 several times

Definitely strange !

I have a computer that sometimes, and I haven't figured it out under what circumstances, reboot at Clover loading, and then it's fine for a while. Not the same as you, though.