Clover Problems and Solutions

cecekpawon · September 21, 2015

Sadly i was in 3270 already and 3272 right now and problem still persists

0:100  0:000  Starting Clover rev 3272 on American Megatrends EFI
...
16:501  4:614  Using OEM capri.plist at path: EFI\CLOVER\capri.plist
...
26:415  0:000   0 Kexts to patch

cecekpawon · September 21, 2015

Solved by adding line below, in "Settings.c"

GetUserSettings(
  IN  EFI_FILE *RootDir,
      TagPtr CfgDict
      )
{
  ...
    // KernelAndKextPatches
    DictPointer = GetProperty (Dict, "KernelAndKextPatches");
    if (DictPointer != NULL) {
      FillinKextPatches ((KERNEL_AND_KEXT_PATCHES *)(((UINTN)&gSettings) + OFFSET_OF(SETTINGS_DATA, KernelAndKextPatches)), DictPointer);
    }
    SaveSettings();
  }
//DBG ("config.plist read and return %r\n", Status);
  return EFI_SUCCESS;
}

Slice · September 21, 2015

Solved by adding line below, in "Settings.c"

GetUserSettings(
  IN  EFI_FILE *RootDir,
      TagPtr CfgDict
      )
{
  ...
    // KernelAndKextPatches
    DictPointer = GetProperty (Dict, "KernelAndKextPatches");
    if (DictPointer != NULL) {
      FillinKextPatches ((KERNEL_AND_KEXT_PATCHES *)(((UINTN)&gSettings) + OFFSET_OF(SETTINGS_DATA, KernelAndKextPatches)), DictPointer);
    }
    SaveSettings();
  }
//DBG ("config.plist read and return %r\n", Status);
  return EFI_SUCCESS;
}

Sorry,

You said that KernelAndKextPatches should be at bottom of GetUserSettings()? line 4738?

It present at line 2058. :huh:

cecekpawon · September 21, 2015

Hello, im blind in C coding, so dont know which procedure are invoked first
I thought Clover just forgot / incomplete to re-read some of user settings with given new config name from GUI menu after read default config.plist.
Although i solved my problem with patch above, thanks for the answer..

Faradis · September 21, 2015

SaveSettings();
  }
//DBG ("config.plist read and return %r\n", Status);
  return EFI_SUCCESS;
}

maybe this one is added cause i can't find that in clover source

Slice · September 21, 2015

SaveSettings();
  }
//DBG ("config.plist read and return %r\n", Status);
  return EFI_SUCCESS;
} 
maybe this one is added cause i can't find that in clover source

fffeee · September 23, 2015

Clover 3272 cannot boot my Z97 Gryphon workstation, but I am successfully booting it with Clover 3229. It hasn't been bootable with newer builds for quite a while but I'd like to get it squared away before release of 10.11 if I can. I'm using the same config.plist, but this is a photo of the display when I boot into verbose mode with 3272. Symptoms without verbose mode are just a status bar under the logo that appears stuck indefinitely.

I have a zpool with an SSD for zil and l2arc installed on this workstation in addition to the OS and applications SSD which is HFS+.

One thing I found puzzling is that:

## 3272

2:319  0:000  found 39 volumes with blockIO

while

## 3229

3:330  0:000  found 34 volumes with blockIO

Both Clover instances arrive at the Clover GUI correctly and default to the correct boot volume and successfully (apparently insert nvram values and EFI payloads.)

Both get my boot variables as well. Mostly. My config has:

<string>slide=0 darkwake=10 nvda_drv=1 kext-dev-mode=1 keepsyms=y</string>

But both record in preboot:

## 3272

2:608  0:000  found boot-args in NVRAM:kext-dev-mode=1 keepsyms=y nvda_drv=1, size=37

## 3329

3:444  0:000  found boot-args in NVRAM:kext-dev-mode=1 keepsyms=y nvda_drv=1, size=37

So not everything is making it into nvram?

My config.plist is available on pastebin.

I'm not opposed to spamming pastebin urls of my preboot logs if it's relevant, I just don't know how to proceed debugging on my own at this point.

Note: I use RampageDev's SSDT on this workstation and apply Clover-centric fixes for the audio device but I use SPDIF into my audio equipment for digital audio.

AsusFreak · September 23, 2015

3272 works fine here on the same board.

fffeee · September 23, 2015

3272 works fine here on the same board.

Any chance I could eyeball your config and see what I'm doing wrong? I'd hate to think it's my zfs pool confusing things; that would be a big problem for me. I'm not trying to do anything stupid like boot off it or anything so I don't think it's related.

No longer desired, issue was with my SSDT-1 that I believe Toleda's script created? At any rate, removing that file and it's fine. I went back to Voodoo HD for my audio since I only use USB devices and SPDIF anyway.

RehabMan · October 1, 2015

I was working on one of my projects here, starting to use config.plist/ACPI/DSDT/Patches a bit more heavily...

With each patch added, I noticed time to the Apple logo getting longer and longer... as if the simple search/replace in DSDT/Patches was taking a very long time to process.

So... I had a look at the code and discovered a few things...

First in the case of equal sized find/replace, move_data is called with offset=0. In that instance it does not need to move any data

change:

UINT32 move_data(UINT32 start, UINT8* buffer, UINT32 len, INT32 offset)
{
  UINT32 i;
  
  if (offset<0) {
    for (i=start; i<len+offset; i++) {
      buffer[i] = buffer[i-offset];
    }
  }
  else { // data move to back
    for (i=len-1; i>=start; i--) {
      buffer[i+offset] = buffer[i];
    }
  }
  return len + offset;
}

to:

UINT32 move_data(UINT32 start, UINT8* buffer, UINT32 len, INT32 offset)
{
  UINT32 i;
  
  if (offset<0) {
    for (i=start; i<len+offset; i++) {
      buffer[i] = buffer[i-offset];
    }
  }
  else if (offset>0) { // data move to back
    for (i=len-1; i>=start; i--) {
      buffer[i+offset] = buffer[i];
    }
  }
  return len + offset;
}

When offset==0, buffer[i+offset] refers to the same memory location as buffer. The read/store loop is not needed.

OK, but that still didn't improve the performance significantly, so I started looking closer at FixAny.

  for (i = 20; i < len; i++) {
    adr = FindBin(dsdt + i, len, ToFind, LenTF);

FindBin searches for ToFind at the data pointed at by dsdt+i for len bytes. The len is the entire length of the AML. Note that len is not adjusted to account for the starting point of the search. Hence it is searching (and potentially replacing) beyond the bounds of the AML being patched.

Corrected code:

  for (i = 20; i < len; i++) {
    adr = FindBin(dsdt + i, len - i, ToFind, LenTF);

And some attention to the loop here...

  for (i = 20; i < len; i++) {
    adr = FindBin(dsdt + i, len - i, ToFind, LenTF);

FindBin searches the entire AML for the pattern, so this loop (between the two bugs mentioned above) is O*N^2...

Since FindBin returns the index of the found pattern, there is no need to search data prior to the end of the replacement data on subsequent iterations.

Tweaked loop:

  for (i = 20; i < len; ) {
...
    i = i + adr + LenTR;
  }

Essentially, we can skip past the end of the replacement and search from that point to the end...

But we need to deal with the case that LenTR is zero, as code higher in the call hierarchy does not check.

From:

   BOOLEAN found = FALSE;
   if (!ToFind) {
     return len;
   }

To:

   BOOLEAN found = FALSE;
   if (!ToFind || !LenTF || !LenTR) {
     return len;
   }

Please do check my work.

I'm testing it and it is working for me (all expected patches are still applied as before), but it is faster. Ummm... a LOT faster.

The full diffs (against v3277) are here:

Speedy-OSX:Clover RehabMan$ svn diff
Index: rEFIt_UEFI/Platform/FixBiosDsdt.c
===================================================================
--- rEFIt_UEFI/Platform/FixBiosDsdt.c	(revision 3277)
+++ rEFIt_UEFI/Platform/FixBiosDsdt.c	(working copy)
@@ -1077,7 +1077,7 @@
       buffer[i] = buffer[i-offset];
     }
   }
-  else  { // data move to back        
+  else if (offset>0) { // data move to back
     for (i=len-1; i>=start; i--) {
       buffer[i+offset] = buffer[i];
     }
@@ -1687,7 +1687,7 @@
   INT32 sizeoffset, adr;
   UINT32 i;
   BOOLEAN found = FALSE;
-  if (!ToFind) {
+  if (!ToFind || !LenTF || !LenTR) {
     return len;
   }
   DBG(" patch pattern %01x%01x%01x%01x\n", ToFind[0], ToFind[1], ToFind[2], ToFind[3]);
@@ -1696,8 +1696,8 @@
     return len;
   }
   sizeoffset = LenTR - LenTF;
-  for (i = 20; i < len; i++) {
-    adr = FindBin(dsdt + i, len, ToFind, LenTF);
+  for (i = 20; i < len; ) {
+    adr = FindBin(dsdt + i, len - i, ToFind, LenTF);
     if (adr < 0) {
       if (!found) {
         DBG("  bin not found\n");
@@ -1712,6 +1712,7 @@
     }
     len = CorrectOuterMethod(dsdt, len, adr + i - 2, sizeoffset);
     len = CorrectOuters(dsdt, len, adr + i - 3, sizeoffset);
+    i = i + adr + LenTR;
   }
 
   return len;

Also, whoever accepts this might want to fix this small cosmetic (but potentially confusing) problem:

-  DBG(" patch pattern %01x%01x%01x%01x\n", ToFind[0], ToFind[1], ToFind[2], ToFind[3]);
+  DBG(" patch pattern %02x%02x%02x%02x\n", ToFind[0], ToFind[1], ToFind[2], ToFind[3]);

Slice · October 1, 2015

@RehabMan

Thanks for the analysis.

I'll accept your propositions when I return home.

RehabMan · October 1, 2015

Here's another for you.

Problem: Devices/Arbitrary is broken.

Problems:

- in most cases, it causes a hang before reaching the Apple logo. Endless loop is the problem.

- fixing the looping bug, bogus data is injected due to using the wrong index (i vs. PropIndex)

- zero length data properties are not accommodated (needed for PinConfigurations injection on HDA)

Index: rEFIt_UEFI/Platform/Settings.c
===================================================================
--- rEFIt_UEFI/Platform/Settings.c	(revision 3277)
+++ rEFIt_UEFI/Platform/Settings.c	(working copy)
@@ -403,7 +403,7 @@
     
   Prop = GetProperty (Dict, PropName);
   if (Prop != NULL) {
-    if (Prop->data != NULL && Prop->dataLen > 0) {
+    if (Prop->data != NULL /*&& Prop->dataLen > 0*/) { //rehabman: allow zero length data
       // data property
       Data = AllocateZeroPool (Prop->dataLen);
       CopyMem (Data, Prop->data, Prop->dataLen);
@@ -3557,7 +3557,7 @@
               
               for (PropIndex = 0; PropIndex < PropCount; PropIndex++) {
                 UINTN Size = 0;
-                if (!EFI_ERROR (GetElement (Dict2, i, &Dict3))) {
+                if (!EFI_ERROR (GetElement (Dict2, PropIndex, &Dict3))) {
                   
                   DevProp = gSettings.AddProperties;
                   gSettings.AddProperties = AllocateZeroPool (sizeof(DEV_PROPERTY));
@@ -3583,7 +3583,7 @@
                     //else  data
                     gSettings.AddProperties->Value = GetDataSetting (Dict3, "Value", &Size);
                     gSettings.AddProperties->ValueLen = Size;
                 }
                // gSettings.NrAddProperties++;
               }   //for() device properties
@@ -5246,6 +5246,7 @@
           }
           while (Prop) {
             if (Prop->Device != PCIdevice.dev.addr) {
+              Prop = Prop->Next;
               continue;
             }
             if (Once) {
Index: rEFIt_UEFI/Platform/device_inject.c
===================================================================
--- rEFIt_UEFI/Platform/device_inject.c	(revision 3277)
+++ rEFIt_UEFI/Platform/device_inject.c	(working copy)
@@ -211,7 +211,7 @@
   UINT32 *datalength;
   UINT8 *newdata;
   
-  if(!device || !nm || !vl || !len)
+  if(!device || !nm || !vl /*|| !len*/) //rehabman: allow zero length data
     return FALSE;
   /*	DBG("devprop_add_value %a=", nm);
    for (i=0; i<len; i++) {

sebinouse · October 3, 2015

I edited my SSDT :

EHC1 > EH01

EHC2 > EH02

XHC > XHC1

And add your kext to /EFI kext folder

And it seems to work !!! Thanks a lot !

So it was not really Clover related ...

I changed my mind and tried other solutions to get vanilla support for my USB ... I just added :

<key>ACPI</key>
	<dict>
		<key>DSDT</key>
		<dict>
...
			<key>Fixes</key>
			<dict>
				<key>FixShutdown_0004</key>
				<true/>
			</dict>
		</dict>
...

And it worked ... so it was Clover related (DSDT in fact) !

All my USB port are handled by XHC though ... but at the right speed so I don't mind

fffeee · October 5, 2015

And it worked ... so it was Clover related (DSDT in fact) !

All my USB port are handled by XHC though ... but at the right speed so I don't mind

Which is more likely: your USB ports are working because of a kernel extension and SSDT change you made, or the addition of a completely unrelated DSDT patch mask to Clover that adds a method to _PTS at shutdown?

cecekpawon · October 6, 2015

With this way, i could force clover to detect ~~& inject~~ my intel even as 2nd display (nvidia as primary)

0:100  0:000  PCI (00|01:00.00) : 10DE 0FC6 class=030000 | 03 00 PCI_CLASS_DISPLAY_VGA
0:100  0:000  Found NVidia model=MSi GeForce GTX 650
0:100  0:000  PCI (00|01:00.01) : 10DE 0E1B class=040300
0:100  0:000  PCI (00|00:02.00) : 8086 0162 class=038000 | 03 80 PCI_CLASS_DISPLAY_OTHER
0:100  0:000  Found GFX model=Intel HD Graphics 4000

--- /Original/Settings.c 2015-12-17 10:48:29.000000000
+++ /Patch/Settings.c 2015-12-04 19:43:49.000000000
@@ -5039,12 +5039,14 @@
             Pci.Hdr.ClassCode[0]
             );

         // GFX
         if ((Pci.Hdr.ClassCode[2] == PCI_CLASS_DISPLAY) &&
-            (Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA) &&
+            ((Pci.Hdr.ClassCode[1] == (PCI_CLASS_DISPLAY_VGA)) ||
+            (Pci.Hdr.ClassCode[1] == (PCI_CLASS_DISPLAY_OTHER))) &&
             (NGFX < 4)) {
           GFX_PROPERTIES *gfx = &gGraphics[NGFX];
           gfx->DeviceID       = Pci.Hdr.DeviceId;
           gfx->Segment        = Segment;
           gfx->Bus            = Bus;
           gfx->Device         = Device;
@@ -5290,12 +5292,14 @@
                Bus, Device, Function);
           continue;
         }
         // GFX
         if (/* gSettings.GraphicsInjector && */
             (Pci.Hdr.ClassCode[2] == PCI_CLASS_DISPLAY) &&
-            (Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA)) {
+            //(Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA)) {
+            ((Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA) || (Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_OTHER))) {
           UINT32 LevelW = 0xC0000000;
           UINT32 IntelDisable = 0x03;

//        gGraphics.DeviceID = Pci.Hdr.DeviceId;

Edit: with rev 3330

Edited December 17, 2015 by cecekpawon

sebinouse · October 6, 2015

Which is more likely: your USB ports are working because of a kernel extension and SSDT change you made, or the addition of a completely unrelated DSDT patch mask to Clover that adds a method to _PTS at shutdown?

I don't know and i can't see a method to determine this. Those two configurations work:

- Nothing USB related (except cosmetic USB by SSDT, no EHC1>EH01, no dummy/Rehabman's kext ...) + Clover "Shutdown Fix"

- SSDT edit (EHC1>EH01 ...) + Rehabman's kexts (no clover shutdown fix)

fearandleb · October 6, 2015

Hi,

Clover 3270 (Release) on X9Dai Dual CPU/PCI-Bus Motherboard with El Capitan (Release) reports only half of Memory Slots AND half of Memory.

In Yosemite, amount of Memory was ok, but also only half of the slots was reported. The Slot Detection Mechanism changed after Clover 3113, before Clover detected 16 Slots.

Secondly, I assume related to this Bug, the El Capitan System reports (hardwired) PhysMem: 16T used (16T wired), 86G unused. VM: 754G vsize, 467M framework vsize, so somehow the reported Physical Memory falls back to the maximum amount of addressable Memory as a static value. The 86G unused are connected to my total amount of Ram (96GB) i assume, so this is weird.

Attached is Darwindumper output and Screenshot of Activity Monitor.

If anyone needs more information, please post.

Thanks,

000_2015-10-05_21-41-49_MacPro5,1.zip

Riley Freeman · October 7, 2015

I mentioned this bug in the general discussion but as it's now the sole cause for me to use SSDT injection I'll bring it up here as well.

My P9X79 doesn't have a HDEF device in the DSDT. With FixHDA and Devices\Audio\Inject properties set in Clover's config it creates the HDEF device and properties, but in the wrong path. It should be PCI0\HDEF but instead it creates it in PCI0\^UNC0\HDEF. As a result audio doesn't work.

On my P8Z68 which has a HDEF device the same config entries work fine. Clover just injects the values for layout-id, pinconfig etc into the existing device.

The issue appears to be when Clover has to create the device entry from scratch.

WinstonAce · October 7, 2015

You don't need dsdt fix for audio.

You can inject audio under devices

http://clover-wiki.zetam.org/Configuration/Devices#Audio

Slice · October 7, 2015

My P9X79 doesn't have a HDEF device in the DSDT. With FixHDA and Devices\Audio\Inject properties set in Clover's config it creates the HDEF device and properties, but in the wrong path. It should be PCI0\HDEF but instead it creates it in PCI0\^UNC0\HDEF.

I think this is a right path. Look ioreg.

Riley Freeman · October 7, 2015

Thanks for the feedback guys.

@Slice: There's no HDEF device in IOReg with Clover injection. Only when the device is injected via SSDT.aml (see attachments).

@WinstonAce: As far as I know (from looking at the Wiki) Devices\Audio is for injecting the layout-id. It won't create the HDEF device itself.

Slice · October 7, 2015

Thanks for the feedback guys.

@Slice: There's no HDEF device in IOReg with Clover injection. Only when the device is injected via SSDT.aml.

@WinstonAce: As far as I know (from looking at the Wiki) Devices\Audio is for injecting the layout-id. It won't create the HDEF device itself.

What is the device ^UNC0?

It looks like it is the same PCI0 just in shred of DSDT.

Some DSDT is shredded into small pieces and Clover can't correctly calculate a path.

In such cases it is good to make own DSDT.

WinstonAce · October 7, 2015

I think it should work, or you can try with properties (xml --> hex) injection.

Riley Freeman · October 7, 2015

@Slice: I've no idea what it is. But that's where Clover has decided to inject the HDEF device.

I know it can be fixed by DSDT/SSDT injection but I've managed to move all of the fixes I made using SSDT to Clover's config.plist. Now the only fix I still need a SSDT for is HDEF because of this path issue.

@WinstonAce: I tried with just Devices\Audio\Inject=1 but as I suspected, it didn't work. The core of the issue is lack of a HDEF device.

WinstonAce · October 7, 2015

What about EFI string injection?

let's say your HDEF(with ssdt) is under pci0@0 at 1B

you need to inject something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
  <dict>
      <key>layout-id</key>
      <string>0x00000001</string>
   </dict>
</dict>
</plist>

which in HEX is

e80000000100000001000000dc0000000500000002010c00d041030a0000000001010600001b7fff04001c0000007200650076006900730069006f006e002d00690064000000080000000100000018000000760065006e0064006f0072002d006900640000000800000086800000180000006c00610079006f00750074002d00690064000000080000000c0000002c000000730075006200730079007300740065006d002d00760065006e0064006f0072002d0069006400000008000000581400001e000000730075006200730079007300740065006d002d006900640000000800000002a00000

in clover you'll need to add this

<key>Devices</key>
<dict>
<key>Inject</key>
<true/>
<key>Properties</key>
<string>e80000000100000001000000dc0000000500000002010c00d041030a0000000001010600001b7fff04001c0000007200650076006900730069006f006e002d00690064000000080000000100000018000000760065006e0064006f0072002d006900640000000800000086800000180000006c00610079006f00750074002d00690064000000080000000c0000002c000000730075006200730079007300740065006d002d00760065006e0064006f0072002d0069006400000008000000581400001e000000730075006200730079007300740065006d002d006900640000000800000002a00000</string>
</dict>

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