Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3205 posts in this topic

Recommended Posts

Slice
Slice
Posted
Posted

Nope. I can assure this is not users' issues. Maybe Clover bug. But not reading config.plist...

 

Ah necessary? I don't own SKL models. Here is the EFI folder of my DIY (Configurations, please check my signature.) if necessary: (I just kept the main part to reduce the archive size.)

attachicon.gifCLOVER.zip

Cuz you are't currently using a Dell Skylake. As I said. Seems other models don't have this bug.

It is not Clover bug as I show you. And Dell Skylake will not influence on Clover's calculations.

 

@syscl

Instead of printf(..) you can use DBG(...) to print into boot.log or Print(L"bla-bla...\n", args); to print on screen.

AsciiStrCopy() defined in EDK2 sources.

PMheart
PMheart
Posted
Posted

It is not Clover bug as I show you. And Dell Skylake will not influence on Clover's calculations.

 

@syscl

Instead of printf(..) you can use DBG(...) to print into boot.log or Print(L"bla-bla...\n", args); to print on screen.

AsciiStrCopy() defined in EDK2 sources.

Ah. In this case this could be hardware issues.

PMheart
PMheart
Posted
Posted

How hardware issue may influence on AsciiStrCopy()? Is it using commands that will not work on Skylakes?

Sorry have no condition to test... @syscl may tell. But it seems only Dell SKL have this bug, other models like Asus don't. So maybe hardware problems..

RehabMan
RehabMan
Posted
Posted

How hardware issue may influence on AsciiStrCopy()? Is it using commands that will not work on Skylakes?

The issue is not with AsciiStrCopy.

My suggestion: Let someone that can reproduce the problem investigate/debug fully.

RehabMan
RehabMan
Posted
Posted

May be hardware problems. Like a restriction powered by motherboard.

Not really a "hardware problem", but more likely a problem specific to the code in UEFI firmware on these particular computers.

Sherlocks
Sherlocks
Posted
Posted

Why is matching on the binary name broken?

I used binary name in previous clover like you. But you should use full name in latest clover. It changed to recognize name. Some patches happen not work .So i changed binary name to full name in KextsToPatch for latest clover.

 

나의 LG-F410S 의 Tapatalk에서 보냄

RehabMan
RehabMan
Posted
Posted

I used binary name in previous clover like you. But you should use full name in latest clover. It changed to recognize name. Some patches happen not work .So i changed binary name to full name in KextsToPatch for latest clover.

 

나의 LG-F410S 의 Tapatalk에서 보냄

It is fine to support matching on the bundle name (I assume by "full name", you mean "bundle name").

But for backward compatibility, matching on binary name should still be supported.

Otherwise, you will break essentially every config.plist that exists...

  • Like 2
PMheart
PMheart
Posted
Posted

Why is matching on the binary name broken?

Seems not broken. Just my preference to use full signature instead of name.

It is fine to support matching on the bundle name (I assume by "full name", you mean "bundle name").

But for backward compatibility, matching on binary name should still be supported.

Otherwise, you will break essentially every config.plist that exists...

It seems that KextToPatch works as below now:

==> If use short name then will patch the kext and its dependencies (But typically the dependencies do not contain the byte values we want to patch.).

==> If use full/bundle name then will patch the kext itself only.

Obviously. The latter is a speed-up way. And more precise.

RehabMan
RehabMan
Posted
Posted

Seems not broken. Just my preference to use full signature instead of name.

Imposing your preference while breaking compatibility with a large body of existing ocnfig.plist files seems like a huge mistake.

And not nice.

 

It seems that KextToPatch works as below now:

==> If use short name then will patch the kext itself and its dependencies (But typically the dependencies do not contain the byte values we want to patch.).

That's how it used to work. Evidently not any more.

 

==> If use full/bundle name then will patch the kext itself only.

Obviously. The latter is a speed-up way. And more precise.

This is fine, but we can already do it the "more precise/faster" way simply by presenting the full name.

No change was required in Clover to effect this optimization.

PMheart
PMheart
Posted
Posted

Imposing your preference while breaking compatibility with a large body of existing ocnfig.plist files seems like a huge mistake.

And not nice.

 

 

That's how it used to work. Evidently not any more.

 

 

This is fine, but we can already do it the "more precise/faster" way simply by presenting the full name.

No change was required in Clover to effect this optimization.

Nope. The idea is not powered by me. And also. This is not committed by me. And the old way still works.

 

Tried only use AppleHDA (for example) yesterday. And all works fine. Support both. Nevertheless... Only need to patch AppleHDA on my model, other kexts not tested.

 

Yes. Seems that Clover r3956 just brought a more strict way for KextToPatch. Nothing more.

artur_pt
artur_pt
Posted
Posted

hello

 

true should support old config way .. if u want to use other way .. clover will give u that choice ..

 

only is giving problems in old working config .. and so many in use ..

 

for me don't work the bin patch for the wifi.. don't use applehda

 

thanks

RehabMan
RehabMan
Posted
Posted

And the old way still works.

Reports are that the old way does not work.

For example it is common to use AirPortBrcm4360 to patch bundle com.apple.driver.AirPort.Brcm4360

 

Tried only use AppleHDA (for example) yesterday. And all works fine. Support both.

As should be expected with StrStr on the bundle name.

StrStr for AppleHDA matches com.apple.driver.AppleHDA.

But StrStr for AirPortBrcm4360 does not match on com.apple.driver.AirPort.Brcm4360

 

It seems that matching on the binary name was removed. It should be restored to original functionality.

 

Note that you still get a "family effect" even if you specify the complete bundle name...

Because StrStr for com.apple.driver.AppleHDA matches on com.apple.driver.AppleHDAController

 

If we want strict matching on bundle name (exactly), we should add a new property to the dict instead of overloading the Name property.

eg.

BundleName: if specified, will match strictly against the bundle-id (StrCmp)

  • Like 2
PMheart
PMheart
Posted
Posted

Reports are that the old way does not work.

For example it is common to use AirPortBrcm4360 to patch bundle com.apple.driver.AirPort.Brcm4360

 

 

As should be expected with StrStr on the bundle name.

StrStr for AppleHDA matches com.apple.driver.AppleHDA.

But StrStr for AirPortBrcm4360 does not match on com.apple.driver.AirPort.Brcm4360

 

It seems that matching on the binary name was removed. It should be restored to original functionality.

I see. That's the problem with the bundle name of AirPortBrcm4360 cuz the name of itself and its bundle name don't match. But AppleHDA not and then the patch for AppleHDA will work whereas AirPortBrcm4360 will not.

 

BTW this more strict way is coded by @FredWst. Try to @Slice and revert back.  :) 

PMheart
PMheart
Posted
Posted

hello

 

sorry i wait for Slice answer to this .. but last days several bad commits in clover sources

 

inject kext .. kext_patcher .. nothing new and only problems

 

thanks

Ah all right. No. Actually kext_patcher.c changed in 3956.

@artur_pt

Hi. May have a try with this? (Compiled based on r3957 but with the kext_patcher.c of r3955)  :)

 

 

 

PMheart

 Share
Go to topic listing
×
×
  • Create New...