Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30960 posts in this topic

Recommended Posts

RehabMan
RehabMan
Posted
Posted

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.

apianti
apianti
Posted
Posted

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:

 

btn_donateCC_LG.gif

 

Thanks!

 

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

  • Like 6
apianti
apianti
Posted
Posted

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.

nms
nms
Posted
Posted

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

nms
nms
Posted
Posted

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
apianti
Posted
Posted

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.

  • Like 1
smolderas
smolderas
Posted
Posted

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
cecekpawon
Posted
Posted

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
apianti
Posted
Posted

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.

  • Like 1
mhaeuser
mhaeuser
Posted
Posted

 

 

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
  • Like 2
Sherlocks
Sherlocks
Posted
Posted

 

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

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

 

vs Sierra & High Sierra

attachicon.gifBoot 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

Slice
Slice
Posted
Posted

Official 

 

 

UDK2017 is a subset of EDK II applicable to Intel architecture firmware. EDK II covers a broad set of requirements, including obsolete packages or features that can’t be verified on Intel platforms. 

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

Create makefile with one line

./ebuild.sh -t XCODE8

apianti
apianti
Posted
Posted

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

 

Because it's massive and a maintenance nightmare. Clover has duplicated many libraries from EDK2 because the EDK team refuses to fix bugs that are reported to them. I don't know what you mean by loss of ability to combine drivers via DSC, or what FDF has to do with anything. Clover 3 will have no legacy support. Those things are not needed at all.

 

 

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

 

I don't even understand what you mean by this. You mean modifying firmware? What's the difference if you have to replace one driver with ten? Still works right? Yeah...

 

 

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

 

This is kind of what I was talking about, but I don't want to load macOS stuff when I'm booting windows or linux, and vice versa. It's a waste of resources and I don't know what you mean by terrible mess, seems pretty easy to me. As I said you can load the drivers and they will install protocols so if you want to put it in the firmware you can, but also there will be a stub to only load them on demand. I'm thinking about all this trash that gets left behind that no one seems to think matters but I know it does and I can even see in windows and linux that my system memory usage is much higher if I boot through clover compared to from the firmware menu.

  • Like 1
mhaeuser
mhaeuser
Posted
Posted

Because it's massive and a maintenance nightmare.

 

"EDK2" is not a dependecy, it is more of a toolcahin shim. You consume LibraryClasses, which aren't giant, depending on which you refer to. LibraryClasses enable you to write true non-agbostic code, by shimming everything that might be different for a certain build. Do you want to explicitely allocate over 4GB (which would require you to get the memory map on each allocation call as UEFI has no other way than AllocateAddress to ensure you get what you want), when the base firmware does so anyway? That can be eliminated by LibraryClasses. For proper UEFI firmware, use the default EDK2 UefiMemoryAllocationLib and for your normal Craptio fw, use the fixup lib. That is just one of many possible usecases.

 

Clover has duplicated many libraries from EDK2 because the EDK team refuses to fix bugs that are reported to them.

 

Idk what/how you are reporting, but literally every single patch I ever submited, which was not faulty, got merged, no single exception. This includes bug fixes, new code and oh-so-minor compiler improvements in form of conditional directives.

 

I don't know what you mean by loss of ability to combine drivers via DSC

 

You can include a driver's inf in a platform dsc file... if you now include other driver's infs in curly braces relative to the first driver, they will be consumed by the first, i.e. the first driver's EP gets called and then the ones of the 'child ones'. This lets you merges all Clover v3 modules into one, if wished, without adding any kind of 'merge module', maintainance work or whatever.

 

or what FDF has to do with anything. Clover 3 will have no legacy support. Those things are not needed at all.

 

Neither dsc, nor fdf have anything remotely to do with legacy. FDF is the describes the flash file, which is supposed to go onto the Flash Chip (or into the DUET file...). When building one's own fw, one could include the Clover v3 modules via the FDF, if it had an EDK2 inf, without any scripting magic.

 

I don't even understand what you mean by this. You mean modifying firmware? What's the difference if you have to replace one driver with ten? Still works right? Yeah...

 

Keeping the modules separate doesn't give you the ability to make them depend on each other statically, which would lower the risk for a Clover v2 v2 dramatically. If you plan to properly support the Apple protocols, you draw no benefit from having one driver to do several tasks.

 

This is kind of what I was talking about, but I don't want to load macOS stuff when I'm booting windows or linux, and vice versa. It's a waste of resources and I don't know what you mean by terrible mess, seems pretty easy to me. As I said you can load the drivers and they will install protocols so if you want to put it in the firmware you can, but also there will be a stub to only load them on demand.

 

How does that work when the drivers are placed in a FV? You would literally have to build a 'Clover v3 core module' that locates and decodes a proprietary Freeform file from the FV (which ofc requires UEFI PI compliance, which might be safe to assume nowadays, but is not amazingly great practice considering the specs are rightfully separate) and loads the drivers based on... what? Want an own file (with an own GUID) per OS (in case you plan to support multiple OSes, which cannot hurt)? On the HDD, want own folder names? What if a driver needs to do stuff on init and when macOS boots? You need an event there anyway, so what is the exact benefit of loading on demand? Right, you save a handful of KB which get scrapped a few milliseconds later. Furthermore remember, these modules will depend on your 'Clover v3 core module' and will misbehave when not loaded by it, which is not a great scenario in an UEFI environment.

 

I'm thinking about all this trash that gets left behind that no one seems to think matters but I know it does and I can even see in windows and linux that my system memory usage is much higher if I boot through clover compared to from the firmware menu.

 

Fix the problem by the root then and cut BS_data and BS_code from the memory map on GetMemoryMap().

  • Like 1
apianti
apianti
Posted
Posted

Sounds good with GUI, means responsive theme (vector)? But, "No Legacy support"..? Uhmmb..  :rolleyes:

 

Yes, I'm sure you're aware because you make a bunch but the themes are a disaster. There were some mistakes, then I made more in trying to redesign it. The biggest problem is the difference screen size affects a theme, it could look nice, or like complete garbage based on your resolution. That's a pretty blatant {censored} bug. Vector graphics resize well, so should be the method of choice for drawing. Though I'm sure some static sized elements can't be helped. Also I was thinking about allowing themes to have scripting for cooler effects and stuff. Another is I was going to attempt to write an opentype font renderer, which would allow for different sized fonts, colors, style, and most importantly full character sets, lol. No more trying to make those little ridiculous font maps like it came from super nintendo games, hahahaha.

 

What I mean by no legacy support is that I will not be writing a legacy firmware, clover 2 already has legacy firmware. That firmware (or any other legacy emulation firmware) can be installed and used to launch clover 3. No point in rewriting the firmware since it works. Most likely clover 2 will either become legacy emulation firmware only or split into two branches, one firmware and GUI still, the other just firmware. Or maybe not, who knows.....

  • Like 2
Badruzeus
Badruzeus
Posted
Posted

Yes, I'm sure you're aware because you make a bunch but the themes are a disaster. There were some mistakes, then I made more in trying to redesign it. The biggest problem is the difference screen size affects a theme, it could look nice, or like complete garbage based on your resolution. That's a pretty blatant {censored} bug. Vector graphics resize well, so should be the method of choice for drawing. Though I'm sure some static sized elements can't be helped. Also I was thinking about allowing themes to have scripting for cooler effects and stuff. Another is I was going to attempt to write an opentype font renderer, which would allow for different sized fonts, colors, style, and most importantly full character sets, lol. No more trying to make those little ridiculous font maps like it came from super nintendo games, hahahaha.

NP, I started the design from vector based, I love it bcoz it was simpler (I think), and even a free Inkscape.app did the job.  :) Something new has to be learned then, though I could only follow the guides for it. Thanks anyway @apianti.

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