Clover General discussion

[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'.

[Slice]

Slice, what should we do regarding this case?

 

Sent from my ONEPLUS A5000 using Tapatalk

Check this_kext.info.plist->BundleIdentifier

[WinstonAce]

Thanks.

Just tried and it seems to work.

 

 

Sent from my ONEPLUS A5000 using Tapatalk

[RehabMan]

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

@WinstonAce

@zxv

 

I do hope someone with this issue will post the requested data.

I'd like to see what is actually in your XSDT and EFI/Clover.

[WinstonAce]

I didn't noticed it myself (I'm on older version of clover), I was just replaying to zxv comment on new behavior of patching (which now I understand hasn't changed).

 

Sent from my ONEPLUS A5000 using Tapatalk

[apianti]

Hey everyone,
 
Thanks for your donations. I feel like I have received enough to warrant devoting some initial time to working on clover version 3, which I have begun doing. I am keeping a list of donors, so I can hopefully thank them with some sort of clover themed gift. If you haven't, please donate so I can continue to work on this and hopefully create a better user experience:

 

 

Thanks!

 

EDIT: If you do donate please PM me so I can add you to the list.

[nms]

Well,

why to chase the very latest edk2? What wrong staying on stable UDK2017, for example?

[apianti]

Will V3 be embedded into FW like Ozmosis, or is that too big a task?

Would be great if it was.IMHO ( which don't mean much,  apparently)

 

It will be modular, so yes, you will be able to take modules and put them in firmware if you wanted. Which also means you can add and remove modules for functionality. Also I am trying to make no dependencies, edk2 is not being used. The only potential dependency might be openssl (depending for safe boot support) besides of course a compiler. I am only using VS solution at this point but I imagine setting up the build for Xcode or makefile build for macOS/linux wouldn't be too hard.

 

Well,

why to chase the very latest edk2? What wrong staying on stable UDK2017, for example?

 

Are you asking why clover2 syncs with the lastest edk2 revision? Because there are bug fixes among other stuff. The issue usually comes when the patches used for the legacy firmware no longer work correctly because the code was changed too much. Sometimes there is other bug in code but that happens all the time in all code in every project.

[Slice]

Agree, UDKxxxx is not more bugless then current EDK2.

[nms]

Agree, UDKxxxx is not more bugless then current EDK2.

Are you telling me -- bugs (new features and capablities aside) discovered do not backported to UDK2017?

 

Look at this https://github.com/tianocore/tianocore.github.io/wiki/UDK2017 and this https://github.com/tianocore/edk2/commits/UDK2017

[Slice]

UDK is stable and not updatable.

EDK2 is updated every day.

[cecekpawon]

What nms trying to say is: UDK2017 was released in June 2017. With last commit on Oct. So yes, they keep UDK2017 uptodated sometimes

[nms]

UDK is stable and not updatable.

EDK2 is updated every day.

Who said UDK(2017) is not updatable? Had you seen my udk2017 pointers?

 

EDK2 updated every day with brand new features, bugs, ...

 

Chasing TWO constantly moving targets (edk2 and macos) is tough hobby )-;

[apianti]

Are you telling me -- bugs (new features and capablities aside) discovered do not backported to UDK2017?

 

Look at this https://github.com/tianocore/tianocore.github.io/wiki/UDK2017 and this https://github.com/tianocore/edk2/commits/UDK2017

 

You said it right there it's backported, so there's a much longer waiting time. Guess where it's backported from? EDK2. So it's just a matter of getting fixes when they are committed to the code base instead of waiting for releases.

 

 

UDK is stable and not updatable.

EDK2 is updated every day.

 

UDK is backported from EDK2, so it is updated just not nearly as often.

 

What nms trying to say is: UDK2017 was released in June 2017. With last commit on Oct. So yes, they keep UDK2017 uptodated sometimes

 

Yeah, the releases are updated at some schedule but it's definitely not recent.... I wonder if they even backport everything or just select fixes.

 

 

Who said UDK(2017) is not updatable? Had you seen my udk2017 pointers?

 

EDK2 updated every day with brand new features, bugs, ...

 

Chasing TWO constantly moving targets (edk2 and macos) is tough hobby )-;

 

So is clover... Just don't update until you want to then.... lol. You don't need to upgrade most of the time, sometimes, yes, but not usually.

[smolderas]

It will be modular, so yes, you will be able to take modules and put them in firmware if you wanted. Which also means you can add and remove modules for functionality. Also I am trying to make no dependencies, edk2 is not being used. The only potential dependency might be openssl (depending for safe boot support) besides of course a compiler. I am only using VS solution at this point but I imagine setting up the build for Xcode or makefile build for macOS/linux wouldn't be too hard.

 

 

Are you asking why clover2 syncs with the lastest edk2 revision? Because there are bug fixes among other stuff. The issue usually comes when the patches used for the legacy firmware no longer work correctly because the code was changed too much. Sometimes there is other bug in code but that happens all the time in all code in every project.

Please make it so, that it could be build within Xcode...

[cecekpawon]

It will be modular ..

 

So do you like to separating Gui as an tiny app and other stuffs as drivers? That would be great man!

 

I wonder if they even backport everything or just select fixes.

 

Only some pkgs I believe. Idk if they have huge impacts with current patches distributed by Clover..

[apianti]

Please make it so, that it could be build within Xcode...

 

I'll look into it. Not sure if Xcode can target EFI directly like VS can. Can always just use a makefile project though so it will work somehow...

 

So do you like to separating Gui as an tiny app and other stuffs as drivers? That would be great man!

 

Yes, everything separated so that you only need to have what you want. Also managing memory better, trying to keep as much memory as possible below 4GB free. The configuration is not static (that was in my EDK2 based code which I scrapped). Getting rid of the external dependencies, especially EDK2 (should make building much easier and faster). And allowing drivers and other application/tools to interact with the GUI to add their own options and dialogs and such. Themes will probably be radically different, SVG support, and actual font support. This stuff is going to have to roll out in stages though, lol.

 

EDIT: I want to come up with a way to have stub images to detect when you are starting an OS to load the remaining images needed only before starting the OS loader. Like just a tiny driver that detects you are going to start boot.efi, so it loads an smbios driver, patcher drivers, boot fix, etc, then instead of when initializing the GUI. Although, that may put a wrinkle in the embed in firmware people's plans.... Although I guess that those could be protocols, and be loaded already... Eh could probably think of something to make it work.

[mhaeuser]

 

 

Getting rid of the external dependencies, especially EDK2 (should make building much easier and faster).

How is getting rid of EDK2 a good thing? Duplicate code, loss of library classes, loss of the ability to combine drivers via the dsc, loss of direct fdf inclusion...

Also I propose you stick to the Apple scheme of drivers so they are exchangable with the orig blobs.

 

EDIT: I want to come up with a way to have stub images to detect when you are starting an OS to load the remaining images needed only before starting the OS loader. Like just a tiny driver that detects you are going to start boot.efi, so it loads an smbios driver, patcher drivers, boot fix, etc, then

Plz don't load on demand, that will be a terrible mess. Rather always load all drivers and let them register named event hooks in their EP for macOS boot

[Sherlocks]

 

FakeSMC failing to load?

 

 

 

The installer path to boot.efi on the "Boot OS X" partition for Fusion Drives changed from /System/Library/CoreServices/boot.efi (in El Capitan) to /com.apple.boot.R/boot.efi (in Sierra & High Sierra)...

 

El Capitan

Boot OS X and com.apple.boot.S for El Capitan install.png

 

vs Sierra & High Sierra

Boot OS X and com.apple.boot.R for HSierra install.png

 

 

sorry-off topic

hi, can you test boot in fusion drive installer? just test whether boot

vit9696 asked this test.

 

thanks in advance.

Lilu.kext-no prelinked test.zip

Lilu.kext-prelinked test.zip