Clover General discussion

[Matgen84]

49 minutes ago, chris1111 said:

@Slice thanks latest commit seems to have fixed the Fletch OpenCorePkg 

As @chris1111 says latest commit fix the fletch sud-module OpencorePKG. CloverconfigPlistValidator can't always be build.

OutPut result

[Guest 5T33Z0]

15 hours ago, Stefanalmare said:

ROM îs not necessary, UseMacAddr0 it works just fin. Also I never used Update Firmware Only. Rest is like in your tutorial and is what I did from some time with 7 hacks I play around, different tipes, always latest OS, OC, Clover commits.

 

ROM is a necessary value. It's just a question of where to get it from. If you select "MacAddr0" it uses the MAC Address of your Ethernet Controller. Otherwise you can enter a fake one and that's what the field is for.

You need to use "Update Firmware only" if you're working with an old config. If the firmeware dates back to far you will get an error message about outdated SMC firmware when trying to install macOS and the installer will just quit. So just to be safe, it's wise ti use this function.

Edited May 3, 2022 by 5T33Z0

[MifJpnAlphaPlus]

Spoiler

9 hours ago, 5T33Z0 said:

@Slice There's still something wrong with commit 04e42c09e.

 

This is the data that is entered in the Clover Config. It's the same as in my OpenCore config:

 

 

 

After rebooting with CLover, I am being asked for AppleID Password again. Hackintool Shows Data, that I didn't enter. It looks like Clover is using the Custom UUID as System ID and not as Hardware ID and also reverses the Endianness of the first 2 groups. The original System ID isn't used at all:

 

 

On my 2nd test, I left the Custom UUID empty. Then the System ID is used, but the first 3 pairs of digits are reversed:

 

 

After reverting to the release version of r5146 everything is working as expected.

@5T33Z0

Me too・・・

 

 

Thank you so very much @Slice.
I am very sorry to show you my dirty fork source（in git-hub) as I don't know what @Jief_Machak's intentions are.

From my imagination, I would think that at some stage, smUUID would use the takeValueFromBE method of the EFI_GUID class in <Guid++.h> to swap the Endian.
 I could not understand how the takeValueFromBE method is implemented. （It looks like it is written the same way as above.)

So I used XString8 GuidBeToXString8(const EFI_GUID& Guid) in CloverBootloader/rEFIt_UEFI/Platform/guid.cpp, which I know how it works well.

 Tracing back through the flow of changes, in void PatchTableTypeType1(const SmbiosInjectedSettings& smbiosSettings) in rEFIt_UEFI/Platform/smbios.cpp, we previously had StrToGuidBE( smbiosSettings. SmUUID, &SmUUID); and it seemed to be swapping.

 So I looked at swapping Endian in this part of the DGB(...) output, and CopyMem seemed to be working, but in the end it didn't work.
 I think it is here that the SmUUID enters the structure from the flow, but ・・・・ is kind of strange.
 I'm not familiar with C++, so I'm just an amateur who wants to use cast operators with strict types like in C. So, I was just imitating what I saw.
I'm sorry.
 Reading it is a good way to learn.

For now, I'm going to try it if I can think of something.

 

Translated with www. DeepL.com/Translator (free version)

Edited May 3, 2022 by MifJpnAlphaPlus

[Slice]

12 hours ago, 5T33Z0 said:

@Slice There's still something wrong with commit 04e42c09e.

 

This is the data that is entered in the Clover Config. It's the same as in my OpenCore config:

 

 

 

After rebooting with CLover, I am being asked for AppleID Password again. Hackintool Shows Data, that I didn't enter. It looks like Clover is using the Custom UUID as System ID and not as Hardware ID and also reverses the Endianness of the first 2 groups. The original System ID isn't used at all:

 

 

On my 2nd test, I left the Custom UUID empty. Then the System ID is used, but the first 3 pairs of digits are reversed:

 

 

After reverting to the release version of r5146 everything is working as expected.

Look for 

config.plist->SystemParameters->InjectSystemID=YES

or NO

It will influence on this case.

 

 

 

6 hours ago, y010204025 said:

@Slice,Hi, Slice, I noticed that CLOVER uses rEFIt_uefi. Whether the clover switches from rEFIt to rEFInd again, I noticed that rEFIt has stopped updating for a period of time, and the maintenance of rEFInd is more active, and it has added a lot of modern characteristics.

In addition, there is a rEFIndPlus, which seems to have some repair for MacOS, adding some additional functions, which may have some good ideas as a reference.https://github.com/dakanji/refindplus

This is just an advertisement of rEFind.

It appears after Clover and uses our technologies.

But we live in different worlds. Clover is for Hackintosh while rEFInd is for native Mac.

[tluck]

On 5/2/2022 at 8:40 PM, Slice said:

I restored old smUUID behavior and returned to old AppleID.

commit 04e42c09e

compiles and works great. no issues here. thanks.

[MifJpnAlphaPlus]

 

16 hours ago, tluck said:

compiles and works great. no issues here. thanks.

@tluck. It was good.
Here is a summary of the problems.

The release version is as follows. (31187f6e1):InjectSystemID=ture

Spoiler

2022-05-05_22-28_CLOVERX64.31187f6e1.efi.log

 

 

 

The current version is as follows. (04e42c09e):InjectSystemID=True

Spoiler

 

2022-05-05_22-13_CLOVERX64.04e42c09e.efi.log

CloverV2-5146.zip

@Slice has gone to a lot of trouble to fix this, but for some reason I can't get the DGB＝got LE smUUID to show up.
Is it a different Type of SMBIOS?

config.plist
Help me please.

 

 

each version,InjectSystemID=No

Spoiler

 

config.plist

 

I fixed MLB, firmware, and other minor details, but it seems to be the same. (Sad)

newconfig.plist

Edited May 6, 2022 by MifJpnAlphaPlus

[Guest 5T33Z0]

Some thoughts about some "defaults" of Clover:

• In the zip package, why is FSInject still present in the Drivers/UEFI folder when OpenRuntime handles Kext injetion now? This is only required when using Clover ≤ r5123  with old Aptio memory fixes which are no longer supported.
• The default set of drivers is pretty much useless for UEFI systems. The default set of drivers should be: ApfsDriverLoader.efi,  VBoxHfs.efi, and OpenRuntime.efi
• The sample config, especially the ACPI section is a complete mess as well.

[Slice]

4 hours ago, 5T33Z0 said:

Some thoughts about some "defaults" of Clover:

• In the zip package, why is FSInject still present in the Drivers/UEFI folder when OpenRuntime handles Kext injetion now? This is only required when using Clover ≤ r5123  with old Aptio memory fixes which are no longer supported.
• The default set of drivers is pretty much useless for UEFI systems. The default set of drivers should be: ApfsDriverLoader.efi,  VBoxHfs.efi, and OpenRuntime.efi
• The sample config, especially the ACPI section is a complete mess as well.

Thanks for the notes. I will think about. As far as I remember there are drivers that installed by default and drivers absent by default. I will check this.

FSInject is obsolete for new systems but it still can be used for 10.7.5 if I am not wrong.

config-sample contains all possible keys but mostly commented out to be used only by clever users.

[Slice]

7 hours ago, 5T33Z0 said:

 

• The default set of drivers is pretty much useless for UEFI systems. The default set of drivers should be: ApfsDriverLoader.efi,  VBoxHfs.efi, and OpenRuntime.efi
•  

I still will also recommend drivers to be default: 

Fat.efi - it improves AMI UEFI embedded FAT32 drivers used for EFI partition. The FAT32 file system is very fragile. Our Fat.efi driver much better then one in UEFI BIOS.

SMCHelper.efi if you are using FakeSMC and not using VirtualSMC. Anyway the author of VirtualSMC claims the driver is not compatible with Clover. FakeSMC is.

EnglishDxe.efi - it will provide good UnicodeCollation protocol used by Shell.efi. Sometimes this protocol absent or has bad realisation. It is safe driver even if present twice it will not break anything.

 

 

[Guest 5T33Z0]

I would just focus on the mandatory drivers required to boot a current UEFI system with a recent version of macOS.

Legacy users are stuck with r5123.1 anyway and most of the know what to do anyway since it's more challenging.

 

And delete the "Docs" Folder or updated it so it's actually useful. Nobody needs Install Instructions for OSX 10.7/8

 

These are the kind of small but important things that give Clover a bad reputation.

[LAbyOne]

INFO: @Slice

As per today new GCC 12.1.0 update is available

Heads up for future builds

this release fails building Clover 

halting the process on UsbBusDxe driver

 

/Users/labyone/src/CloverBootloader/Drivers/UsbBusDxe/UsbBus.c: In function 'UsbIoBulkTransfer':
/Users/labyone/src/CloverBootloader/Drivers/UsbBusDxe/UsbBus.c:278:13: error: 'UsbHcBulkTransfer' accessing 80 bytes in a region of size 8 [-Werror=stringop-overflow=]
  278 |   Status  = UsbHcBulkTransfer (
      |             ^~~~~~~~~~~~~~~~~~~
  279 |               Dev->Bus,
      |               ~~~~~~~~~
  280 |               Dev->Address,
      |               ~~~~~~~~~~~~~
  281 |               Endpoint,
      |               ~~~~~~~~~
  282 |               Dev->Speed,
      |               ~~~~~~~~~~~
  283 |               EpDesc->Desc.MaxPacketSize,
      |               ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  284 |               BufNum,
      |               ~~~~~~~
  285 |               &Data,
      |               ~~~~~~
  286 |               DataLength,
      |               ~~~~~~~~~~~
  287 |               &Toggle,
      |               ~~~~~~~~
  288 |               Timeout,
      |               ~~~~~~~~
  289 |               &Dev->Translator,
      |               ~~~~~~~~~~~~~~~~~
  290 |               UsbStatus
      |               ~~~~~~~~~
  291 |               );
      |               ~
/Users/labyone/src/CloverBootloader/Drivers/UsbBusDxe/UsbBus.c:278:13: note: referencing argument 7 of type 'void *[10]'
In file included from /Users/labyone/src/CloverBootloader/Drivers/UsbBusDxe/UsbBus.h:46,
                 from /Users/labyone/src/CloverBootloader/Drivers/UsbBusDxe/UsbBus.c:16:
/Users/labyone/src/CloverBootloader/Drivers/UsbBusDxe/UsbUtility.h:200:1: note: in a call to function 'UsbHcBulkTransfer'
  200 | UsbHcBulkTransfer (
      | ^~~~~~~~~~~~~~~~~
At top level:
cc1: note: unrecognized command-line option '-Wno-incompatible-ms-struct' may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
make: *** [/Users/labyone/src/CloverBootloader/Build/Clover/RELEASE_GCC53/X64/Drivers/UsbBusDxe/UsbBusDxe/OUTPUT/UsbBus.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/labyone/src/CloverBootloader/Build/Clover/RELEASE_GCC53/X64/Drivers/UsbBusDxe/UsbBusDxe]


build.py...
 : error F002: Failed to build module
	/Users/labyone/src/CloverBootloader/Drivers/UsbBusDxe/UsbBusDxe.inf [X64, GCC53, RELEASE]

- Failed -
Build end time: 20:03:08, May.06 2022
Build total time: 00:03:08

investigating further..

[Guest 5T33Z0]

BTW: that System ID / Hardware-ID endiannes flipping isssue is still not resolved. I've build Clover from source with Clover Suite Builder and it still flipped the pairs of digits as explained in my previous post.

[Slice]

@LAbyOne

I can test new gcc. Is there any changes in build_gcc script except gcc version?

 

10 hours ago, 5T33Z0 said:

BTW: that System ID / Hardware-ID endiannes flipping isssue is still not resolved. I've build Clover from source with Clover Suite Builder and it still flipped the pairs of digits as explained in my previous post.

Flipped compared to 5146? I see no this. The issue with smUUID I resolved. But CustonUUID entered in text form so it should be in right endianess.

[Guest 5T33Z0]

Please copy over Data from OpenCore Config into Clover, reboot and see what happens to System UUID and Hardware ID in hackintool when iusing the latest build. Maybe then you understand.

[Slice]

56 minutes ago, 5T33Z0 said:

Please copy over Data from OpenCore Config into Clover, reboot and see what happens to System UUID and Hardware ID in hackintool when iusing the latest build. Maybe then you understand.

I have no working copy of OpenCore.

So you say that this operation is successful with Clover 5146 and failed with latest commit?

[Guest 5T33Z0]

@Slice YES. That is what I have been trying to tell you since a couple of days now. As explained in detail in this post

 

 

Edited May 7, 2022 by 5T33Z0

[Slice]

5 minutes ago, 5T33Z0 said:

@Slice YES. That is what me have been trying to tell you since a couple of days now. As explained in detail in this post

 

 

Test, please

rEFIt_UEFI/Settings/ConfigPlist/Config_SystemParameters.h: line 78

    g.takeValueFrom(CustomUUID.value()); ->     g.takeValueFromBE(CustomUUID.value());

[Guest 5T33Z0]

1 minute ago, Slice said:

Test, please

rEFIt_UEFI/Settings/ConfigPlist/Config_SystemParameters.h: line 78

    g.takeValueFrom(CustomUUID.value()); ->     g.takeValueFromBE(CustomUUID.value());

 

I don't know enough about coding to do this. Maybe @LAbyOne can test this.

[Slice]

1 hour ago, 5T33Z0 said:

 

I don't know enough about coding to do this. Maybe @LAbyOne can test this.

Open the file by TextEdit and write two letters in line 78. Then compile as you usually do. 

[MifJpnAlphaPlus]

1 hour ago, Slice said:

Test, please

rEFIt_UEFI/Settings/ConfigPlist/Config_SystemParameters.h: line 78

    g.takeValueFrom(CustomUUID.value()); ->     g.takeValueFromBE(CustomUUID.value());

@Slice

Thank you for writing.
It just didn't work with smUUID.

I couldn't imagine where the meaningful smUUID data was going through the path. (Because it was not reflected in Hackintool even if it was swapped at the patching in the middle.)

Spoiler

But for CustomUUID, the takeValueFromBE method worked fine.

Spoiler

Thank you

 

[Guest 5T33Z0]

@Slice Great News! After changing that line in rEFIt_UEFI/Settings/ConfigPlist/Config_SystemParameters.h to "g.takeValueFromBE(CustomUUID.value());" and compiling Clover everything is back to normal again!

 

SMBIOS before updating Clover:

 

SMBIOS in Hackintool after update and reboot:

 

No more mismatch, no more Apple-ID authorization requests when switching Bootmanagers. I'm so happy that this is resolved now! Thank you very much! 😋

 

Crazy how two letters in a line of code can make a difference.

 

Edited May 7, 2022 by 5T33Z0

[Slice]

@LAbyOne

I tested gcc12 and came to conclusions:

1. Thanks for new warnings and errors. They must be eliminated. The error with UsbBus has origin from MdeModulePkg which is still wrong. Let OpenCore use it ahead.

2. Clover compiled by gcc12 is not working. Crash at "construct_globals_objects(gImageHandle);". Attention to @Jief_Machak. I am not able to correct this.

So I switch back to gcc11.

1 hour ago, MifJpnAlphaPlus said:

@Slice

Thank you for writing.
It just didn't work with smUUID.

I couldn't imagine where the meaningful smUUID data was going through the path. (Because it was not reflected in Hackintool even if it was swapped at the patching in the middle.)

  Reveal hidden contents

But for CustomUUID, the takeValueFromBE method worked fine.

  Reveal hidden contents

Thank you

 

Same here

SMBIOSPlist.h: line 674

      g.takeValueFromBE(SmUUID.value());

[Guest 5T33Z0]

@Slice I think I got excited too soon.

 

After testing I moved  the newly compiled files to the Internal EFI folder and then the the issue returned. When testing, I was booting the new version from the Flash Drive but via Bootloader chooser on the SSD. And the system's EFI folder still contained the current release version of Clover r5146. My bad. Clearly a mistake in testing on my end.

 

So now, after booting from Disk with the new compiled version, the error returns:

 

 

I guess for now, I just flip the pairs in Clover so that they come out correct.

 

 

Edited May 7, 2022 by 5T33Z0

[Slice]

45 minutes ago, 5T33Z0 said:

@Slice I think I got excited too soon.

 

After testing I moved  the newly compiled files to the Internal EFI folder and then the the issue returned. When testing, I was booting the new version from the Flash Drive but via Bootloader chooser on the SSD. And the system's EFI folder still contained the current release version of Clover r5146. My bad. Clearly a mistake in testing on my end.

 

So now, after booting from Disk with the new compiled version, the error returns:

 

 

I guess for now, I just flip the pairs in Clover so that they come out correct.

 

 

I committed my changes, be carefull to git pull to not have a conflict with the existing patches.

[Guest 5T33Z0]

I think that fixed it.