Clover General discussion

[chris1111]

4 minutes ago, Jief_Machak said:

Did you think of --recurse-submodules in your git clone ?

No what is this ? Never need this before, this is new?

[Jief_Machak]

1 minute ago, chris1111 said:

this is new?

yes.

[jsl2000]

14 hours ago, Jief_Machak said:

I think I found the bug. Could you try this : CloverX64-2020-10-04 00:06:31 +0300-Clover revision: 5123-jief-0710.1.zip. If it's working, I'll commit it.

If it doesn't work, send me your debug.log (please scratch it before to avoid having multiple boot in it).

According to my recent test this new version is stable, reliable, and faster to boot to desktop than previous version.

[naiclub]

27 minutes ago, jsl2000 said:

According to my recent test this new version is stable, reliable, and faster to boot to desktop than previous version.

 

 

Congratulations with you

[D-an-W]

@Jief_Machak I use a script someone made a while ago (Forget who sorry!), should I now edit it to include "--recurse-submodules" please?

 

#!/bin/bash

if [[ ! -d "$HOME"/src/CloverBootloader ]]; then
  mkdir -p "$HOME"/src
  cd "$HOME"/src
  git clone https://github.com/CloverHackyColor/CloverBootloader.git
fi

"$HOME"/src/CloverBootloader/buildme

 

[Jief_Machak]

3 minutes ago, D-an-W said:

git clone https://github.com/CloverHackyColor/CloverBootloader.git

"--recurse-submodules" = Yes

[D-an-W]

1 minute ago, Jief_Machak said:

"--recurse-submodules" = Yes

 

Hmmm, I tried...

#!/bin/bash

if [[ ! -d "$HOME"/src/CloverBootloader ]]; then
  mkdir -p "$HOME"/src
  cd "$HOME"/src
  git clone https://github.com/CloverHackyColor/CloverBootloader.git --recurse-submodules
fi

"$HOME"/src/CloverBootloader/buildme

 

[Jief_Machak]

I think it's "git clone --recurse-submodules https://github.com/CloverHackyColor/CloverBootloader.git"

 

Traditionally, in unix command line, options goes before the actual arguments. 

 

Here "clone" being a command and not an argument.

Edited October 7, 2020 by Jief_Machak

[D-an-W]

Ok thanks, it did do something different from last time.

 

It's running at the moment so will see what mess I made once it completes...

 

Spoiler

Cloning into 'CloverBootloader'...

remote: Enumerating objects: 8, done.

remote: Counting objects: 100% (8/8), done.

remote: Compressing objects: 100% (8/8), done.

remote: Total 79173 (delta 0), reused 1 (delta 0), pack-reused 79165

Receiving objects: 100% (79173/79173), 157.35 MiB | 7.96 MiB/s, done.

Resolving deltas: 100% (54581/54581), done.

Updating files: 100% (9696/9696), done.

Submodule 'OpenCorePkg' (https://github.com/CloverHackyColor/OpenCorePkg.git) registered for path 'OpenCorePkg'

Cloning into '/Users/dan/src/CloverBootloader/OpenCorePkg'...

remote: Enumerating objects: 15, done.        

remote: Counting objects: 100% (15/15), done.        

remote: Compressing objects: 100% (11/11), done.        

remote: Total 23432 (delta 4), reused 10 (delta 4), pack-reused 23417        

Receiving objects: 100% (23432/23432), 95.24 MiB | 7.85 MiB/s, done.

Resolving deltas: 100% (16896/16896), done.

Submodule path 'OpenCorePkg': checked out 'a638b1bdf8f0656e3e4264159d9efa245d344dd2'

 

[Slice]

7 hours ago, LAbyOne said:

@Slice

being testing this for a while now  

not sure really needed, but updated file

to latest stable version 2.15.05

... just in case

buildnasm.sh.zip

May be source link should be replaced?

On July 1, 2020, the official NASM git repository moved to github.
The previous repository on repo.or.cz is no longer maintained.

 

[LAbyOne]

47 minutes ago, Slice said:

May be source link should be replaced?

On July 1, 2020, the official NASM git repository moved to github.
The previous repository on repo.or.cz is no longer maintained.

 

yeah, i noticed that, but the one I used is from another source very stable and reliable constantly up to date..

its actually the one already in use since a little while now.

Edited October 7, 2020 by LAbyOne

[vector sigma]

available at same place, as always: https://ftp.osuosl.org/pub/blfs/conglomeration/nasm/

changing:

export NASM_VERSION=${NASM_VERSION:-2.14.02}

to:

export NASM_VERSION=${NASM_VERSION:-2.15.05}

should be enough (buildnasm.sh) 

Edited October 7, 2020 by vector sigma

[LAbyOne]

7 minutes ago, vector sigma said:

available at same place, as always: https://ftp.osuosl.org/pub/blfs/conglomeration/nasm/

changing:

export NASM_VERSION=${NASM_VERSION:-2.14.02}

to:

export NASM_VERSION=${NASM_VERSION:-2.15.05}

should be enough (buildnasm.sh) 

all changes are already done... file is attached to my post...  just replace in source

[tluck]

FYI ... 5123 - all good for me.

booted Catalina, Mojave, HighSierra, Sierra

config etc from the OEM folder - no duplicate ACPI files needed.

Starting Clover revision: 5123 (master, commit 941ff0b3a) on Lenovo EFI

[MacKonsti]

Good evening everyone, again thanks @Jief_Machak for assisting me with that parsing bug for TgtBridge key; I have a question for Clover amidst all this frenzy with everyone trying to install Big Sur  especially now that @tluck confirmed previous macOS boot well (I am trying to avoid the rush and keep a fully near-perfect working system despite using older OS).

 

Indeed, as discussed, without much Clover deeper knowledge going around and having only @Slice updating the other thread with Clover updates, please can anyone explain briefly a couple of things?

• On the release Git, I read for r5123 that now we get "a joint project Clover+OpenCore (https://github.com/acidanthera/OpenCorePkg) so that starts as Clover with Clover GUI and settings and then loads OC to start chosen OS with delegated rights to load and patch kexts." As I don't really fully understand the statement (and done because of Big Sur, I guess) what does this mean? Hybrid bootloader? Boot in 2 stages like Clover does half and under-the-hood OpenCore does the remaining half? Or just using OpenCore techniques to replace slowly older Clover components/code?

• Which build is the real, last original "mentality" of Clover? Is it safe to assume the one before the introduction of OcQuirks.efi ?

• As the sample-config.plist grows larger and larger with each bunch of releases (and with lack of documentation to check, makes me worried on what on earth does what) what is the "default" hardware that the packaged sample-config refers to? Latest generation of platforms like e.g. higher-end Z3xx platform that most people appear to have? Or just a list/dump of ALL possible options?

Thank you!

 

A kind request, please do refrain from polluting this already long thread with personal exchanges and "bickering" at times, we are many more users that need valuable info while browsing many pages and we do have the intelligence to see who is what, in terms of character or attitude 

[fusion71au]

On 10/4/2020 at 12:48 AM, rramon said:

Could someone please post a precise and understandable step-by-step-guide on what needs to be done to get Clover working with Big Sur?

 

The stuff posted on the last couple of pages isn’t comprehensive at least not for me.

 

Thanks.

 

1.  Upgrade Clover to r5123_8e0f4ad24 or later

2.  Copy Quirks section from config-sample.plist to your previous working Clover config.plist with plist editor eg XCODE...

 

Spoiler

 

3.  Make sure you supply "full name" of any kext you want to patch in Clover's config.plist/KernelAndKextPatches/KextsToPatch eg com.apple.driver.AppleAHCIPort instead of just AppleAHCIPort for ALPM IO Error AppleAHCIPort patch.

4.  Add OcQuirks.efi and OpenRuntime.efi to /EFI/CLOVER/drivers/UEFI or /EFI/CLOVER/drivers/BIOS.  Remove old AptioMemoryFix drivers.

5.  Kexts should be in /EFI/CLOVER/kexts/Other &/or /EFI/CLOVER/kexts/10.x and /EFI/CLOVER/kexts/11.  Some Kozlek/Rehabman FakeSMC plugins can cause KP.  Personally, I use @Slice's FakeSMC.

6.  Fine tune Quirks - References: Dortania OC guide and more detailed OC 0.6.1 configuration.pdf, esp sections on Booter/Quirks, Kernel/Quirks properties.

 

Good Luck!

 

 

10 hours ago, ellaosx said:

So it works for Legacy too? I thought its already builtin somewhere in boot file.

Yes, works for my Legacy as well as UEFI systems.  For Legacy BIOS, it still boots whether or not OcQuirks.efi and OpenRuntime.efi is in /EFI/CLOVER/drivers/BIOS .

 

 

Edited October 8, 2020 by fusion71au
OC Drivers optional for Legacy BIOS systems

[LockDown]

1 hour ago, fusion71au said:

4.  Add OcQuirks.efi and OpenRuntime.efi to /EFI/CLOVER/drivers/UEFI or /EFI/CLOVER/drivers/BIOS.

So it works for Legacy too? I thought its already builtin somewhere in boot file.

[stevezheng]

Thank you all for the great work.

I have some suggestions about cleaning the config-sample.plist.

 

- KernelPm and AppleCpuPmCfgLock seems do the same thing. Maybe one of them should be removed?

- Same situation with KernelXCPM and AppleXcpmCfgLock, they all deal with CFG lock on XCPM.

- KernelLapic and LapicKernelPanic are also the same thing probably?

- There are two PanicNoKextDump in config-sample.plist (https://github.com/CloverHackyColor/CloverBootloader/blob/master/CloverPackage/CloverV2/EFI/CLOVER/config-sample.plist)

 

Please correct me if I am wrong. I haven't looked into the new OpenCore integration code yet. Appreciate all the efforts so far.

 

 

Edited October 8, 2020 by stevezheng

[Slice]

1 hour ago, 5T33Z0 said:

 

I've made the switch to OC quirks in 5122 already so I know how it is set up. But in 5123 you have to actually delete OCquirks.plist after copying the entries into the clover config. But the more important issue is:

 

in OpenCore kext are loaded in memory based on their positionin the config so kexts that depend on other kext load later. Thats why you always find lilu and everything else thats neded by other kexts at the top of the list. BUT clover doesnt do that if that particular kest is not hardcoded in. This can lead to conflicts like kexts not working or KPs. And I think that's real design flaw when trying to incorporate OC into clover. So updateing becomes a gamble at this stage.

Is this a theory or you can show facts? 

Clover already loads Lilu in the first place.

[Slice]

Yes. it is.

[Jief_Machak]

4 hours ago, 5T33Z0 said:

I think that's real design flaw

You sound like an OpenCore team member ! 

 

It's not a design, it's a quick and dirty hack made at the beginning, when I didn't even know if I could call OC code like that.

I never said it was finished.

pfff...

[stevezheng]

6 hours ago, Slice said:

Is this a theory or you can show facts? 

Clover already loads Lilu in the first place.

As far as I know, it doesn't affect too much in most cases with lack of kext boot list, but the kext load order is important for VoodooI2C and its plugins.

 

VoodooI2C has three plugins: VoodooGPIO.kext, VoodooI2CServices.kext, and VoodooInput.kext. The correct boot order should be VoodooI2CServices.kext > VoodooGPIO.kext > VoodooI2C.kext > VoodooInput.kext (earliest to load to last to load).

 

For VoodooI2C satellites (VoodooI2CHID/VoodooI2CELAN/VoodooI2CFTE/VoodooI2CSynaptics/VoodooI2CAtmelMXT), they should be loaded between VoodooI2C and VoodooInput.

 

Maybe hardcode VoodooI2C family kexts into main.cpp as well?

Edited October 8, 2020 by stevezheng

[1Revenger1]

Hardcoding even more things sounds like a really bad time - because any time new kexts are created (Such as VoodooRMI) which have a non-trivial dependency order, they have to be added and would require the user the update their boot loader. There are ways to automatically order them - ProperTree (a plist editor), is able to figure this out. So it's really best I think to come up with an algorithm for this rather than hardcode. @stevezheng

This (using an algorithm to figure out boot order) likely was the plan I think based off of prior conversation.

Edited October 8, 2020 by 1Revenger1

[stevezheng]

1 minute ago, 1Revenger1 said:

Hardcoding even more things sounds like a really bad time - because any time new kexts are created (Such as VoodooRMI) which have a non-trivial dependency order, they have to be added and would require the user the update their boot loader. There are ways to automatically order them - ProperTree (a plist editor), is able to figure this out. So it's really best I think to come up with an algorithm for this rather than hardcode. @stevezheng

This likely was the plan I think based off of prior conversation.

Agree. But it needs extra work for the team to read kext list from xml, and it might be a challenge for newbies that don't understand how it works. The decision is up to Clover team.

[jsl2000]

8 hours ago, Jief_Machak said:

You sound like an OpenCore team member ! 

 

It's not a design, it's a quick and dirty hack made at the beginning, when I didn't even know if I could call OC code like that.

I never said it was finished.

pfff...

Hi, Jief_Machak

Any progress of AMD hackintoshs booted by new Clover integration with OC ?

I always got instant reboot with current 5123 version even kernel patches were properly applied in KernelToPatch.