Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

zxv
zxv
Posted
Posted

Better Skylake ARTFrequency handling:

 

Clover currently seems unable to calculate the ARTƒ (Always Running Timer) with sufficient precision, thereby inducing dysfunction in system aspects which otherwise depend on its accuracy. Distorted audio playback is one such symptom.

 

In OS X, when a preexisting value for ARTFreq is unavailable, the timer's default clockspeed (24MHz) is arbitrarily assigned with no attempt made at realtime calculation. See here: http://www.opensource.apple.com/source/xnu/xnu-3248.20.55/osfmk/i386/tsc.c

 

This seems the saner approach, given that ARTFreq is something that should be determined via firmware/etc. very early in the startup process where risk for measurement error is least, i.e. well before any boot environment takes hold.

 

Example patch here: https://github.com/theracermaster/Clover/compare/master...mfckr:master

 

(Been testing this the last few days and have experienced none of the earlier ARTFreq related issues; additionally, it seems to considerably enhance overall system responsiveness).

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

Better Skylake ARTFrequency handling:

 

Clover currently seems unable to calculate the ARTƒ (Always Running Timer) with sufficient precision, thereby inducing dysfunction in system aspects which otherwise depend on its accuracy. Distorted audio playback is one such symptom.

 

In OS X, when a preexisting value for ARTFreq is unavailable, the timer's default clockspeed (24MHz) is arbitrarily assigned with no attempt made at realtime calculation. See here: http://www.opensource.apple.com/source/xnu/xnu-3248.20.55/osfmk/i386/tsc.c

 

This seems the saner approach, given that ARTFreq is something that should be determined via firmware/etc. very early in the startup process where risk for measurement error is least, i.e. well before any boot environment takes hold.

 

Example patch here: https://github.com/theracermaster/Clover/compare/master...mfckr:master

 

(Been testing this the last few days and have experienced none of the earlier ARTFreq related issues; additionally, it seems to considerably enhance overall system responsiveness).

Already done

	<key>CPU</key>
	<dict>
		<key>UseARTFrequency</key>
		<false/>
Link to comment
Share on other sites
cecekpawon
cecekpawon
Posted
Posted (edited)

Still, IndentationError. Please compare

Running edk2 build for CloverX64 using the command:
build  -D USE_LOW_EBDA -p Clover/Clover.dsc  -a X64 -b RELEASE -t GCC49 -n 5 

Traceback (most recent call last):
  File "/Users/x/src/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 41, in <module>
    from AutoGen.AutoGen import *
  File "/Users/x/src/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line 22, in <module>
    import GenC
  File "/Users/x/src/edk2/BaseTools/Source/Python/AutoGen/GenC.py", line 1170
    if DatumType == 'VOID*':
                           ^
IndentationError: unindent does not match any outer indentation level

Done!
Edited by cecekpawon
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

 

Still, IndentationError. Please compare

Running edk2 build for CloverX64 using the command:
build  -D USE_LOW_EBDA -p Clover/Clover.dsc  -a X64 -b RELEASE -t GCC49 -n 5 

Traceback (most recent call last):
  File "/Users/x/src/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 41, in <module>
    from AutoGen.AutoGen import *
  File "/Users/x/src/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line 22, in <module>
    import GenC
  File "/Users/x/src/edk2/BaseTools/Source/Python/AutoGen/GenC.py", line 1170
    if DatumType == 'VOID*':
                           ^
IndentationError: unindent does not match any outer indentation level

Done!

I tested vanilla GenC.py & AutoGen.py and they works. It seems EDK2 developers corrected the error  at last.

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

I build r3385 with gcc 4.9 ... everything ok

 

I build r3385 with gcc 5.3 (earlier tried gcc 5.2 as well) and it fails.  The code for boot6 comes to size > 0x6A000 which is more than allowed for low-ebda (0x68000).  When I use --std-ebda, it works at the expense of another 32K in size.

 

Anyone know why gcc 5.3 causes code bloat?  Is it an optimisation option that needs changing?

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

The -Os did the job.  Not quite sure how changing the ABI to ms from sysv wouldn't break it unless it was already ms ABI.  EFI uses COFF object files anyway - don't those have to use ms ABI?

 

I use very few of the Clover patches to edk2.  Mostly vanilla.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

It's not just the Conf.  Conf is a must, otherwise the build stops with an error after only a few files.

 

I also use following from Patches_for_EDK2

BaseTools/Scripts/gcc4.9-ld-script

MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c

MdePkg/Include/Base.h

MdePkg/Include/Uefi/UefiBaseType.h

MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c

MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c

PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.c

 

Clover.{dsc,fdf} are modified to use some of the vanilla Dxe instead of the ones under Clover/.

Link to comment
Share on other sites
stinga11
stinga11
Posted
Posted

It might not mean anything, but in the last clover revision. the hex number of platform-feature it changed. First, the hex number looks like a real mac.

<0400000000000000> 

In the latest revision looks

<0000000004000000> 
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

The plot thickens.... I modified Conf/build_rule.txt to print some of the gcc invocations, and many them already have -Os! (as well as -mabi=ms).  The -Os I added in Clover.dsc was a 2nd -Os on the command line.

Yet, when I remove -Os from Clover.dsc, results in code bloat > 0x6a000.

 

So it appears, the some of the compilation rules already have -Os, and some don't have -Os !!!

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

 

It might not mean anything, but in the last clover revision. the hex number of platform-feature it changed. First, the hex number looks like a real mac.

<0400000000000000> 

In the latest revision looks

<0000000004000000> 

:blink:

Please upload full DD report to see what is wrong.

The plot thickens.... I modified Conf/build_rule.txt to print some of the gcc invocations, and many them already have -Os! (as well as -mabi=ms).  The -Os I added in Clover.dsc was a 2nd -Os on the command line.

Yet, when I remove -Os from Clover.dsc, results in code bloat > 0x6a000.

 

So it appears, the some of the compilation rules already have -Os, and some don't have -Os !!!

Somewhere this optimization lead to wrong codes. But it was two years ago.

Link to comment
Share on other sites
cecekpawon
cecekpawon
Posted
Posted

Just to report

# with r3386
Handle 0x8500, DMI type 133, 12 bytes
OEM-specific Type
  Header and Data:
    85 0C 00 85 00 00 00 00 00 00 00 00

# before r3386
Handle 0x8500, DMI type 133, 12 bytes
OEM-specific Type
  Header and Data:
    85 0C 00 85 00 00 00 00 04 00 00 00

# should be
Handle 0x0041, DMI type 133, 12 bytes
0000: 85 0c 41 00 04 00 00 00 00 00 00 00 

OEM-specific Type
  Header and Data:
    85 0C 41 00 04 00 00 00 00 00 00 00

<key>PlatformFeature</key>
<integer>4</integer>
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

 

Just to report

# with r3386
Handle 0x8500, DMI type 133, 12 bytes
OEM-specific Type
  Header and Data:
    85 0C 00 85 00 00 00 00 00 00 00 00

# before r3386
Handle 0x8500, DMI type 133, 12 bytes
OEM-specific Type
  Header and Data:
    85 0C 00 85 00 00 00 00 04 00 00 00

# should be
Handle 0x0041, DMI type 133, 12 bytes
0000: 85 0c 41 00 04 00 00 00 00 00 00 00 

OEM-specific Type
  Header and Data:
    85 0C 41 00 04 00 00 00 00 00 00 00

<key>PlatformFeature</key>
<integer>4</integer>

I understand.

@TheRacerMaster.

This is your mistake. You forget to add #pragma pack(1). Smbios tables must be packed what is not default for gcc.

Compare old SmbiosA.h and  your AppleSmBios.h

Link to comment
Share on other sites
droples
droples
Posted
Posted

Clover3390_GCC5.3

Building ... /Users/droplets/src/edk2/Clover/AtaAtapi/AtaAtapiPassThru.inf [X64]
[DLINK1] Fat
[OBJCOPY] Fat
lto1: fatal error: bytecode stream generated with LTO version 3.0 instead of the expected 4.0
compilation terminated.
lto-wrapper: fatal error: /Users/droplets/src/edk2/Clover/../../opt/local/cross/bin/x86_64-clover-linux-gnu-gcc returned 1 exit status
compilation terminated.
/Users/droplets/src/opt/local/cross/lib/gcc/x86_64-clover-linux-gnu/5.3.0/../../../../x86_64-clover-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [/Users/droplets/src/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/SataControllerDxe/SataControllerDxe/DEBUG/SataController.dll] Error 1
build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/droplets/src/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/SataControllerDxe/SataControllerDxe]
build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/droplets/src/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/AtaAtapi/AtaAtapiPassThru]
build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/droplets/src/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/AtaBus/AtaBusDxe]
build.py...
 : error F002: Failed to build module
	/Users/droplets/src/edk2/Clover/SataControllerDxe/SataControllerDxe.inf [X64, GCC49, RELEASE]

- Failed -
Build end time: 22:45:19, Mar.30 2016
Build total time: 00:00:49

iMac-Droplets:Clover droplets$
Link to comment
Share on other sites
smolderas
smolderas
Posted
Posted

Could someone please help me?

 

I have edk2 at revision 20433 (tested r20424 too without luck) and Clover at revision 3390 and got this:

<redacted>:Clover <redacted>$ ./ebuild.sh -D USE_APPLE_HFSPLUS_DRIVER -D ENABLE_VBIOS_PATCH_CLOVEREFI -D ONLY_SATA_0 -D USE_LOW_EBDA -p Clover/Clover.dsc  -a X64 -b RELEASE -t GCC49 -n 9
TOOLCHAIN_DIR: /usr/local/toolchain
Initializing workspace
Loading previous configuration from /usr/local/edk2/Conf/BuildEnv.sh
WORKSPACE: /usr/local/edk2
EDK_TOOLS_PATH: /usr/local/edk2/BaseTools
CONF_PATH: /usr/local/edk2/Conf

Running edk2 build for CloverX64 using the command:
build  -D USE_APPLE_HFSPLUS_DRIVER -D ENABLE_VBIOS_PATCH_CLOVEREFI -D ONLY_SATA_0 -D USE_LOW_EBDA -p Clover/Clover.dsc  -a X64 -b RELEASE -t GCC49 -n 9 

Traceback (most recent call last):
  File "/usr/local/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 41, in <module>
    from AutoGen.AutoGen import *
  File "/usr/local/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line 22, in <module>
    import GenC
  File "/usr/local/edk2/BaseTools/Source/Python/AutoGen/GenC.py", line 1170
    if DatumType == 'VOID*':
                           ^
IndentationError: unindent does not match any outer indentation level
<redacted>:Clover <redacted>$

Even without any option the ebuild.sh throws same error. Anything I am missing?

 

Edit: With the same setup last version I was able to compile was r3364 on 10.11.3...

 

Edit2: I tried all other toolchains too without any luck...

 

Edit3: even ebuild.sh clean or cleanall throws same error.

Link to comment
Share on other sites
smolderas
smolderas
Posted
Posted

Delete old files Autogen.py and GenC.py and update EDK2 again.

Simple update without deleting will mix old and new codes.

Yeah I was overriding old files with theirs in conflicts while checking out from edk2 svn. Weird. It is now working, thanks Slice (Sergei?)...

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...