Jump to content

Clover Problems and Solutions


ErmaC
3,206 posts in this topic

Recommended Posts

I didn't keep following that thread after my post about using vanilla shell successfully.

 

@Sherlocks:

I seem to remember something about bootx1alt (as opposed to boot0xg) that did have something to do with Clover. It is a variant of exfat boot code that allows to press a numeric key to choose which 2nd-stage boot file to load.

  • Like 1
Link to comment
Share on other sites

Each patch for EDK2 is related to some bug noticed by users.

The last one is corrected by rev 4331  #91 

The folder Patches_for_EDK2 exists because we can not correct EDK2 repository.

I use a modified tools_def.txt only (although that specific problem, I fixed the 'wrong' way first, and need to revisit and use tools_def.txt instead to change priority of S vs. nasm).

Also, I have a fork of edk2 with just a few changes.

It is easier to integrate upstream changes in edk2 with a fork, vs. copying a set of replacement files over top.

Just a matter of 'git pull'.

Yes... git is quite powerful and convenient.

  • Like 3
Link to comment
Share on other sites

Yes, it is a possible way. Other way is to stay with some UDK, for example UDK2017.

Are you sure your branch will be always compatible for merge with mainstream EDK2? I have an experience with Wine Sherry and I see time to time they became incompatible. It is a future of any branch if it will live own life.

Link to comment
Share on other sites

Yes, it is a possible way. Other way is to stay with some UDK, for example UDK2017.

Are you sure your branch will be always compatible for merge with mainstream EDK2? I have an experience with Wine <-> Sherry and I see time to time they became incompatible. It is a future of any branch if it will live own life.

I cannot predict the future, but git is pretty good at merging. And pretty good at identifying conflicts.

There are cases it can miss, but my changes are very minor, so it is rather unlikely.

A periodic 'diffmerge' between upstream edk2 and forked edk2 seems prudent, and is something I will do periodically.

Link to comment
Share on other sites

Yes, it is a possible way. Other way is to stay with some UDK, for example UDK2017n

 

@Slice @RehabMan I think the question you devs should ask yourself is do we really need the branch edk2 (the rolling release, constantly updated) or the branch udk2017 (the stable one, receiving only the critical updates from the edk2 branch from time to time) is quite enough in term of set of features it offers. We all know Clover uses only some of the toolkit modules and the rest are being updated more often in that rolling release according to my observations.

  • Like 1
Link to comment
Share on other sites

Agree, we don't need to keep EDK2 updating. But I think UDK2 is also to be patched for our purpose. In this case what is the difference what to use? In both cases we have to patch it.

Link to comment
Share on other sites

Agree, we don't need to keep EDK2 updating. But I think UDK2 is also to be patched for our purpose. In this case what is the difference what to use? In both cases we have to patch it.

The point was using a relatively static edk2 base instead rolling one, so its adaptation to be reduced to a minimum (maybe once a six months or something). Patching will be needed in any case, I know that, but as @RehabMan said, they are minimal and git can handle that pretty well. Just look at this diff:

diff -ur -x '.*' edk2/MdePkg/Include/Base.h rm_edk2/MdePkg/Include/Base.h
--- edk2/MdePkg/Include/Base.h	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Include/Base.h	2017-12-06 09:21:09.000000000 +0200
@@ -601,6 +601,27 @@
 **/
 #define _INT_SIZE_OF(n) ((sizeof (n) + sizeof (UINTN) - 1) &~(sizeof (UINTN) - 1))
 
+#define GCC_VERSION (__GNUC__ * 10 + __GNUC_MINOR__)
+
+/*
+ * clang defines __MACH__ if the target is OS X, but not if the target is Windows
+ */
+#if defined(__clang__) && !defined(__MACH__) && defined(__x86_64__)
+#define CLANG_VERSION (__clang_major__ * 0x100 + __clang_minor__)
+#ifdef __apple_build_version__      // Apple clang
+#if CLANG_VERSION >= 0x0703 && CLANG_VERSION < 0x0801
+// Use __builtin_ms_va_list if Apple clang ver >= 7.3.0 and < 8.1.0
+#define USE_CLANG_BUILTIN_MS_VA_LIST
+#endif
+#else   // Generic clang
+// Use __builtin_ms_va_list if Generic clang ver >= 3.7.0 and < 3.9.0
+#if CLANG_VERSION >= 0x0307 && CLANG_VERSION < 0x0309
+#define USE_CLANG_BUILTIN_MS_VA_LIST
+#endif
+#endif  // end Apple/Generic clang
+#undef CLANG_VERSION
+#endif  // end __clang__ && !__MACH__ && __x86_64__
+
 #if defined(__CC_ARM)
 //
 // RVCT ARM variable argument list support.
@@ -633,7 +654,8 @@
 
 #elif defined(__GNUC__)
 
-#if defined(MDE_CPU_X64) && !defined(NO_MSABI_VA_FUNCS)
+//#if defined(MDE_CPU_X64) && !defined(NO_MSABI_VA_FUNCS)
+#if defined(USE_CLANG_BUILTIN_MS_VA_LIST) || (defined(__x86_64__) && !defined(NO_MSABI_VA_FUNCS) && (GCC_VERSION >= 48))
 //
 // X64 only. Use MS ABI version of GCC built-in macros for variable argument lists.
 //
diff -ur -x '.*' edk2/MdePkg/Include/X64/ProcessorBind.h rm_edk2/MdePkg/Include/X64/ProcessorBind.h
--- edk2/MdePkg/Include/X64/ProcessorBind.h	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Include/X64/ProcessorBind.h	2017-12-06 09:21:09.000000000 +0200
@@ -27,7 +27,8 @@
 #pragma pack()
 #endif
 
-#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO)
+//#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO)
+#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO) && !defined(__clang__)
 //
 // Mark all symbol declarations and references as hidden, meaning they will
 // not be subject to symbol preemption. This allows the compiler to refer to
diff -ur -x '.*' edk2/MdePkg/Library/BaseLib/BaseLib.inf rm_edk2/MdePkg/Library/BaseLib/BaseLib.inf
--- edk2/MdePkg/Library/BaseLib/BaseLib.inf	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Library/BaseLib/BaseLib.inf	2017-12-06 09:21:09.000000000 +0200
@@ -755,7 +755,7 @@
   X86DisablePaging32.c
   X86RdRand.c
   X64/GccInline.c | GCC
-  X64/Thunk16.S | XCODE 
+#  X64/Thunk16.S | XCODE 
   X64/SwitchStack.nasm| GCC
   X64/SwitchStack.S | GCC 
   X64/SetJump.nasm| GCC
diff -ur -x '.*' edk2/MdePkg/Library/BaseLib/SafeString.c rm_edk2/MdePkg/Library/BaseLib/SafeString.c
--- edk2/MdePkg/Library/BaseLib/SafeString.c	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Library/BaseLib/SafeString.c	2017-12-06 09:21:10.000000000 +0200
@@ -14,9 +14,9 @@
 
 #include "BaseLibInternals.h"
 
-#define RSIZE_MAX  (PcdGet32 (PcdMaximumUnicodeStringLength))
-
-#define ASCII_RSIZE_MAX  (PcdGet32 (PcdMaximumAsciiStringLength))
+//REVIEW_REHABMAN: investigate why this is needed (PcdGet32 in this case not working correctly/build issue)
+#define RSIZE_MAX  0 //(PcdGet32 (PcdMaximumUnicodeStringLength))
+#define ASCII_RSIZE_MAX  0 //(PcdGet32 (PcdMaximumAsciiStringLength))
 
 #define SAFE_STRING_CONSTRAINT_CHECK(Expression, Status)  \
   do { \
diff -ur -x '.*' edk2/MdePkg/Library/BaseLib/String.c rm_edk2/MdePkg/Library/BaseLib/String.c
--- edk2/MdePkg/Library/BaseLib/String.c	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Library/BaseLib/String.c	2017-12-06 09:21:10.000000000 +0200
@@ -14,6 +14,12 @@
 
 #include "BaseLibInternals.h"
 
+//REVIEW_REHABMAN: investigate why this is needed (PcdGet32 in this case not working correctly/build issue)
+#undef _PCD_GET_MODE_32_PcdMaximumUnicodeStringLength
+#define _PCD_GET_MODE_32_PcdMaximumUnicodeStringLength 0
+#undef _PCD_GET_MODE_32_PcdMaximumAsciiStringLength
+#define _PCD_GET_MODE_32_PcdMaximumAsciiStringLength 0
+
 #ifndef DISABLE_NEW_DEPRECATED_INTERFACES
 
 /**

So, the keyword here is "git".

Link to comment
Share on other sites

I didn't keep following that thread after my post about using vanilla shell successfully.

 

@Sherlocks:

I seem to remember something about bootx1alt (as opposed to boot0xg) that did have something to do with Clover. It is a variant of exfat boot code that allows to press a numeric key to choose which 2nd-stage boot file to load.

Sorry Zenith432 for late reply.

I'm waited for report of user on sf.

Actually can't help his problem from r4331 commit.

What is difference of boot legacy both clover and chameleon?

Clover legacy supported old bios(hp probook bios(i don't know exactly), hp insyde bios, pheonix normal bios). This issue happens only phoenix securecore tiano. This bios shown in samsung sandy laptop, dell sandy laptop(i'm experienced this issue in l502x).

 

Always stop 6 or 7 message. Never get Clover GUI.

Chameleon can get verbose mode to use boot and option.

 

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites

The point was using a relatively static edk2 base instead rolling one, so its adaptation to be reduced to a minimum (maybe once a six months or something). Patching will be needed in any case, I know that, but as @RehabMan said, they are minimal and git can handle that pretty well. Just look at this diff:

diff -ur -x '.*' edk2/MdePkg/Include/Base.h rm_edk2/MdePkg/Include/Base.h
--- edk2/MdePkg/Include/Base.h	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Include/Base.h	2017-12-06 09:21:09.000000000 +0200
@@ -601,6 +601,27 @@
 **/
 #define _INT_SIZE_OF(n) ((sizeof (n) + sizeof (UINTN) - 1) &~(sizeof (UINTN) - 1))
 
+#define GCC_VERSION (__GNUC__ * 10 + __GNUC_MINOR__)
+
+/*
+ * clang defines __MACH__ if the target is OS X, but not if the target is Windows
+ */
+#if defined(__clang__) && !defined(__MACH__) && defined(__x86_64__)
+#define CLANG_VERSION (__clang_major__ * 0x100 + __clang_minor__)
+#ifdef __apple_build_version__      // Apple clang
+#if CLANG_VERSION >= 0x0703 && CLANG_VERSION < 0x0801
+// Use __builtin_ms_va_list if Apple clang ver >= 7.3.0 and < 8.1.0
+#define USE_CLANG_BUILTIN_MS_VA_LIST
+#endif
+#else   // Generic clang
+// Use __builtin_ms_va_list if Generic clang ver >= 3.7.0 and < 3.9.0
+#if CLANG_VERSION >= 0x0307 && CLANG_VERSION < 0x0309
+#define USE_CLANG_BUILTIN_MS_VA_LIST
+#endif
+#endif  // end Apple/Generic clang
+#undef CLANG_VERSION
+#endif  // end __clang__ && !__MACH__ && __x86_64__
+
 #if defined(__CC_ARM)
 //
 // RVCT ARM variable argument list support.
@@ -633,7 +654,8 @@
 
 #elif defined(__GNUC__)
 
-#if defined(MDE_CPU_X64) && !defined(NO_MSABI_VA_FUNCS)
+//#if defined(MDE_CPU_X64) && !defined(NO_MSABI_VA_FUNCS)
+#if defined(USE_CLANG_BUILTIN_MS_VA_LIST) || (defined(__x86_64__) && !defined(NO_MSABI_VA_FUNCS) && (GCC_VERSION >= 48))
 //
 // X64 only. Use MS ABI version of GCC built-in macros for variable argument lists.
 //
diff -ur -x '.*' edk2/MdePkg/Include/X64/ProcessorBind.h rm_edk2/MdePkg/Include/X64/ProcessorBind.h
--- edk2/MdePkg/Include/X64/ProcessorBind.h	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Include/X64/ProcessorBind.h	2017-12-06 09:21:09.000000000 +0200
@@ -27,7 +27,8 @@
 #pragma pack()
 #endif
 
-#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO)
+//#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO)
+#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO) && !defined(__clang__)
 //
 // Mark all symbol declarations and references as hidden, meaning they will
 // not be subject to symbol preemption. This allows the compiler to refer to
diff -ur -x '.*' edk2/MdePkg/Library/BaseLib/BaseLib.inf rm_edk2/MdePkg/Library/BaseLib/BaseLib.inf
--- edk2/MdePkg/Library/BaseLib/BaseLib.inf	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Library/BaseLib/BaseLib.inf	2017-12-06 09:21:09.000000000 +0200
@@ -755,7 +755,7 @@
   X86DisablePaging32.c
   X86RdRand.c
   X64/GccInline.c | GCC
-  X64/Thunk16.S | XCODE 
+#  X64/Thunk16.S | XCODE 
   X64/SwitchStack.nasm| GCC
   X64/SwitchStack.S | GCC 
   X64/SetJump.nasm| GCC
diff -ur -x '.*' edk2/MdePkg/Library/BaseLib/SafeString.c rm_edk2/MdePkg/Library/BaseLib/SafeString.c
--- edk2/MdePkg/Library/BaseLib/SafeString.c	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Library/BaseLib/SafeString.c	2017-12-06 09:21:10.000000000 +0200
@@ -14,9 +14,9 @@
 
 #include "BaseLibInternals.h"
 
-#define RSIZE_MAX  (PcdGet32 (PcdMaximumUnicodeStringLength))
-
-#define ASCII_RSIZE_MAX  (PcdGet32 (PcdMaximumAsciiStringLength))
+//REVIEW_REHABMAN: investigate why this is needed (PcdGet32 in this case not working correctly/build issue)
+#define RSIZE_MAX  0 //(PcdGet32 (PcdMaximumUnicodeStringLength))
+#define ASCII_RSIZE_MAX  0 //(PcdGet32 (PcdMaximumAsciiStringLength))
 
 #define SAFE_STRING_CONSTRAINT_CHECK(Expression, Status)  \
   do { \
diff -ur -x '.*' edk2/MdePkg/Library/BaseLib/String.c rm_edk2/MdePkg/Library/BaseLib/String.c
--- edk2/MdePkg/Library/BaseLib/String.c	2017-12-06 09:15:38.000000000 +0200
+++ rm_edk2/MdePkg/Library/BaseLib/String.c	2017-12-06 09:21:10.000000000 +0200
@@ -14,6 +14,12 @@
 
 #include "BaseLibInternals.h"
 
+//REVIEW_REHABMAN: investigate why this is needed (PcdGet32 in this case not working correctly/build issue)
+#undef _PCD_GET_MODE_32_PcdMaximumUnicodeStringLength
+#define _PCD_GET_MODE_32_PcdMaximumUnicodeStringLength 0
+#undef _PCD_GET_MODE_32_PcdMaximumAsciiStringLength
+#define _PCD_GET_MODE_32_PcdMaximumAsciiStringLength 0
+
 #ifndef DISABLE_NEW_DEPRECATED_INTERFACES
 
 /**

So, the keyword here is "git".

 

The problem is that patching the source with diff is not possible, because then the source would need to match exactly, which would mean even more maintenance. Currently clover copies entire sources over previous EDK2 sources to fix bugs, or remove unfavorable code. The reason why EDK2 is used instead of UDK2017 is because we would need to constantly update when a new UDK was released, which would be harder and bring many many many more difficult changes as they would be abrupt and large instead of gradual. EDK2 fixes bugs and adds features that may never be fixed in previous UDKs, also UDKs are for a specific firmware revision, EDK2 always advances. Not sure why the keyword is "git", git and subversion are practically the same thing, git just has more features.... Also the UDK is updated usually twice but at least once a month. So unsure where you think this six month period would come from, plus then if there was a problem there would be a bug for six months!

  • Like 2
Link to comment
Share on other sites

And yet, RehabMan's fork is pretty good example how all this maintenance can be done with minimum effort.

 

Not sure why the keyword is "git", git and subversion are practically the same thing, git just has more features....

 

Yes, they basically are, only that those "features" matter in the current case.

  • Like 1
Link to comment
Share on other sites

And yet, RehabMan's fork is pretty good example how all this maintenance can be done with minimum effort.

 

 

Yes, they basically are, only that those "features" matter in the current case.

 

Except that is a lot of effort to convert the current clover2 repo, etc. Not worth it. Would rather work on clover3 and get rid of EDK2 requirement... But yeah git, will be used in new repos.

Link to comment
Share on other sites

Except that is a lot of effort to convert the current clover2 repo, etc. Not worth it.

I already did it.

It was not difficult, although it took a bit of effort and correspondence with TheRacerMaster to come to a git svn base that was compatible with his already created fork.

 

Would rather work on clover3 and get rid of EDK2 requirement... But yeah git, will be used in new repos.

Looking forward to clover3 when you have something ready to work with.

Getting rid of EDK2 dependencies is likely a good thing.

And a complete rewrite would provide an opportunity to break with config.plist backward compatibility and simplify things a bit (eg. predictable defaults, consistent ways to inject things, consistent naming [eg. Nvidia vs. NVidia vs. NVidia], etc).

 

And yes, git would be a welcome change to svn, as git is much more appropriate for distributed development efforts.

  • Like 1
Link to comment
Share on other sites

I already did it.

It was not difficult, although it took a bit of effort and correspondence with TheRacerMaster to come to a git svn base that was compatible with his already created fork.

 

The main repository on sourceforge. And I meant more than zero amount of effort, lol.

 

Looking forward to clover3 when you have something ready to work with.

Getting rid of EDK2 dependencies is likely a good thing.

And a complete rewrite would provide an opportunity to break with config.plist backward compatibility and simplify things a bit (eg. predictable defaults, consistent ways to inject things, consistent naming [eg. Nvidia vs. NVidia vs. NVidia], etc).

 

I already have removed the EDK2 dependency and have quite a bit done towards a basic boot loader, but the only build system so far is Visual Studio (mainly because I use it to code most). It shouldn't be too hard to create other build systems for other OSes, I'll get on that eventually. The naming problem is now irrelevant, since there is no longer a static configuration, instead a case-insensitive tree navigated by the key path. The configuration can be used by any driver as well, and all those features will probably get broken down into smaller sets for drivers. It can be loaded from multiple plist files and written out to plist. I have an idea about providing schemas too for configuration defaults but there are also just some keys that will only ever be known at runtime.

 

And yes, git would be a welcome change to svn, as git is much more appropriate for distributed development efforts.

 

I favor git, as I think most people probably do, but I'm not going to change something just for that reason when it works perfectly fine. The real problem is that there's just too much projects slammed together into one place and it's too hard to determine what's working and why or not anymore. Just needs simplified and make the switch to git with v3, which is done already because I say so, lol.

Link to comment
Share on other sites

The main repository on sourceforge. And I meant more than zero amount of effort, lol.

It could be done easily (almost zero effort), since the 'svn' branch in my github is already _exactly_ what is needed.

It is there if someone wants to look into it.

For me it isn't a big deal, as I have already procedures that work for me.

The rest of the Clover team can decide what they want (which will probably be to stick with subversion).

  • Like 2
Link to comment
Share on other sites

A few bug fixes for AcpiPatcher.c

 

- fixed a bug with config.plist/ACPI/DSDT/Fixes/FixHeaders (NUL/0 characters should not have been translated to spaces)

 

- also fixed a minor problem where FixAsciiTableHeader was checking/fixing any char >0x7e, but CheckNonAscii was checking only >0x7f (off by one)

 

- fixed problems with AutoMerge=true when table headers needed fixing (header fixing was causing problems with table id comparisons)... note that the above bug (where table headers were unnecessarily being modified), exposed this bug a bit easier/more often.

 

- fixed a bug when AutoMerge=true and SortedOrder specified would cause a merged table to be also treated as an add-on SSDT. (Note: SortedOrder is not needed when using AutoMerge=true, but it should not result in duplicate table insertion)

 

Two main commits:

https://github.com/RehabMan/Clover/commit/e05eaa0a52f5f974863f600ab6d90e4fd66396cc

https://github.com/RehabMan/Clover/commit/aeeca14d7de008cbcb3fc89727673aa10614895d

 

Best just to grab the new AcpiPatcher.c:

https://github.com/RehabMan/Clover/raw/master/rEFIt_UEFI/Platform/AcpiPatcher.c

  • Like 5
Link to comment
Share on other sites

There is a problem with the Clover package. In very rare cases (mostly using a third-party custom-made package after the official one and vice versa), when the CloverThemeManager is already installed in /Applications, selecting that app for installation causes merging of the two apps that makes the resulted one inoperable.

 

According to some sources, incl. the guys at the installer-dev mailing list, installing an app directly over the already installed one, using such package, is generally not recommended for several reasons (leftovers from the old one that may affect the operation of the new one, wrong permissions of those leftovers etc.), unless the package contains a patcher for that app and not actually the newer version of it.

 

The attached file contains a patch for buildpkg.sh and a folder, named CloverThemeManager, that should be copied to Clover/CloverPackage/package/Script.templates. The folder contains a preinstall script for the CloverThemeManager subpackage that removes the currently installed app (if found) before installing the payload of the package.

CloverThemeManager_pkgfix.zip

  • Like 8
Link to comment
Share on other sites

Philip, do you want to maintain the package? Because no one is currently doing that and it's starting to get out of sync with the build. I can add you to the project on sf.net, just PM me your user name and I'll add you. Then you can maintain away my friend.

  • Like 1
Link to comment
Share on other sites

Philip, do you want to maintain the package? Because no one is currently doing that and it's starting to get out of sync with the build. I can add you to the project on sf.net, just PM me your user name and I'll add you. Then you can maintain away my friend.

Sure, why not... You've got a PM.

Link to comment
Share on other sites

Sure, why not... You've got a PM.

 

Ok, you are now the maintainer of the package. There may be some open tickets referencing the installer, you should look through. Also if you felt inclined you could simplify the installer, maybe have an extra dialog page that chooses between UEFI and legacy and explains a little detail, or something IDK. lol

 

EDIT: Here are three open tickets relating to the package, they shouldn't be too hard (they may already be fixed, lol):

 

#400 Installer: include Usb{Kb,Mouse}Dxe-64.efi for UEFI-only installs?

#48 Clover installation on RAID 0 fails

#37 Installer does not work on fusion drive

 

#37 and #48 appear to be the same sort of issue.

  • Like 4
Link to comment
Share on other sites

Can anyone tell me if exfat volumes can be hidden or used in custom entries like they should be able to? I'd like to close this ticket but I can't remember if it works now or not.

What kind of OS are you going to boot from exFAT?

For me the ticket should be closed as won't-fix.

Link to comment
Share on other sites

What kind of OS are you going to boot from exFAT?

For me the ticket should be closed as won't-fix.

 

Ah sorry, my question was misleading. It can be hidden when using the grub exfat EFI driver. It has to do with legacy partitions, so you can most certainly boot linux or windows from an exfat. It appears that exfat is not detected correctly so it can't be hidden or booted. I'm pretty sure this should be fixed, the PBR for exfat is different than fat.

Link to comment
Share on other sites

  • 3 weeks later...

I didn't understand do we need slide=0 with new AptioFix?

Clover add it!

    if (gDriversFlags.AptioFixLoaded &&
        !DoHibernateWake &&
        !StrStr(Entry->LoadOptions, L"slide=")) {
      // Add slide=0 argument for ML+ if not present
      CHAR16 *TempOptions = AddLoadOption(Entry->LoadOptions, L"slide=0");
      FreePool(Entry->LoadOptions);
      Entry->LoadOptions = TempOptions;
    }

  • Like 1
Link to comment
Share on other sites

I didn't understand do we need slide=0 with new AptioFix?

Clover add it!

    if (gDriversFlags.AptioFixLoaded &&
        !DoHibernateWake &&
        !StrStr(Entry->LoadOptions, L"slide=")) {
      // Add slide=0 argument for ML+ if not present
      CHAR16 *TempOptions = AddLoadOption(Entry->LoadOptions, L"slide=0");
      FreePool(Entry->LoadOptions);
      Entry->LoadOptions = TempOptions;
    }

You don't need "slide=0", AFM just detects convenient ones to make failed boots more unlikely
Link to comment
Share on other sites

×
×
  • Create New...