Clover General discussion

[Guest]

@apianti

do you know if it exixts something similar in OSX?

 

https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver

 

In Windows it is possible to update microcode

https://downloadcenter.intel.com/download/26925/Linux-Processor-Microcode-Data-File

[LockDown]

is it bad to install clover legacy on the hfs partition where macOS resides?

[apianti]

I installed Clover in ESP in macOS,after that I packed it to EFI.zip,then I reinstalled Windows 7 x64,I unpacked EFI.zip to ESP,but nothing happened in AMI UEFI Boot Entry,I have to rename bootmgfw.efi to bootmgfw.old(in Ubuntu Live,because bootmgfw.efi is the only boot efi for Windows 7 x64) so that UEFI OS (Clover) Boot Entry is automatic add to AMI UEFI Boot Entry,after that AMI UEFI can Boot Clover,Clover boot bootmgfw.efi,bootmgfw.efi boot Windows 7 x64,.The question is does install Windows 7 x64 under Windows 7 UEFI retail DVD or install Clover under macOS installer automatic add Windows Boot Manager(bootmgfw.efi) or UEFI OS(CLOVERX64.efi)?If I want to manually add them in EFI environment,how to do that?I know that is a stupid question but I don't get any answer on Internet.Thank you.

 

Well, first change your windows back, that's not how to do it. Then boot into ubuntu, to add your boot entry. Get the disk identifier of the disk where the ESP is, usually /dev/sda (but check with disks or gparted). Get the partition number of the ESP, it's usually 1, but if you installed Windows 10 first for some reason windows puts it's recovery before the ESP, so it's 2. Then type this into terminal (remember to change the options for -d and -p):

sudo modprobe efivars
sudo efibootmgr -d /dev/sda -p 1 -c -l "\\EFI\\CLOVER\\CLOVERX64.efi" -L "Clover"

Now restart and you should have another option in your boot menu for clover.

 

@apianti

do you know if it exixts something similar in OSX?

 

https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver

 

In Windows it is possible to update microcode

https://downloadcenter.intel.com/download/26925/Linux-Processor-Microcode-Data-File

 

I am not sure what you mean.... A microcode update is not the same as what you were asking for before. Microcode allows the CPU to be updated if there are errors or manufacturing defects on the chip. Almost every OS has microcode drivers that are used, boot into linux and look at the restricted drivers being used, one will be Intel microcode. Maybe there is microcode that will be able to change what you want, or maybe not. But even if there is it doesn't mean it will work. Give it a try if you want, I don't see the benefit of that much effort for something that isn't really affecting anyone...

 

is it bad to install clover legacy on the hfs partition where macOS resides?

 

It's not bad, you can do it, but that means you are going to lose the ability to do some things. The big one is no disk writing, so no logs or any other dumps. It's a much better idea to install to the ESP that way you don't lose clover if you need to reinstall or an update goes bad or you suddenly get converted to an APFS container without knowing. You should just install to the ESP.... lol

[apianti]

Hey ladies and gentlemen,

 

I am on a new medicine that seems to be working well (at least for now) and I'd like to take this time to try to get some development done on v3. However, here's the dilemma, I need to make money, I can't do both my own business and clover. I want to devote some time like a month or two to nothing but clover v3. If you want this to happen (and you should) please donate some money to me, any amount is helpful. I'm hoping to get enough to take a break from my job entirely while I write this. Anyone who donates will get to give feature requests, do alpha/beta testing (I'm not going to release the source until it's stable, and public betas will be further down the line), my help and eternal gratitude, and maybe a little letter and sticker or something letting you know you rock!

 

Donate to my paypal here:

 

 

 

EDIT: Some donations are coming in, thanks guys! If you donate would you mind sending me a PM so I know that it was you and I can compile a list.

EDIT2: Forgot to mention, this is a business account, so I'm paying the fees, there's no extra charge for a donator.

[Sherlocks]

@cecekpawon

hi, can you check pm? thanks in advance

[zxv]

What's the reasoning for assigning framebuffer Exmoor to 380X in r4318? Lagotto is a perfect match for 380/380X.

[Slice]

What's the reasoning for assigning framebuffer Exmoor to 380X in r4318? Lagotto is a perfect match for 380/380X.

I can make Lagotto but it doesn't exists in ElCapitan.

Anyway there are no perfect matches between DeviceID and Apple's framebuffer. It is a question about connectors and they can be different for different OEM.

[zxv]

I can make Lagotto but it doesn't exists in ElCapitan.

Anyway there are no perfect matches between DeviceID and Apple's framebuffer. It is a question about connectors and they can be different for different OEM.

No problem. Easy enough for me to assign Lagotto manually. Was just curious about the reasoning, and you explained it.

[mitch_de]

Yep, i would also say that Clover should only config most used things (for GPUs) and let special configs made manually by the users.

Also Clover must not include all kind of fixes - they to support over many OS X versions maybe too much and can line into more probs than they fix.

Also too many functions may be a problem for outdated config.plists if some update clover and run into reports " not booting after clover update"... even clover has no bug - they bug is the outdated (wrong) config.plist. Maybe later Clover installer could check config.plist for known missconfigured/ outdated keys, settings at the install process & give at least some warings to look after that.

Or someone which have time, could make an Clover_config_Check tool which checks existing configs for known problems and give advices to fix that?

[maxb2000]

@Slice

 

I have a feature request for Clover and maybe you can implement it:

 

If it's fastboot enabled in the Clover option, then there is no way accessing recovery.

 

So can you make like a 0.5 sec or even smaller delay so it can detected a key like "D" hold down and show the boot selection screen ?

 

Thanks !

[mhaeuser]

@Slice

 

I have a feature request for Clover and maybe you can implement it:

 

If it's fastboot enabled in the Clover option, then there is no way accessing recovery.

 

So can you make like a 0.5 sec or even smaller delay so it can detected a key like "D" hold down and show the boot selection screen ?

 

Thanks !

Just unset fastboot and set Timeout=0.

[WinstonAce]

Something in KextPatch changed (I guess in commit 4305)

now this patch doesn't work (doesn't even appear in debug mode)

it's inside  IO80211Family.kext

<?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>Comment</key>
<string>Wi-Fi Region to 0x64</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>D7eH3AQAAA==</data>
<key>Name</key>
<string>AirPortAtheros40</string>
<key>Replace</key>
<data>uGQAAACQkA==</data>
</dict>
</plist>

[smolderas]

 

Something in KextPatch changed (I guess in commit 4305)

now this patch doesn't work (doesn't even appear in debug mode)

it's inside  IO80211Family.kext

<?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>Comment</key>
<string>Wi-Fi Region to 0x64</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>D7eH3AQAAA==</data>
<key>Name</key>
<string>AirPortAtheros40</string>
<key>Replace</key>
<data>uGQAAACQkA==</data>
</dict>
</plist>

 

I have the same problem, after r4305 or so is kextpatching broken. It says in the log, that it patched, but it does not...

[zxv]

Clover SSDT patches now appear to be occurring after insertion of custom SSDTs (instead of before). Is this expected behavior?

 

e.g.: 

5:576  0:000  === [ ACPIPatchedAML ] ====================================
…
5:576  0:000  Inserting SSDT-AMD.aml from EFI\CLOVER\ACPI\patched: size=463 ... Success
…
5:576  0:000  === [ PatchAllSSDT ] ======================================
…
5:577  0:000  Patch table: SSDT  SSDTAMDG len=0x1CF
…
5:577  0:000  3. [GFX0 → IGPU]: pattern 47465830, patched at: [ (42) (17) ]

[Slice]

Clover SSDT patches now appear to be occurring after insertion of custom SSDTs (instead of before). Is this expected behavior?

 

e.g.: 

5:576  0:000  === [ ACPIPatchedAML ] ====================================
…
5:576  0:000  Inserting SSDT-AMD.aml from EFI\CLOVER\ACPI\patched: size=463 ... Success
…
5:576  0:000  === [ PatchAllSSDT ] ======================================
…
5:577  0:000  Patch table: SSDT  SSDTAMDG len=0x1CF
…
5:577  0:000  3. [GFX0 → IGPU]: pattern 47465830, patched at: [ (42) (17) ]

It is better, isn't it?

[WinstonAce]

Nope...

It should be choosable.

 

Sent from my ONEPLUS A5000 using Tapatalk

[zxv]

It is better, isn't it?

Probably better, yes.

 

I don't mind the change, but you may want to give a heads up in Clover Change Explanations, as it can introduce quirky behavior for custom SSDT users.

 

For instance I've Clover replace GFX0 → IGPU, followed by PEGP → GFX0… but in my AMD SSDT I already had device defined as GFX0, thus it became IGPU. Easy fix though once I realized what was going on.

 

Nope...

It should be choosable.

Nah… I don't think we want special config parameters for myriad possible use cases. Keep it simple.

[WinstonAce]

But it change the current situation, it shouldn't be the default because it can break things for people which already use on the fly patching with appropriate ssdt. (For example renaming gfx0 to igpu and pegp to gfx and ssdt with appropriate names will lead to ssdt with two igpu devices).

 

Sent from my ONEPLUS A5000 using Tapatalk

[nms]

Clover developers,

 

why to make decisions on OSVersion while here is darwin and/or kext binary version?

[Slice]

Clover developers,

 

why to make decisions on OSVersion while here is darwin and/or kext binary version?

It is not a question to developers. It is a question to users why they want to put a kext into /10.x folder instead of Other folder.

Really guys, why? Any reason to use OS specific folder?

[LockDown]

some users installs multiple version of macOS probably

[Slice]

some users installs multiple version of macOS probably

All our kexts are OS independant. 

[WinstonAce]

Something in KextPatch changed (I guess in commit 4305)

now this patch doesn't work (doesn't even appear in debug mode)

it's inside IO80211Family.kext

<?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>Comment</key>
<string>Wi-Fi Region to 0x64</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>D7eH3AQAAA==</data>
<key>Name</key>
<string>AirPortAtheros40</string>
<key>Replace</key>
<data>uGQAAACQkA==</data>
</dict>
</plist> 

Slice, what should we do regarding this case?

 

Sent from my ONEPLUS A5000 using Tapatalk

[nms]

It is a question to developers. It is a question to users why they want to put a kext into /10.x folder instead of Other folder.

Really guys, why? Any reason to use OS specific folder?

Due to confusing name 'Other'? 'common' is more appropriate.

[RehabMan]

Clover SSDT patches now appear to be occurring after insertion of custom SSDTs (instead of before). Is this expected behavior?

 

e.g.: 

5:576  0:000  === [ ACPIPatchedAML ] ====================================
…
5:576  0:000  Inserting SSDT-AMD.aml from EFI\CLOVER\ACPI\patched: size=463 ... Success
…
5:576  0:000  === [ PatchAllSSDT ] ======================================
…
5:577  0:000  Patch table: SSDT  SSDTAMDG len=0x1CF
…
5:577  0:000  3. [GFX0 → IGPU]: pattern 47465830, patched at: [ (42) (17) ]

 

Any SSDTs "added" to the XSDT are ignored for the patching phase (eg. not subject to ACPI/DSDT/Patches).

And with AutoMerge=true, any patched SSTDs (eg. those merged into their respective spot in the XDST), are subject to patching.

 

Look carefully at the code in AcpiPatcher.c:

EFI_STATUS PatchACPI(IN REFIT_VOLUME *Volume, CHAR8 *OSVersion)
{
...
  // RehabMan: Save current Xsdt entry count, as PatchAllSSDT operates on only
  //  original SSDTs or SSDTs that were loaded/merged.
  XsdtOriginalEntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);

and...

VOID PatchAllSSDT()
{
...
  // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
  EntryCount = XsdtOriginalEntryCount;
//  EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);

Probably better, yes.

 

I don't mind the change,

There is no change in behavior intended.

But it change the current situation, it shouldn't be the default because it can break things for people which already use on the fly patching with appropriate ssdt. (For example renaming gfx0 to igpu and pegp to gfx and ssdt with appropriate names will lead to ssdt with two igpu devices).

 

Sent from my ONEPLUS A5000 using Tapatalk

There is no change in behavior intended.

If you think there is a problem, you should provide details.

 

Details would include:

EFI/Clover (without themes, attached as ZIP, make sure F4 is used to generate ACPI/origin)

Clover bootlog

 

There is this code in DropTableFromXSDT that seems to deal (strangely) with NULL pointers in the XSDT:

  for (Index = 0; Index < EntryCount; Index++, BasePtr += sizeof(UINT64)) {
    if (ReadUnaligned64((CONST UINT64*)BasePtr) == 0) {
      if (DoubleZero) {
        Xsdt->Header.Length = (UINT32)(sizeof(UINT64) * Index + sizeof(EFI_ACPI_DESCRIPTION_HEADER));
        DBG("DoubleZero in XSDT table\n");
        break;
      }
      DBG("First zero in XSDT table\n");
      DoubleZero = TRUE;
      Xsdt->Header.Length -= sizeof(UINT64);
      continue; //avoid zero field
    }
    DoubleZero = FALSE;

I'm not 100% convinced that code is correct, but it might make more sense once I see an XSDT with zero entries...

Currently, the code probably does not adjust XsdtOriginalEntryCount correctly in light of this code dealing with NULL entries in the XDST.

 

Note: It seems to me that if there are NULL entries in the XSDT, and these NULL entries somehow cause a problem for macOS/OS X, we should remove them just like we do other entries in the table. I don't see why it is a special case, and I don't see why two zeros in a row should be handled any differently. It is almost as if Clover is trying to treat a double-NULL as some sort of terminator for the XSDT entry array, but I see nothing in the ACPI spec that indicates any such double-NULL termination should be honored. And the code for single NULL, if it were to appear anywhere but at the end of the table, looks truly incorrect.

 

Due to confusing name 'Other'? 'common' is more appropriate.

The behavior of 'Other' used to be that it was used only if a matching version specific directory did not exist.

Of course, the Clover installer would constantly create each version specific directory, so if a user had placed kexts into Other, it was ignored after updating Clover due to the extra directories (previously deleted by the user) being created.

So, 'Other' behavior was changed to act more like one would expect from a directory called 'Always', 'Common', or 'AnyVersion'.