Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

Slice
Slice
Posted
Posted
On 6/19/2018 at 11:43 PM, vector sigma said:

@Slice, and all, I want to propose some changes to ebuild.sh and in buildpkg.sh

 

ebuild.sh

I'm not a big supporter of pre built binaries inside my source, so I modified it a bit:

  1. no download by default, '--no-ext' sobstituted with '--ext-pre' to enable it.
  2. Added '--ext-co' to fresh clone & build latest AptioFixPkg/ApfsSupportPkg (and dependecies from the development branch as requested). Since I didn't like to to put external stuff inside the edk/udk folder these Pkg are placed inside a directory called 'EXT_PACKAGES' created at the same level of the edk2/udk folder .. so not inside it. ebuild.sh take the step to export this additional path in PACKAGES_PATH.
  3. Added ''--ext-build', build or rebuild external Pkg(s) at your will. This allow us to make modification to the source... who knows.
  4. Added missing drivers like XhciDxe/ApfsSupport to both drivers64/drivers64UEFI (see buildpkg.sh).

 

examples:

...to download and build external sources (..not needed on the second run): 


./ebuild.sh --ext-co -x64 -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8
./ebuild.sh -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8

or if you want to build them again: 


./ebuild.sh --ext-build -x64 -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8
./ebuild.sh -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8

 

Instead, if you want them again as prebuilt binaries from github: 


./ebuild.sh --ext-pre -x64 -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8
./ebuild.sh -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8

in all cases existing external drivers will be copied to their respective destinations if found, may be downloaded/built a month ago..

 

buildpkg.sh: 

Can now add duplicate choices, in case of drivers.

 

Let me know, here works, but testers are welcome!:)

 

 

 

ebuild.sh.zip

buildpkg.sh.zip

Thanks for your work but some problems

MacBook-Pro-Sergey:Clover sergey$ ./buildpkg.sh --srcroot CloverPackage --symroot CloverPackage/sym --builddir CloverPackage/sym/package

cat: version: No such file or directory

cat: revision: No such file or directory

sed: ./../../Version.h: No such file or directory

Failed conversion of ``'' using format ``%Y-%m-%d %H:%M:%S''

date: illegal time format

usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...

            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

awk: can't open file ./../CREDITS

source line number 1

awk: can't open file ./../CREDITS

source line number 1

awk: can't open file ./../CREDITS

source line number 1

awk: can't open file ./../CREDITS

source line number 1

 

  -------------------------------

  Building Clover Install Package

  -------------------------------

 

====================== Preinstall ======================

Error addTemplateScripts: template 'Pre' doesn't exists

MacBook-Pro-Sergey:Clover sergey$

  • Like 2
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted
33 minutes ago, Slice said:

We can avoid duplicate choice by copy drivers with different names

XhciDxe-64.efi to drivers64

XhciDxe-64U.efi to drivers64U

The sensible way to handle XhciDxe is to either embed it into boot6 with -D ENABLE_USB_XHCI or not use it at all.  It doesn't belong in drivers64 or drivers64UEFI.

 

Quote

Systems with a xhci controller and UEFI bios have a builtin XHCI driver, so XhciDxe does not belong in drivers64UEFI

When using boot7, USB controller drivers should not be used because they either don't work or wrest the controller away from legacy bios that should own it.

When using boot6 on a system that only has a XHCI controller (like mine) - XhciDxe needs to be included in boot6 with -D ENABLE_USB_XHCI or it can't boot form USB sticks.

So XhciDxe should only be in drivers64 when using boot6, the system has additional older type USB controllers and you never plan to boot Clover from the XHCI controller.

 

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

One possible case is SandyBridge machine (like H61M) having no XHCI controller but having UEFI BIOS.

XHCI controller can be inserted into PCIe 4x slot and will work in system. In this case we can place XhciDxe into drivers64UEFI. Clover will not started from there but what about OSInstall?

 

I am not sure that boot6 has enough space for XHCI. Should try.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted (edited)

driver64/driver64UEFI are for commonly used setups

drivers-Off is for special setups

 

I haven't tried what happens when loading XhciDxe with a native UEFI xhci driver present, but as I remember, there is no protection mechanism for preventing mutliple Dxe from trying to manage the xhci PCI configuration space and registers - so it can cause a crash.

 

I don't see the point of compiling boot7 with '-mc --no-usb', only to have Clover GUI turn around and load XhciDxe.  I remember trying years ago with explict load XhciDxe.efi from the shell, and it hung.

And remembering some more: it hung on the bios semaphore, after which I added code to break the bios semaphore - and I found that now loads only to make xhci unusable.  Because legacy bios loses control, and XhciDxe doesn't have the USB stack to support it.

Edited by Zenith432
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
5 hours ago, Slice said:

Thanks for your work

it's a pleasure!:)

 

5 hours ago, Slice said:

MacBook-Pro-Sergey:Clover sergey$ ./buildpkg.sh --srcroot CloverPackage --symroot CloverPackage/sym --builddir CloverPackage/sym/package

cat: version: No such file or directory

cat: revision: No such file or directory

sed: ./../../Version.h: No such file or directory

I just cd into CloverPackage and then 'make pkg' and works. But from your errors I can see that he cannot find Version.h of which is not its business and I didn't touch (ebuild.sh is?). Can be that you run it with a fresh copy of Clover never built? Anyway I'll take a better look as soon as I have time.

 

About XhciDXe, was just added under drivers64UEFI but not enabled by default, isn't that right then?

 

@Slice,@Zenith432, I'll follow all your advices, but sorry until tomorrow I'll be very busy..

 

P.S. I now see that we have a duplicate of Version.h, but this isn't bad? I mean, you are not causing existing modules to be rebuilt again and again with no reason?

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

Update on XhciDxe:

 

I loaded XhciDxe into native UEFI bios that has builtin xhci driver.  It didn't connect to the xhci controller and didn't interfere with existing functionality.  So it can be safely put in drivers64UEFI to cover cases of native UEFI bios without a native xhci driver.

 

I tested XhciDxe with boot7 - and USB keyboard immediately stopped working because it's connect thru xhci.

 

I will look over XhciDxe this weekend to find a way to make it not interfere with boot7 such that it can still be put in driver64 to work with boot6.

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

@vector sigma:

 

If you got "no matching pragma" with 4569 then you're using an obsolete patch to MdePkg/Include/X64/ProcessorBind.h in your edk2/udk2018 tree that should be reverted.  I will leave it as is and change to the previous workaround that uses -DUSING_LTO, but please update your patches because this preprocessor symbol may be deprecated by EDK2 in the future.

Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
1 minute ago, Zenith432 said:

@vector sigma:

 

If you got "no matching pragma" with 4569 then you're using an obsolete patch to MdePkg/Include/X64/ProcessorBind.h in your edk2/udk2018 tree that should be reverted.  I will leave it as is and change to the previous workaround that uses -DUSING_LTO, but please update your patches because this preprocessor symbol may be deprecated by EDK2 in the future.

oh, sorry I'm going to try. I'm doing some works on the packages and I just wasn't able to compile it again. Let you know immediately

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

It's ok.  The patch has a history.... EDK2 originally added

 

#if defined(__GNUC__) && defined(__pic__)

#pragma GCC visibility push(hidden)

#endif

 

in order to serve their GCC5 toolchain that moved to using -fpie/--pie settings instead of the large model.

Clover was using Xcode with LTO at the time and this broke the Xcode build, so slice added

#if defined(__GNUC__) && defined(__pic__) && !defined(__clang__)

 

to the condition.  Later EDK2 moved to using LTO with GCC5 and it broke their build, so they started using a macro USING_LTO and made the condition

#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO)

 

And Clover continued to have the !defined(__clang__) condition, but stopped using LTO with Xcode.

Then I found that for Xcode non-LTO, enabling this pragma reduces code size for XCODE8 by about 9K.  So I reenabled it for clang.

But in clover-genconfig, the pragma needs to be turned off - either completely or after the #include of "Platform.h" because otherwise it makes the macOS functions hidden too (which they shouldn't be because they're in shared libraries).

So USING_LTO suppresses the pragma, but if EDK2 decide to eliminate this macro in the future, then visibility should be returned to default in clover-genconfig.c after #include of Platform.h by using either

#pragma GCC visibility pop

or

#pragma GCC visibility push(default)

  • Like 1
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted (edited)
On 6/17/2018 at 11:13 AM, Sherlocks said:

now, clover has problems in edid part

1. not working custom edid value in 10.6/10.7.

-injected edid in ioreg. but there is custom edid from darwin dump.

2. not consider 256 edid.

Hi Sherlocks, EDID >= 256 bytes is just like the other, for that you have to check bytes[126] which is the number of (optional) 128-byte EDID extension blocks to follow. With that you should be able to know the expected size.

Edited by vector sigma
  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I'm finding that injecting AAPL,GfxYTile causes problems on 10.14 beta with KabyLake-R UHD 620 graphics (my hardware is a NUC7 Dawson Canyon).

 

Since AAPL,GfxYTile is really a work around for much older versions of OS X, and can be easily applied if needed with config.plist/Devices/AddProperties, better to remove this code from Clover.

 

My diffs: 


NUC6i7KYK:Clover rehabman$ git diff rEFIt_UEFI/Platform/gma.c
diff --git a/rEFIt_UEFI/Platform/gma.c b/rEFIt_UEFI/Platform/gma.c
index 962c2079..ff0794a7 100644
--- a/rEFIt_UEFI/Platform/gma.c
+++ b/rEFIt_UEFI/Platform/gma.c
@@ -2436,7 +2436,8 @@ BOOLEAN setup_gma_devprop(pci_dt_t *gma_dev)
             default:
               break;
           }
-          devprop_add_value(device, "AAPL,GfxYTile", skylake_hd_vals[1], 4);
+          //REVIEW_REHABMAN: not needed and problematic with UHD620 on 10.14 beta
+          //devprop_add_value(device, "AAPL,GfxYTile", skylake_hd_vals[1], 4);
           break;
       }
       break;
@@ -2645,7 +2646,8 @@ BOOLEAN setup_gma_devprop(pci_dt_t *gma_dev)
             default:
               break;
           }
-          devprop_add_value(device, "AAPL,GfxYTile", kabylake_hd_vals[1], 4);
+          //REVIEW_REHABMAN: not needed and problematic with UHD620 on 10.14 beta
+          //devprop_add_value(device, "AAPL,GfxYTile", kabylake_hd_vals[1], 4);
           break;
       }
       break;

 

  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
On 6/30/2018 at 7:56 PM, RehabMan said:

I'm finding that injecting AAPL,GfxYTile causes problems on 10.14 beta with KabyLake-R UHD 620 graphics (my hardware is a NUC7 Dawson Canyon).

 

Since AAPL,GfxYTile is really a work around for much older versions of OS X, and can be easily applied if needed with config.plist/Devices/AddProperties, better to remove this code from Clover.

 

My diffs:

  


NUC6i7KYK:Clover rehabman$ git diff rEFIt_UEFI/Platform/gma.c
diff --git a/rEFIt_UEFI/Platform/gma.c b/rEFIt_UEFI/Platform/gma.c
index 962c2079..ff0794a7 100644
--- a/rEFIt_UEFI/Platform/gma.c
+++ b/rEFIt_UEFI/Platform/gma.c
@@ -2436,7 +2436,8 @@ BOOLEAN setup_gma_devprop(pci_dt_t *gma_dev)
             default:
               break;
           }
-          devprop_add_value(device, "AAPL,GfxYTile", skylake_hd_vals[1], 4);
+          //REVIEW_REHABMAN: not needed and problematic with UHD620 on 10.14 beta
+          //devprop_add_value(device, "AAPL,GfxYTile", skylake_hd_vals[1], 4);
           break;
       }
       break;
@@ -2645,7 +2646,8 @@ BOOLEAN setup_gma_devprop(pci_dt_t *gma_dev)
             default:
               break;
           }
-          devprop_add_value(device, "AAPL,GfxYTile", kabylake_hd_vals[1], 4);
+          //REVIEW_REHABMAN: not needed and problematic with UHD620 on 10.14 beta
+          //devprop_add_value(device, "AAPL,GfxYTile", kabylake_hd_vals[1], 4);
           break;
       }
       break;

 

 

As far as I remember this set of properties (AAPL,Gfx*) I found surplus and unwanted. Don't know why they present in Clover.

Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted
As far as I remember this set of properties (AAPL,Gfx*) I found surplus and unwanted. Don't know why they present in Clover.
this solution is glitches fix for skylake graphics in el capitan and sierra. i don't know when no need this value.
https://pikeralpha.wordpress.com/2016/10/30/aapl-properties-for-skylake-graphics/

but i checked this values from realmac dump. since macbook, macbookpro of skylake+. these laptop still have this value in high sierra.

sorry for my bad english

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted
1 hour ago, Sherlocks said:

this solution is glitches fix for skylake graphics in el capitan and sierra. i don't know when no need this value.
https://pikeralpha.wordpress.com/2016/10/30/aapl-properties-for-skylake-graphics/

but i checked this values from realmac dump. since macbook, macbookpro of skylake+. these laptop still have this value in high sierra.

sorry for my bad english

나의 LG-F800S 의 Tapatalk에서 보냄
 

 

Injecting AAPL,GfxYTile causes a hang on boot in 10.14 beta with my NUC KabyLake-R UHD620.

I tested by using my own SSDT-IGPU.aml (which works fine as is), and adding AAPL,GfxYTile... confirming that it causes the hang.

Then I removed the code as I mention earlier from Clover and verified I was able to boot successfully without AAPL,GfxYTile using Clover injection instead of my SSDT-IGPU.aml.

The AAPL,GfxYTile inject should be removed.

 

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Hi guys,

Can we somehow mix UEFI and legacy Clover as follow?

1. Boot UEFI.

2. Stop original services.

3. Define own DS and BS as legacy Clover did. But keep OEM RS.

4. Cleanup memory map and start own EFI implementation.

This way we will not need AptioFix as legacy Clover and have native NVRAM as OEM UEFI.

Any thoughts? Is it possible?

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

Defining own BS will not resolve the NVRAM issue, that would need to be taken over from AF.

 

AMI BS code is very broken and if you want to entirely terminate the AMI UEFI environment, there *will* be leftovers (devices not properly stopped etc) that will need to be cleaned up in a platform-specific way. Not terminating the AMI UEFI env could lead to invalid accesses to the old services. Not every driver is terminatable, but modifies the environment (device ownership, IDT, ...), needs cleanup too. RT drivers would need to be reloaded or replaced to guarantee a safe environment. Reloading might not work due to dependencies on actions done on events (AMI specific events etc). Some actions run twice might cause issues.

 

There will be a huge performance penalty and a noticable switch (GOP needs to be shut down and back up, etc).

 

All in all, a crapton of work for almost no benefit, would not recommend. The two best options we have are AptioFix and a replacement for the entire platform FW.

 

 

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Yes, GOP, SATA, USB will be restarted. Events are connected to timer interrupts so hardware vectors will be rewritten. RT services should be independent because they work in loaded OS.

There are very many doubts in this idea but AptioFix looked impossible too.

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted
Just now, Slice said:

RT services should be independent because they work in loaded OS.

You can only assume that after SetVirtualAddressMap()... At best it would be ExitBootServices(), but iirc Linux has workarounds for borked firmwares that still access BS memory after ExitBS().

 

3 minutes ago, Slice said:

but AptioFix looked impossible too.

Sorry, what do you mean?

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
6 hours ago, Download-Fritz said:

You can only assume that after SetVirtualAddressMap()... At best it would be ExitBootServices(), but iirc Linux has workarounds for borked firmwares that still access BS memory after ExitBS().

 

Sorry, what do you mean?

If a firmware will has access BS memory after HackOS started then it will be crash, kernel panic, because the kernel reuse all BS memory.

 

I mean history, nothing more.

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted
5 minutes ago, Slice said:

If a firmware will has access BS memory after HackOS started then it will be crash, kernel panic, because the kernel reuse all BS memory.

The kernel will not start until after SetVirtualAddressMap().

 

Aside from that, I honestly cannot imagine why CSM even works... it's integrated quite deeply and, in contrast to probably anything else, tested, so I guess it does a bunch of cleanup tasks. The point is you need more platform knowledge than you should have to implement this with almost no gain. If it's only about NVRAM for you, porting AMI NVRAM to DUET would probably be an easier and cleaner task.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Can we implement SSE2 functions in Clover like these? 

	__m128i const0 = _mm_setzero_si128();
	__m128i const1 = _mm_set1_epi16(1);
	__m128i constC = _mm_set_epi16(0, (short)cb, (short)cg, (short)cr, 0, (short)cb, (short)cg, (short)cr);

 

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
1 minute ago, Zenith432 said:

@Slice

These are not compiler intrinsics - they're macros or inline functions defined in xmmintrin.h or emmintrin.h.  So you need to find these include files in the toolchain.  Compiler instrinsics are different between gcc/clang and visual c.

We have it in VoodooHDA?

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