Clover Problems and Solutions

TheRacerMaster · April 4, 2016

r3398 broke compilation with Xcode/clang due to extra parentheses in Nvidia.c, removing them fixes it:

diff --git a/rEFIt_UEFI/Platform/nvidia.c b/rEFIt_UEFI/Platform/nvidia.c
index 730eda4..0056c84 100644
--- a/rEFIt_UEFI/Platform/nvidia.c
+++ b/rEFIt_UEFI/Platform/nvidia.c
@@ -2301,7 +2301,7 @@ BOOLEAN setup_nvidia_devprop(pci_dt_t *nvda_dev)
     devprop_add_value(device, "vendor-id", (UINT8*)&FakeID, 4);
   }
   
-	if ((gSettings.NVCAP[0] != 0)) {
+	if (gSettings.NVCAP[0] != 0) {
 		devprop_add_value(device, "NVCAP", &gSettings.NVCAP[0], NVCAP_LEN);
     DBG("set NVCAP: %02x%02x%02x%02x-%02x%02x%02x%02x-%02x%02x%02x%02x-%02x%02x%02x%02x-%02x%02x%02x%02x\n",
         gSettings.NVCAP[0], gSettings.NVCAP[1], gSettings.NVCAP[2], gSettings.NVCAP[3],
@@ -2337,7 +2337,7 @@ BOOLEAN setup_nvidia_devprop(pci_dt_t *nvda_dev)
 		devprop_add_value(device, "@0,built-in", &built_in, 1);
 	}
   
-	if ((gSettings.NVCAP[0] == 0)) {
+	if (gSettings.NVCAP[0] == 0) {
 		devprop_add_value(device, "NVCAP", default_NVCAP, NVCAP_LEN);
     DBG("default NVCAP: %02x%02x%02x%02x-%02x%02x%02x%02x-%02x%02x%02x%02x-%02x%02x%02x%02x-%02x%02x%02x%02x\n",
         default_NVCAP[0], default_NVCAP[1], default_NVCAP[2], default_NVCAP[3],

TheRacerMaster · April 4, 2016

Also, somewhat unrelated, but building with Xcode/clang seems to break DSDT binary patching (config.pist/DSDT/Patches).

1:907  0:000   patch pattern 5F4F5349
1:907  0:000    bin not found
1:907  0:000   patch pattern 434F5052
1:908  0:000    bin not found
1:908  0:000   patch pattern 45484331
1:908  0:000    bin not found
1:908  0:000   patch pattern 45484332
1:908  0:000    bin not found
1:908  0:000   patch pattern 47465830
1:908  0:000    bin not found
1:909  0:000   patch pattern 5F414452
1:909  0:000    bin not found
1:909  0:000   patch pattern 474C414E
1:909  0:000    bin not found
1:909  0:000   patch pattern 50454750
1:909  0:000    bin not found
1:909  0:000   patch pattern 53415430
1:910  0:000    bin not found
1:910  0:000   patch pattern 5848435F
1:910  0:000    bin not found

With GCC it works fine.

BOOTX64.efi.zip

cecekpawon · April 4, 2016

With GCC it works fine.

For me, it looks like Clover try to looking our DSDT pattern in SSDT after successfully patching DSDT (patches applied twice)?

0:427  0:000  Config set Fixes will override FixMask mask!
0:427  0:000     final mask=800A2109
0:427  0:000  PatchesDSDT: 7 requested
0:427  0:000   DSDT bin patch #0  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #1  lenToFind=4  lenToReplace=4
0:427  0:000   patch disabled, skipped
0:427  0:000   DSDT bin patch #3  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #4  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #5  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #6  lenToFind=4  lenToReplace=4

...

4:226  0:000  ========= Auto patch DSDT Finished ========
4:226  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=Cpu0Ist Length=2474
4:226  0:000   Xsdt has tables count=8 
4:226  0:000   Table: SSDT  Cpu0Ist  2474 dropped
4:226  0:000  corrected XSDT length=92
4:226  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=CpuPm Length=2706
4:226  0:000   Xsdt has tables count=7 
4:226  0:000   Table: SSDT  CpuPm  2706 dropped
4:226  0:000  corrected XSDT length=84
4:226  0:000  Patch table: SSDT  SataTabl
4:226  0:000   SSDT len = 0x36D
4:226  0:000   patch pattern 53415430
4:226  0:000    patched at B5
4:226  0:000   patch pattern 4543305F
4:226  0:000    bin not found
4:226  0:000   patch pattern 47465830
4:226  0:000    bin not found
4:226  0:000   patch pattern 434F5052
4:226  0:000    bin not found
4:226  0:000   patch pattern 50454750
4:226  0:000    bin not found
4:226  0:000   patch pattern 45484331
4:226  0:000    bin not found

Slice · April 4, 2016

To: @slice

** update with @TheRacerMaster patch below

OK, revised and committed. I tested it on my Geforce 7300LE (comp #4 in my sig). Looks like nothing changed.

Also, somewhat unrelated, but building with Xcode/clang seems to break DSDT binary patching (config.pist/DSDT/Patches).

1:907  0:000   patch pattern 5F4F5349
1:907  0:000    bin not found
1:907  0:000   patch pattern 434F5052
1:908  0:000    bin not found
1:908  0:000   patch pattern 45484331
1:908  0:000    bin not found
1:908  0:000   patch pattern 45484332
1:908  0:000    bin not found
1:908  0:000   patch pattern 47465830
1:908  0:000    bin not found
1:909  0:000   patch pattern 5F414452
1:909  0:000    bin not found
1:909  0:000   patch pattern 474C414E
1:909  0:000    bin not found
1:909  0:000   patch pattern 50454750
1:909  0:000    bin not found
1:909  0:000   patch pattern 53415430
1:910  0:000    bin not found
1:910  0:000   patch pattern 5848435F
1:910  0:000    bin not found

With GCC it works fine.

It is strange and should be discovered more. I know that clang compilation leads to non-working codes but I still don't know what is the last reason.

What I know:

1. Clang don't like absolute addressing so I rewritten all asm procedures to use only relative addressing.

2. Clang do aggressive optimisation replacing for example

for (i=1;i

by memcpy builtin function.

It is not permissible for our case because between compiling and linking there are more actions.

So I have to find all such places in sources and force clang do not make optimization here.

3. Clang before version 3.7 doesn't know ms_va_list using unix_va_list instead which is not the same.

Using old clang is not possible for this project.

4. I know a Clang dependent bug in Wine 39758. But I don't know how it influences on Clover.

For me, it looks like Clover try to looking our DSDT pattern in SSDT after successfully patching DSDT (patches applied twice)?

0:427  0:000  Config set Fixes will override FixMask mask!
0:427  0:000     final mask=800A2109
0:427  0:000  PatchesDSDT: 7 requested
0:427  0:000   DSDT bin patch #0  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #1  lenToFind=4  lenToReplace=4
0:427  0:000   patch disabled, skipped
0:427  0:000   DSDT bin patch #3  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #4  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #5  lenToFind=4  lenToReplace=4
0:427  0:000   DSDT bin patch #6  lenToFind=4  lenToReplace=4

...

4:226  0:000  ========= Auto patch DSDT Finished ========
4:226  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=Cpu0Ist Length=2474
4:226  0:000   Xsdt has tables count=8 
4:226  0:000   Table: SSDT  Cpu0Ist  2474 dropped
4:226  0:000  corrected XSDT length=92
4:226  0:000  Drop tables from Xsdt, SIGN=SSDT TableID=CpuPm Length=2706
4:226  0:000   Xsdt has tables count=7 
4:226  0:000   Table: SSDT  CpuPm  2706 dropped
4:226  0:000  corrected XSDT length=84
4:226  0:000  Patch table: SSDT  SataTabl
4:226  0:000   SSDT len = 0x36D
4:226  0:000   patch pattern 53415430
4:226  0:000    patched at B5
4:226  0:000   patch pattern 4543305F
4:226  0:000    bin not found
4:226  0:000   patch pattern 47465830
4:226  0:000    bin not found
4:226  0:000   patch pattern 434F5052
4:226  0:000    bin not found
4:226  0:000   patch pattern 50454750
4:226  0:000    bin not found
4:226  0:000   patch pattern 45484331
4:226  0:000    bin not found

This is designed behavior.

If user make a patch with renaming a device then all SSDT must be patched as well to rename links for this device.

dgsga · April 4, 2016

@ racermaster,

I've been trying to compile with clang/xcode but I always get a bootx64.efi that fails to load (black screen on boot). Which version of XCode/clang are you using, and are you making any changes to the Conf files at all (tools_def and build_rules.txt)??

Thanks for your help...

cecekpawon · April 4, 2016

Thanks @slice, here what @TheRacerMaster mentioned before

Slice · April 4, 2016

Thanks @slice, here what @TheRacerMaster mentioned before

Yes, it is here.

smolderas · April 4, 2016

With the latest update on nvidia.c (r3399 I think) my second graphics cards memory won't show up correct. It shows 1 MB instead of 1280 MB...

I have two 570 GTX.

Edit: In the logs for the first card it is recognized correctly, the second got "-9007199253692416"...

0:365  0:000  mem_detected 1342177280
0:365  0:000  read_nVidia_ROM
0:365  0:000  Using PRAMIN fixups
0:576  0:211  patch_nvidia_rom
0:576  0:000  version 70.10.55.00.01
0:576  0:000  nVidia NVIDIA GeForce GTX 570 HD  1280MB NVC8 [10DE:1086] :: PcieRoot(0x0)\Pci(0x1,0x0)\Pci(0x0,0x0) => device #1 
0:576  0:000  devprop_add_nvidia_template
0:576  0:000  Nvidia: VideoPorts: undefined, default to: 2
0:576  0:000  default NVCAP: 04000000-00000300-3C000000-00000007-00000000
0:576  0:000  mem_detected -9007199253692416
0:576  0:000  read_nVidia_ROM
0:576  0:000  Using PRAMIN fixups
0:635  0:058  PROM
0:694  0:058  ERROR: Unable to locate nVidia Video BIOS
0:694  0:000  there are no ROM loaded and no VBIOS read from hardware
0:694  0:000  nVidia NVIDIA GeForce GTX 570 HD  1MB NV1FF [10DE:1086] :: PcieRoot(0x0)\Pci(0x1,0x1)\Pci(0x0,0x0) => device #2 
0:694  0:000  devprop_add_nvidia_template
0:694  0:000  Nvidia: VideoPorts: undefined, default to: 2
0:694  0:000  default NVCAP: 04000000-00000300-3C000000-00000007-00000000

Edit2: returning to r3398 "fixes" it, I think it takes the mem_detected of the first card. In OS X it shows the correct value though...

0:365  0:000  mem_detected 1342177280
0:365  0:000  read_nVidia_ROM
0:365  0:000  Using PRAMIN fixups
0:576  0:210  patch_nvidia_rom
0:576  0:000  version 70.10.55.00.01
0:576  0:000  nVidia NVIDIA GeForce GTX 570 HD  1280MB NVC8 [10DE:1086] :: 
0:576  0:000  PcieRoot(0x0)\Pci(0x1,0x0)\Pci(0x0,0x0)
0:576  0:000  devprop_add_nvidia_template
0:576  0:000  default NVCAP: 04000000-00000300-3C000000-00000007-00000000
0:576  0:000  read_nVidia_ROM
0:576  0:000  Using PRAMIN fixups
0:635  0:059  PROM
0:695  0:059  ERROR: Unable to locate nVidia Video BIOS
0:695  0:000  there are no ROM loaded and no VBIOS read from hardware
0:695  0:000  nVidia NVIDIA GeForce GTX 570 HD  1280MB NV1FF [10DE:1086] :: 
0:695  0:000  PcieRoot(0x0)\Pci(0x1,0x1)\Pci(0x0,0x0)
0:695  0:000  devprop_add_nvidia_template
0:695  0:000  default NVCAP: 04000000-00000300-3C000000-00000007-00000000

Edit3: r3407 (including r3403, which should fix the issue) didn't help either

Edit4: uncommenting the line 2176 in nvidia.c fixes the issue:

	// Amount of VRAM in kilobytes (?) no, it is already in bytes!!!
	if (gSettings.VRAM != 0) {
		videoRam = gSettings.VRAM;
	} else {
		videoRam = mem_detect(nvCardType, nvda_dev);
	//    gSettings.VRAM = videoRam;
	}

stinga11 · April 4, 2016

	<key>Graphics</key>
	<dict>
		<key>Inject</key>
		<dict>
			<key>Intel</key>
			<true/>
		</dict>
		<key>ig-platform-id</key>
		<string>0x10000300</string>
	</dict>

I found a bug. When I put the snb-platform-id. I have only the "ig-platform-id" but the sandy bridge HD3000 needs the snb not the ig. I had to delete the AppleIntelSNBGraphicsFB.kext to boot the Hackintosh. Otherwise it would not have been able to generate the darwin dumper.

DarwinDumper_2.9.9.2_AMI_X64_3389_Mav_macuser.zip

RehabMan · April 4, 2016

	<key>Graphics</key>
	<dict>
		<key>Inject</key>
		<dict>
			<key>Intel</key>
			<true/>
		</dict>
		<key>ig-platform-id</key>
		<string>0x10000300</string>
	</dict>
I found a bug. When I put the snb-platform-id. I have only the "ig-platform-id" but the sandy bridge HD3000 needs the snb not the ig. I had to delete the AppleIntelSNBGraphicsFB.kext to boot the Hackintosh. Otherwise it would not have been able to generate the darwin dumper.

DarwinDumper_2.9.9.2_AMI_X64_3389_Mav_macuser.zip

The ig-platform-id setting is only for AAPL,ig-platform-id. It cannot be used for AAPL,snb-platform-id. You need to use /Devices/Arbitrary, /Devices/AddProperties, or ACPI/_DSM injection.

In other words... not so much a bug. More like a feature not implemented.

stinga11 · April 4, 2016

The ig-platform-id setting is only for AAPL,ig-platform-id. It cannot be used for AAPL,snb-platform-id. You need to use /Devices/Arbitrary, /Devices/AddProperties, or ACPI/_DSM injection.

In other words... not so much a bug. More like a feature not implemented.

Slice wrote:

Rev 3321

Add an item into Clover menu for instant set *-platform-id which used as ig-platform-id or snb-platform-id.

RehabMan · April 4, 2016

Slice wrote:

Rev 3321

Add an item into Clover menu for instant set *-platform-id which used as ig-platform-id or snb-platform-id.

I find this in the source code:

  switch (gma_dev->device_id) {
    case 0x0102: 
      devprop_add_value(device, "class-code",	(UINT8*)ClassFix, 4);
    case 0x0106:
    case 0x0112:  
    case 0x0116:
    case 0x0122:
    case 0x0126:
 /*     switch (MacModel) {
        case MacBookPro81:
          SnbId = 0x00000100;
          break;
        case MacBookPro83:
          SnbId = 0x00000200;
          break;
        case MacMini51:
          SnbId = 0x10000300;
          break;
      case Macmini52:
          SnbId = 0x20000300;
          break;
        case MacBookAir41:
          SnbId = 0x00000400;
          break;

        default:
          break;
      }
      if (SnbId != 0) {
        devprop_add_value(device, "AAPL,snb-platform-id",	(UINT8*)&SnbId, 4);
      }
  */
  */
    case 0x0152:
    case 0x0156:
    case 0x0162:
    case 0x0166:
    case 0x016A:
...

Note that it is commented out and falls through to the ig-platform-id related code...

Slice · April 4, 2016

I seems forget to finish the work...

RehabMan · April 4, 2016

I seems forget to finish the work...

FYI: snb-platform-id support was requested a few months ago, but you stated it wasn't needed as there are other methods.

And there are already many ways to do this in config.plist.

TheRacerMaster · April 4, 2016

@ racermaster,

I've been trying to compile with clang/xcode but I always get a bootx64.efi that fails to load (black screen on boot). Which version of XCode/clang are you using, and are you making any changes to the Conf files at all (tools_def and build_rules.txt)??

Thanks for your help...

I'm using Xcode 7.3 with stock EDK2 tools_def/build_rules (building with -t XCODE5).

Slice · April 5, 2016

FYI: snb-platform-id support was requested a few months ago, but you stated it wasn't needed as there are other methods.

And there are already many ways to do this in config.plist.

Yes, there are AddProperties and possibilities to inject this by DSDT/SSDT.

But there is no way to change the property from Clover GUI for first start.

RehabMan · April 5, 2016

But there is no way to change the property from Clover GUI for first start.

That would be a nice feature...

Zenith432 · April 6, 2016

I tried building with -xcode5 toolchain, Xcode 7.3 - build is successful, but when I try to boot either boot6 or boot7 they hang immediately.

I've been trying to compile with clang/xcode but I always get a bootx64.efi that fails to load (black screen on boot). Which version of XCode/clang are you using, and are you making any changes to the Conf files at all (tools_def and build_rules.txt)??

Thanks for your help...

Slice · April 6, 2016

I tried building with -xcode5 toolchain, Xcode 7.3 - build is successful, but when I try to boot either boot6 or boot7 they hang immediately.

Same result.

cecekpawon · April 7, 2016

Reinit boot-args if user switch to another config from GUI-menu?

tluck · April 7, 2016

during attempt to build r3424 with GCC53 (no problem with 4.9) ... get this error? is there another compiler option needed?

FV Space Information
DUETEFIMAINFVX64 [39%Full] 2752512 total, 1098960 used, 1653552 free
- Done -
Build end time: 08:57:09, Apr.07 2016
Build total time: 00:02:06
Compressing DUETEFIMainFv.FV ...
Encoding
Compressing DxeCore.efi ...
Encoding
Compressing DxeIpl.efi ...
Encoding
Generate Loader Image ...
Created /Extra/Clover_Install/CloverGrowerPro/edk2/Build/Clover/RELEASE_GCC53/FV/Efildr64
GenPage...
/Extra/Clover_Install/CloverGrowerPro/edk2/Build/Clover/RELEASE_GCC53/FV/Efildr20Pure: ERROR 16386: Invalid parameter option
Input file size (0x6aa41) exceeds the Page Table Offset (0x68000)
Cloverx64 release ERROR!!

Slice · April 7, 2016

during attempt to build r3424 with GCC53 (no problem with 4.9) ... get this error? is there another compiler option needed?

Input file size (0x6aa41) exceeds the Page Table Offset (0x68000)

Cloverx64 release ERROR!!

Key --std-edba will help.

Somehow gcc53 produces larger codes then gcc49.

Zenith432 · April 7, 2016

Key --std-edba will help.

Somehow gcc53 produces larger codes then gcc49.

It's the code bloat problem of gcc 5.3 that was discussed before. Here's the status on it

max size of Clover EFI for low-ebda is 0x68000. For std-ebda it's 0x70000.
The problem is only in boot6, as boot7 uses less modules and fits in low-ebda.
Personally I've added following line at end of Clover.dsc

  MSFT:*_*_*_CC_FLAGS  = /FAcs /FR$(@R).SBR /wd4701 /wd4703 $(BUILD_OPTIONS)
  XCODE:*_*_*_CC_FLAGS = -Os $(BUILD_OPTIONS) -Wno-msvc-include
  GCC:*_*_*_CC_FLAGS   = $(BUILD_OPTIONS) 
  #-Wunused-but-set-variable
  # -Os -fno-omit-frame-pointer -maccumulate-outgoing-args
  GCC:*_GCC53_*_CC_FLAGS = -Os

This line forces all modules to compile with -Os and makes boot6 fit in low-ebda.
I have not committed this change because I want to study whether it's 1) safe and 2) a good idea.
What I have so far is that I don't know if it's safe. You said -Os produces incorrect code in older version of gcc, but I don't know how to reproduce and test if still happens in gcc 5.3.
As for whether it's a good idea, here's what I found so far...
There are 2 modules compiled with -O3 (AtaAtapi and VBoxHfs). There are about 20 modules compiled with -O0 (no optimization).
I tried changing -O3 to -Os for the two modules, and it reduces the code size by about 20KB, but due to the LzmaCompress, this is not enough to shrink it under low-ebda (the actual uncompressed firmware is about 2.6MB !).
So I started changing the -O0 modules one by one to -Os, but it turned out even after quite a few, the build still doesn't fit in low-ebda!
So eventually I gave up trying to micro-tune the optimization switches, and just left the -Os in Clover.dsc which forces all modules to -Os.
It is still left to discover whether -Os is safe with gcc 5.3.
That's where it stands.

Edit: I committed #3425 to apply -Os, but only for -gcc53 builds of boot6 that are low-ebda.

Edited April 7, 2016 by Zenith432

mhaeuser · April 7, 2016

If the tools_def patches for GCC5 (etc?) are required and well tested, how about sending a patch to edk2-devel?

Slice · April 7, 2016

If the tools_def patches for GCC5 (etc?) are required and well tested, how about sending a patch to edk2-devel?

Did you ever try to send something to edk2-devel? Happy attempts!

Clover Problems and Solutions

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites