Clover General discussion

[chris1111]

Guys the HP Probook Elitebook Clover is ready Big Sur and Monterey, its a great peace of software 👌

Thanks to @Slice for developing and maintaining Clover on TOP ! 

Spoiler

 

Edited April 11, 2022 by chris1111

[chris1111]

Clover WIKI is almost done 👍

[Guest 5T33Z0]

On 4/10/2022 at 5:32 PM, 5T33Z0 said:

@SliceI already deleted the whole key and created a new one. Nothing unusual when dumping the ACPI tables either. There are no hidden chars in the file:

 

 

Just an update: still can't drop DMAR on my desktop pc. The workaround I use now is enabling AutoMerge so my DMAR replacement table is merged with the original.

[Slice]

19 minutes ago, 5T33Z0 said:

 

Just an update: still can't drop DMAR on my desktop pc. The workaround I use now is enabling AutoMerge so my DMAR replacement table is merged with the original.

C u

We may know more about the problem if create a special Clover version with more debug output in the ACPI patching.

[Slice]

17 hours ago, chris1111 said:

Clover WIKI is almost done 👍

I started to EDIT the WiKi

[chris1111]

1 hour ago, Slice said:

I started to EDIT the WiKi

I see, great

[Jief_Machak]

Hi all.

For the first time since a loooong while, I got some time to commit a nice refactoring (Yes, I know, another one 😀). Does it change anything for users ? Of course not  !

 

I replaced the basic struct EFI_GUID by a class of the same name. What for ? Make it nicer for developer, which means more obvious, which mean less bug.

 

* the object is 100% binary compatible with the previous one. So low level operation (CopyMem, CompareGuid, etc.) are still possible like before. It can also be passed to the libraries.

* no need anymore for (let's say you have a EFI_GUID guid object) :

   - StrToGuid : just call guid.toXString8() or guid.toXStringW() (you can chain guid.toXString8().c_str() or guid.toXStringW().wc_str() if low level char access is needed).

   - AsciiStrToGuid : just call guid.takeValueFrom(...)

   - CopyGuid : just assign. guid1 = guid2

   - CompareGuid : just compare. "if ( guid1 == guid2 )". (Honestly, return true when equal when all C compare function return 0 when equal ???. That's why more obvious is less bug)

* I replaced all CONST EFI_GUID* in librairies parameter by const EFI_GUID& through a preprocessor macro (CONST_EFI_GUID_PTR_T and JCONST_EFI_GUID_PTR_T). So when it's compiled without this new replacement, it compiles exactly like it was before.

 

Why replacing a pointer (CONST EFI_GUID*) by a reference (const EFI_GUID&) ? For the usual reason : if you call an EFI function that takes a pointer to a guid, you can (you should!) always wonder if the function will modify that parameter. EDK function are generally well made enough to identify IN and OUT parameter, but you have to go look at the documentation or the prototype. Now, because you can call a function that takes an EFI_GUID parameter as input without taking the address yourself, you know that it's an non modified input parameter.

Example : instead of

Status = gBS->LocateProtocol(&gAppleSMCProtocolGuid, NULL, (void**)&gAppleSmc);

use

Status = gBS->LocateProtocol(gAppleSMCProtocolGuid, NULL, (void**)&gAppleSmc);

The idea is : use a guid like you would use an int. Assign, compare, give as parameter.

Of course, if a function has an output EFI_GUID parameter, the need to take the address with & remains to remind you that it will be changed by the call.

 

Ok, now I'm going back to the refactor I've started more than 2 years ago 😇

 

 

 

[LAbyOne]

@Jief_Machak sent you a pm about that.

[Slice]

Hi @Jief_Machak,

Good work as usual.

Can you also comment your commit about "Skip" in patching?

[chris1111]

16 hours ago, Jief_Machak said:

Hi all.

For the first time since a loooong while, I got some time to commit a nice refactoring (Yes, I know, another one 😀). Does it change anything for users ? Of course not  !

 

I replaced the basic struct EFI_GUID by a class of the same name. What for ? Make it nicer for developer, which means more obvious, which mean less bug.

 

* the object is 100% binary compatible with the previous one. So low level operation (CopyMem, CompareGuid, etc.) are still possible like before. It can also be passed to the libraries.

* no need anymore for (let's say you have a EFI_GUID guid object) :

   - StrToGuid : just call guid.toXString8() or guid.toXStringW() (you can chain guid.toXString8().c_str() or guid.toXStringW().wc_str() if low level char access is needed).

   - AsciiStrToGuid : just call guid.takeValueFrom(...)

   - CopyGuid : just assign. guid1 = guid2

   - CompareGuid : just compare. "if ( guid1 == guid2 )". (Honestly, return true when equal when all C compare function return 0 when equal ???. That's why more obvious is less bug)

* I replaced all CONST EFI_GUID* in librairies parameter by const EFI_GUID& through a preprocessor macro (CONST_EFI_GUID_PTR_T and JCONST_EFI_GUID_PTR_T). So when it's compiled without this new replacement, it compiles exactly like it was before.

 

Why replacing a pointer (CONST EFI_GUID*) by a reference (const EFI_GUID&) ? For the usual reason : if you call an EFI function that takes a pointer to a guid, you can (you should!) always wonder if the function will modify that parameter. EDK function are generally well made enough to identify IN and OUT parameter, but you have to go look at the documentation or the prototype. Now, because you can call a function that takes an EFI_GUID parameter as input without taking the address yourself, you know that it's an non modified input parameter.

Example : instead of

Status = gBS->LocateProtocol(&gAppleSMCProtocolGuid, NULL, (void**)&gAppleSmc);

use

Status = gBS->LocateProtocol(gAppleSMCProtocolGuid, NULL, (void**)&gAppleSmc);

The idea is : use a guid like you would use an int. Assign, compare, give as parameter.

Of course, if a function has an output EFI_GUID parameter, the need to take the address with & remains to remind you that it will be changed by the call.

 

Ok, now I'm going back to the refactor I've started more than 2 years ago 😇

 

 

 

Ok great but big problem with Xcode on that commits. Not test GCC

Spoiler

 

 

 

 

Edited April 27, 2022 by chris1111

[Slice]

No errors with gcc.

[Jief_Machak]

14 hours ago, chris1111 said:

Ok great but big problem with Xcode on that commits. Not test GCC

  Reveal hidden contents

 

 

 

 

You probably have a newer Xcode than me. They have deprecated something. I'll a closer look in few hours.

23 hours ago, Slice said:

Hi @Jief_Machak,

Good work as usual.

Can you also comment your commit about "Skip" in patching?

It skips some replacement. Like for kernel and kext patching.

I know that TgtBridge is a way better way. because DSDT can change with BIOS settings, using a skip count is unreliable. But I end up with a case I couldn't resolve with TgtBridge...

[Matgen84]

2 hours ago, Jief_Machak said:

You probably have a newer Xcode than me. They have deprecated something. I'll a closer look in few hours.

Hi @Jief_Machak glad to see you back on the forum. 🙂

I also have the same problem with XCODE 12.4 on Catalina.

[Slice]

18 hours ago, chris1111 said:

Ok great but big problem with Xcode on that commits. Not test GCC

  Reveal hidden contents

 

 

 

 

Attention of @Jief_Machak

https://stackoverflow.com/questions/66115771/whats-the-meaning-of-gcc-g-error-implicitly-declared-constructor-is-depreca

[chris1111]

4 hours ago, Jief_Machak said:

You probably have a newer Xcode than me. They have deprecated something. I'll a closer look in few hours.

It skips some replacement. Like for kernel and kext patching.

I know that TgtBridge is a way better way. because DSDT can change with BIOS settings, using a skip count is unreliable. But I end up with a case I couldn't resolve with TgtBridge...

Hi

I use Xcode 13.2.1

 

[tluck]

7 hours ago, chris1111 said:

Hi

I use Xcode 13.2.1

 

im on 13.2.1 too and see this trying to compile the last commit.

```

CC] Test

In file included from <built-in>:1:

In file included from /opt/Source/Clover/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit/DEBUG/AutoGen.h:16:

In file included from /opt/Source/Clover/MdePkg/Include/Uefi.h:23:

  constexpr GUID(const GUID& other) : GUID{other.Data1, other.Data2, other.Data3, {other.Data4[0], other.Data4[1], other.Data4[2], other.Data4[3], other.Data4[4], other.Data4[5], other.Data4[6], other.Data4[7]}} { }

            ^

/opt/Source/Clover/rEFIt_UEFI/include/Guid++.h:69:26: note: in implicit copy assignment operator for 'GUID' first required here

  void setNull() { *this = GUID(); }

                         ^

[DLINK] SMCHelper

[SLINK] UsbMouseDxe

[DLINK] NullMemoryTestDxe

[CC] BiosVideo

[CC] AutoGen

[DLINK] UsbMouseDxe

[CC] AutoGen

[SLINK] FSInject

[SLINK] OhciDxe

[SLINK] GraphicsConsoleDxe

[DLINK] FSInject

[CC] ComponentName

[DLINK] OhciDxe

[DLINK] GraphicsConsoleDxe

[CC] AudioDxe

[CC] ComponentName

[MTOC] NullMemoryTestDxe

1 error generated.

[CC] UsbBus

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

 

 

build.py...

: error 7000: Failed to execute command

make tbuild [/opt/Source/Clover/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit]

 

[matxpa]

Hi,

with Xcode 13.3.1 and Monterey 12.4 beta 3 (21F5063e) too, same error with r5146 and last commit 1ea4700.

 

[Slice]

@chris1111, @tluck, check commit 60b2ed52b

[LAbyOne]

Posted new update to Clover Suite Builder 1.7

a few tools needed correcting typos and few more added

 

[Matgen84]

14 hours ago, Slice said:

@chris1111, @tluck, check commit 60b2ed52b

@Slice can't build commit 60b2ed52b. (Catalina, XCODE 12.4). Build log file attached.

 

Clover_Build.log

[chris1111]

15 hours ago, Slice said:

@chris1111, @tluck, check commit 60b2ed52b

@Slice

No error again

EDIT ***

ACPIPatcher fault

 

Spoiler

1 error generated.
make: *** [/Users/chris/src/CloverBootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit/OUTPUT/Platform/AcpiPatcher.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/chris/src/CloverBootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit]


build.py...
 : error F002: Failed to build module
	/Users/chris/src/CloverBootloader/rEFIt_UEFI/refit.inf [X64, XCODE8, RELEASE]

- Failed -
Build end time: 05:42:07, Apr.30 2022
Build total time: 00:00:49

 

 

Edited April 30, 2022 by chris1111

[Slice]

9 minutes ago, chris1111 said:

@Slice

No error again

EDIT ***

ACPIPatcher fault

 

  Hide contents

1 error generated.
make: *** [/Users/chris/src/CloverBootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit/OUTPUT/Platform/AcpiPatcher.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/chris/src/CloverBootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit]


build.py...
 : error F002: Failed to build module
	/Users/chris/src/CloverBootloader/rEFIt_UEFI/refit.inf [X64, XCODE8, RELEASE]

- Failed -
Build end time: 05:42:07, Apr.30 2022
Build total time: 00:00:49

 

 

Please provide full log as I see no whre the error was occured.

 

36 minutes ago, Matgen84 said:

@Slice can't build commit 60b2ed52b. (Catalina, XCODE 12.4). Build log file attached.

 

Clover_Build.log 135.81 kB · 0 downloads

This is dirty compilation. Delete Build folder and try again.

 

@Jief_Machak

New Clover hangs at

        DBG("    Boot0082 points to Volume with UUID:%s\n", BootGUID.toXString8().c_str());

because BootGUID is null.

Old clover has strguid(BootGUID) which produces a string "<null guid>" in this case.

[chris1111]

6 minutes ago, Slice said:

Please provide full log as I see no whre the error was occured.

 

here full output

Terminal Saved Output.zip

[Matgen84]

1 hour ago, Slice said:

This is dirty compilation. Delete Build folder and try again.

 

I manually remove Build folder and Clover_Build.log file from previous build. Normally, my script does it automatically at each compilation.

Clover_Build.log

[Slice]

2 hours ago, chris1111 said:

here full output

Terminal Saved Output.zip 14.48 kB · 0 downloads

OK, understand.  It is second appearance of the conflict.

 

Test please commit 4ba408424

1 hour ago, Matgen84 said:

 

I manually remove Build folder and Clover_Build.log file from previous build. Normally, my script does it automatically at each compilation.

Clover_Build.log 113.34 kB · 0 downloads

I didn't understand this message

Quote

[CC] DebugHelp
<built-in>:367:10: warning: non-portable path to file '"/Users/mathieu/src/CloverBootloader/Build/Clover/RELEASE_XCODE8/X64/MdePkg/Library/BaseLib/BaseLib/DEBUG/AutoGen.h"'; specified path differs in case from file name on disk [-Wnonportable-include-path]
#include "/Users/mathieu/src/Cloverbootloader/Build/Clover/RELEASE_XCODE8/X64/MdePkg/Library/BaseLib/BaseLib/DEBUG/AutoGen.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         "/Users/mathieu/src/CloverBootloader/Build/Clover/RELEASE_XCODE8/X64/MdePkg/Library/BaseLib/BaseLib/DEBUG/AutoGen.h"
1 warning generated.
[

Autogen.h from MdePkg is not my mistake. Why this warning is here?