Jump to content

Clover Bug/Issue Report and Patch

Clover Issue Bug Report Patch

  • Please log in to reply
2735 replies to this topic

#2721
Zenith432

Zenith432

    InsanelyMac Legend

  • Developers
  • 770 posts
  • Gender:Male

@Zenith432
does clover have boot0xg now?
i saw your work
http://www.insanelym...d-for-chameleon
http://forge.voodoop...s/Bungo/CHANGES
Zenith432 : Replace boot0 with boot0xg. Now boot0xg has all features of previous boot0.

I don't know. I wrote boot0xg for Chameleon, and any import of it for Clover is not my work.
 

Why not commit to Patches_to_EDK2?

It was just temporary until edk2 fix it.
 

Full functional help command?
What about
Shell> edit config.plist
?

Didn't know about these things.

#2722
Slice

Slice

    InsanelyMac V.I.P.

  • Local Moderators
  • 6,624 posts
  • Gender:Male
  • Location:Moscow

Didn't know about these things.

     EDK2 (UEFI) Shell issues/bugs?    



#2723
Zenith432

Zenith432

    InsanelyMac Legend

  • Developers
  • 770 posts
  • Gender:Male

     EDK2 (UEFI) Shell issues/bugs?    

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.

#2724
RehabMan

RehabMan

    InsanelyMacaholic

  • Developers
  • 3,237 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

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.

#2725
Slice

Slice

    InsanelyMac V.I.P.

  • Local Moderators
  • 6,624 posts
  • Gender:Male
  • Location:Moscow

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.



#2726
RehabMan

RehabMan

    InsanelyMacaholic

  • Developers
  • 3,237 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

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.

#2727
Philip Petev

Philip Petev

    InsanelyMac Sage

  • Coders
  • 302 posts
  • Gender:Male
  • Location:Haskovo, Bulgaria

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.



#2728
Slice

Slice

    InsanelyMac V.I.P.

  • Local Moderators
  • 6,624 posts
  • Gender:Male
  • Location:Moscow

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.



#2729
Philip Petev

Philip Petev

    InsanelyMac Sage

  • Coders
  • 302 posts
  • Gender:Male
  • Location:Haskovo, Bulgaria

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".



#2730
Sherlocks

Sherlocks

    InsanelyMac Deity

  • Coders
  • 1,615 posts
  • Gender:Male
  • Location:Seoul

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에서 보냄

#2731
apianti

apianti

    I have dementia!

  • Developers
  • 584 posts
  • Gender:Not Telling

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!



#2732
Philip Petev

Philip Petev

    InsanelyMac Sage

  • Coders
  • 302 posts
  • Gender:Male
  • Location:Haskovo, Bulgaria

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.


  • nms likes this

#2733
apianti

apianti

    I have dementia!

  • Developers
  • 584 posts
  • Gender:Not Telling

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.



#2734
RehabMan

RehabMan

    InsanelyMacaholic

  • Developers
  • 3,237 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

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.
  • nms likes this

#2735
apianti

apianti

    I have dementia!

  • Developers
  • 584 posts
  • Gender:Not Telling

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.



#2736
RehabMan

RehabMan

    InsanelyMacaholic

  • Developers
  • 3,237 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

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).






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

© 2017 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy