Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

zxv
zxv
Posted
Posted

This problem (NULL in XSDT causing add-on SSDTs to be patched by ACPI/Patches) should be fixed by the Clover I just uploaded to bitbucket:

https://bitbucket.org/RehabMan/clover/downloads/

 

Will work on submitting the change to mainline Clover.

Good to know. Thank you for your work.

 

While it was easy enough in my case to route around the issue by renaming add-on SSDT devices to their pre-patch names, one could easily see this sort of thing inducing headaches for users down the road.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

 

I do not know which revision was broken, but I just tested r4330

boot ESP CloverEFI 64-bits SATA Boot0af

The boot still hang on   6_

r4324 all good  ^_^

 

It depends on EDK2 revision and on chosen toolset. New EDK2 with XCODE5 tooset leads to this hang.

Looks like 25687 is first wrong revision.

Link to comment
Share on other sites
nms
nms
Posted
Posted

It depends on EDK2 revision and on chosen toolset. New EDK2 with XCODE5 tooset leads to this hang.

Looks like 25687 is first wrong revision.

This short patch

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/BaseLib.inf
index 320ac457..b772f82b 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -755,7 +755,6 @@
   X86DisablePaging32.c
   X86RdRand.c
   X64/GccInline.c | GCC
-  X64/Thunk16.S | XCODE
   X64/SwitchStack.nasm| GCC
   X64/SwitchStack.S | GCC
   X64/SetJump.nasm| GCC

will switch XCODE5 compilation from Thunk16.S to Thunk16.nasm in edk2 BaseLib and solve the hang at '6'. I have no idea what wrong with Thunk16.S (and/or xcode9.1) yet )-;

  • Like 3
Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted

Thanks @Slice, Legacy Clover r4330 works just fine on my 2nd Gen mach  :) (XCode8.2 | EDK2 r25764):

2:694  0:000  Now is 1.12.2017,  14:45:57 (GMT)
2:694  0:000  Starting Clover revision: 4330 on CLOVER EFI
2:694  0:000  Build with: [Args: -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8 | -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 5 | OS: 10.11.6 | XCODE: 8.2]
......   .....  ...
377:019  0:000  Loading boot.efi  status=Success
377:467  0:448  GetOSVersion: 10.11.6 (15G18013)
1) Update Build_Clover script v4.5.8
2) update Clover + force edk2 update (no building)
5) build existing revision for release (no update, standard build).

bootlog.log.txt_A43SJ_r4330_XCode8.2.zip

Link to comment
Share on other sites
Funky frank
Funky frank
Posted
Posted

Safe.

Anyway you should always be able to revert to working soultion.

 

 

Thanks. One last question, since I have no experience with EFI partition. If I want to update clover on an EFI partition, I simply do that thru the installer's options, or do I have to mount that EFI partition first manually?

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Thanks. One last question, since I have no experience with EFI partition. If I want to update clover on an EFI partition, I simply do that thru the installer's options, or do I have to mount that EFI partition first manually?

If installer then umount the ESP.

If manually copy then mount it.

diskutil mount disk0s1

This short patch

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/BaseLib.inf
index 320ac457..b772f82b 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -755,7 +755,6 @@
   X86DisablePaging32.c
   X86RdRand.c
   X64/GccInline.c | GCC
-  X64/Thunk16.S | XCODE
   X64/SwitchStack.nasm| GCC
   X64/SwitchStack.S | GCC
   X64/SetJump.nasm| GCC

will switch XCODE5 compilation from Thunk16.S to Thunk16.nasm in edk2 BaseLib and solve the hang at '6'. I have no idea what wrong with Thunk16.S (and/or xcode9.1) yet )-;

I confirm, this patch helps!

  • Like 2
Link to comment
Share on other sites
nms
nms
Posted
Posted

As I understand homegrown XCODE8 toolchain gives priority to .nasm versions of files? If so, then this

--- tools_def.txt.orig	2017-12-01 22:52:31.000000000 +0300
+++ tools_def.txt	2017-12-01 22:53:10.000000000 +0300
@@ -7408,7 +7408,7 @@

 *_XCODE5_*_*_FAMILY            = GCC
 *_XCODE5_*_*_BUILDRULEFAMILY   = XCODE
-*_XCODE5_*_*_BUILDRULEORDER    = S s nasm

 #
 # use xcode-select to change Xcode version of command line tools

will align XCODE5 to XCODE8. Patch for BaseLib .inf file can/should be reverted.

  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

@nms: I think I used BUILDRULEORDER='nasm S s' for XCODE8 intentionally to make it like GCC49/GCC53.

What you suggest would align XCODE5 to the default BUILDRULEORDER 'nasm asm Asm ASM S s', which would work too :)

 

Edit: Actually, the default BUILDRULEORDER may not work for Xcode because asm and Asm are masm variants may get chosen over S variant.

 

Edit: There was something about Apple EFI lead engineer wanting to use clang -cc1as for all assembly and not use nasm is the reason that the xcode toolchains in EDK2 sample tools_def use BUILDRULEORDER 'S s nasm'.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Edit: There was something about Apple EFI lead engineer wanting to use clang -cc1as for all assembly and not use nasm is the reason that the xcode toolchains in EDK2 sample tools_def use BUILDRULEORDER 'S s nasm'.

His hame is Andrew Fish.

The reason is S files compiled by clang can be optimised by clang linker (dead code elimination). While nasm compilation will not be optimised.

That is why XCODE5 compilation is smaller then XCODE8.

I just don't know if we want this optimisation.

  • Like 1
Link to comment
Share on other sites
nms
nms
Posted
Posted

His hame is Andrew Fish.

The reason is S files compiled by clang can be optimised by clang linker (dead code elimination). While nasm compilation will not be optimised.

That is why XCODE5 compilation is smaller then XCODE8.

I just don't know if we want this optimisation.

Well,

recent changes in nasm itself introduced such features for macho.

@nms: I think I used BUILDRULEORDER='nasm S s' for XCODE8 intentionally to make it like GCC49/GCC53.

What you suggest would align XCODE5 to the default BUILDRULEORDER 'nasm asm Asm ASM S s', which would work too :)

 

Edit: Actually, the default BUILDRULEORDER may not work for Xcode because asm and Asm are masm variants may get chosen over S variant.

 

Edit: There was something about Apple EFI lead engineer wanting to use clang -cc1as for all assembly and not use nasm is the reason that the xcode toolchains in EDK2 sample tools_def use BUILDRULEORDER 'S s nasm'.

In this particular topic it would better to discuss Clover useless source code base I guess. (-;

IMHO, .nasm variants in edk2 supported better. Is there a reason to keep .S variants in Clover repository?

I see nothing wrong with .nasm for decent VisualStudio toolchain (vs2017).

  • Like 1
Link to comment
Share on other sites
oswaldini
oswaldini
Posted
Posted

Clover rev 4318 with OsxAptioFix2

Asus Prime Z370-A

RAM 4x16GB 3000 MHz (64GB)

 

Clover sees the entire RAM but macOS 10.13.1 sees only 2 of 4 banks (32GB), I need to manually fix it in smbios section.

3:798  0:000  === [ ScanSPD ] ===========================================
3:799  0:000  SMBus device : 8086 A2A3 class=0C0500 status=Success
3:799  0:000  SMBus CmdReg: 0x3
3:799  0:000  Scanning SMBus [8086:A2A3], mmio: 0xDFF4A004, ioport: 0xF000, hostc: 0x11
3:799  0:000  Slots to scan [8]...
3:799  0:000  SPD[0]: Got invalid type 0 @0x50. Will set page and retry.
3:800  0:000  SPD[0]: Type 12 @0x50
3:818  0:018  XMP Profile1: 6*125 -83 ns
3:818  0:000  Found module with XMP version 2.0
3:818  0:000  Using XMP Profile1 instead of standard frequency 2132MHz
3:818  0:000  DDR speed 2998MHz
3:818  0:000  Slot: 0 Type 26 16384MB 2998MHz Vendor=Corsair PartNo=CMK32GX4M2B3000C15 SerialNo=0000000000000000
3:819  0:000  SPD[1]: Type 12 @0x51
3:837  0:018  XMP Profile1: 6*125 -83 ns
3:837  0:000  Found module with XMP version 2.0
3:837  0:000  Using XMP Profile1 instead of standard frequency 2132MHz
3:837  0:000  DDR speed 2998MHz
3:837  0:000  Slot: 1 Type 26 16384MB 2998MHz Vendor=Corsair PartNo=CMK32GX4M2B3000C15 SerialNo=0000000000000000
3:837  0:000  SPD[2]: Type 12 @0x52
3:856  0:018  XMP Profile1: 6*125 -83 ns
3:856  0:000  Found module with XMP version 2.0
3:856  0:000  Using XMP Profile1 instead of standard frequency 2132MHz
3:856  0:000  DDR speed 2998MHz
3:856  0:000  Slot: 2 Type 26 16384MB 2998MHz Vendor=Corsair PartNo=CMK32GX4M2B3000C15 SerialNo=0000000000000000
3:856  0:000  SPD[3]: Type 12 @0x53
3:874  0:018  XMP Profile1: 6*125 -83 ns
3:874  0:000  Found module with XMP version 2.0
3:874  0:000  Using XMP Profile1 instead of standard frequency 2132MHz
3:874  0:000  DDR speed 2998MHz
3:874  0:000  Slot: 3 Type 26 16384MB 2998MHz Vendor=Corsair PartNo=CMK32GX4M2B3000C15 SerialNo=0000000000000000
Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

Some recent GenSec changes in EDK2 break the build of BaseTools with XCODE5. If you already have built BaseTools you won't run into this issue (would've posted this in the other thread but I don't have permission).

GenSec.c:1354:21: error: passing 'UINT8 *' (aka 'unsigned char *') to parameter of type 'const char *' converts between pointers to integer types with different sign [-Werror,-Wpointer-sign]
        if (stricmp(DummyFileBuffer, InFileBuffer + (InFileSize - DummyFileSize)) == 0){
                    ^~~~~~~~~~~~~~~
/usr/include/strings.h:78:29: note: passing argument to parameter here
int      strcasecmp(const char *, const char *);
                                ^
GenSec.c:1354:38: error: passing 'UINT8 *' (aka 'unsigned char *') to parameter of type 'const char *' converts between pointers to integer types with different sign [-Werror,-Wpointer-sign]
        if (stricmp(DummyFileBuffer, InFileBuffer + (InFileSize - DummyFileSize)) == 0){
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/strings.h:78:43: note: passing argument to parameter here
int      strcasecmp(const char *, const char *);
                                              ^
GenSec.c:1329:16: error: implicit conversion from 'unsigned long long' to 'int' changes value from 9223372036854775829 to 21 [-Werror,-Wconstant-conversion]
        return EFI_ABORTED;
        ~~~~~~ ^~~~~~~~~~~
../Include/Common/UefiBaseTypes.h:119:35: note: expanded from macro 'EFI_ABORTED'
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...