chris1111 Posted October 7, 2020 Share Posted October 7, 2020 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? Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 7, 2020 Share Posted October 7, 2020 1 minute ago, chris1111 said: this is new? yes. 1 Link to comment Share on other sites More sharing options...
jsl2000 Posted October 7, 2020 Share Posted October 7, 2020 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. 1 1 Link to comment Share on other sites More sharing options...
naiclub Posted October 7, 2020 Share Posted October 7, 2020 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 Link to comment Share on other sites More sharing options...
D-an-W Posted October 7, 2020 Share Posted October 7, 2020 @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 Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 7, 2020 Share Posted October 7, 2020 3 minutes ago, D-an-W said: git clone https://github.com/CloverHackyColor/CloverBootloader.git "--recurse-submodules" = Yes Link to comment Share on other sites More sharing options...
D-an-W Posted October 7, 2020 Share Posted October 7, 2020 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 Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 7, 2020 Share Posted October 7, 2020 (edited) 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 1 1 Link to comment Share on other sites More sharing options...
D-an-W Posted October 7, 2020 Share Posted October 7, 2020 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' 1 Link to comment Share on other sites More sharing options...
Slice Posted October 7, 2020 Share Posted October 7, 2020 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. Link to comment Share on other sites More sharing options...
LAbyOne Posted October 7, 2020 Share Posted October 7, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
vector sigma Posted October 7, 2020 Share Posted October 7, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
LAbyOne Posted October 7, 2020 Share Posted October 7, 2020 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 Link to comment Share on other sites More sharing options...
tluck Posted October 7, 2020 Share Posted October 7, 2020 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 4 1 Link to comment Share on other sites More sharing options...
MacKonsti Posted October 7, 2020 Share Posted October 7, 2020 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 1 Link to comment Share on other sites More sharing options...
fusion71au Posted October 7, 2020 Share Posted October 7, 2020 (edited) 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 5 3 Link to comment Share on other sites More sharing options...
LockDown Posted October 8, 2020 Share Posted October 8, 2020 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. Link to comment Share on other sites More sharing options...
stevezheng Posted October 8, 2020 Share Posted October 8, 2020 (edited) 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 1 Link to comment Share on other sites More sharing options...
Slice Posted October 8, 2020 Share Posted October 8, 2020 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. 2 Link to comment Share on other sites More sharing options...
Slice Posted October 8, 2020 Share Posted October 8, 2020 Yes. it is. Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 8, 2020 Share Posted October 8, 2020 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... 2 6 Link to comment Share on other sites More sharing options...
stevezheng Posted October 8, 2020 Share Posted October 8, 2020 (edited) 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 1 Link to comment Share on other sites More sharing options...
1Revenger1 Posted October 8, 2020 Share Posted October 8, 2020 (edited) 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 2 Link to comment Share on other sites More sharing options...
stevezheng Posted October 8, 2020 Share Posted October 8, 2020 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. Link to comment Share on other sites More sharing options...
jsl2000 Posted October 9, 2020 Share Posted October 9, 2020 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. 1 Link to comment Share on other sites More sharing options...
Recommended Posts