Jump to content
ErmaC

Clover General discussion

20,677 posts in this topic

Recommended Posts

Advertisement

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 )-;

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

 

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

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

"Themes will probably be radically different, SVG support, and actual font support."

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Anything that is relied on outside of your project is a dependency. I'm not writing anything that is platform specific, these have all been provided already through protocols from the firmware. Once again, not building firmware. Actually not sure what you mean but I've already solved that problem of the memory, I can't really prevent other stuff from allocate pages where it wants. But overriding AllocatePool and managing memory instead by allocating pages high up and serving from those pages, also allows to keep track of memory leaks. I've written my own libraries and they should be good for all uses, since it's not producing the protocols, they are being consumed.

 

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've reported several bugs, some of which they actually just removed the feature instead of fixing the bug. Like using macros in build files. I just stopped trying...

 

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.

 

I don't see how this is any different than any other build system. I also just don't like the EDK2 build system.

 

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 already said I do not care about building firmware. You could still do this, get the built modules and include them just like the hfsplus.efi driver. And clover2 is still around doing exactly this, maybe it gets modified to be only firmware based and you can pull clover3 in or something, idk....

 

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.

 

I had no plans on making only one driver to do everything. I said that it would be broken up. That's a large problem with clover2, it has a huge chunk of it's stuff built into the GUI and you must have it whether you need or want the feature or not.

 

 

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.

 

No you misunderstand. The drivers themselves are perfectly functional, they can be loaded into the FV and work, they won't attempt to load anything. But when booted from disk there will be a shim, that waits until these drivers are needed then loads them - the shim won't function in the FV because it won't be able to find a file system protocol on it's loaded image device handle. There is no core module, it's protocols, and the protocol is in a library, if it's not found it's installed. The big difference is that if I don't boot macOS they are not loaded, and IDK what you mean by few KB but its probably more like MBs. I've already thought about all this stuff you are saying and they are not issues, they have solutions.

 

 

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

 

Boot services code and data are freed at exit boot services, the problem is the loader code and loader data which are not. And of course everything is dynamically allocated as loader data, and clover is allocated in loader code area. Not very much of this memory is freed.

 

And in case you were wondering what I meant about EDK2 being massive and a nightmare, it takes forever to pull and this is without touching, right after:

post-749318-0-02564100-1511788952.png

Share this post


Link to post
Share on other sites
Anything that is relied on outside of your project is a dependency.

 

 

I was talking about EDK2 as a whole. The actual dependencies are the LibraryClasses you consume, because the rest is either build system or not a dependency as it's not consumed.

 

But overriding AllocatePool and managing memory instead by allocating pages high up and serving from those pages, also allows to keep track of memory leaks. I've written my own libraries and they should be good for all uses, since it's not producing the protocols, they are being consumed.

 

 

So you literally replace Boot Services? Interesting...

 

I don't see how this is any different than any other build system. I also just don't like the EDK2 build system.

 

 

How do you merge two separate drivers into a single one with VS?

 

I had no plans on making only one driver to do everything. I said that it would be broken up. That's a large problem with clover2, it has a huge chunk of it's stuff built into the GUI and you must have it whether you need or want the feature or not.

 

When one driver caln replace ten, I am indeed worried...

 

 

the problem is the loader code and loader data which are not. And of course everything is dynamically allocated as loader data, and clover is allocated in loader code area.

 

Oh, I forgot. Well, don't alloc LoaderCode/Data then?

 

 

And in case you were wondering what I meant about EDK2 being massive and a nightmare, it takes forever to pull and this is without touching, right after:

 

How often do you pull a fresh EDK2? ;P

Share this post


Link to post
Share on other sites

I was talking about EDK2 as a whole. The actual dependencies are the LibraryClasses you consume, because the rest is either build system or not a dependency as it's not consumed.

 

I understand your point of view but I was referring to external project dependencies, meaning relying on outside code. I want to be able to just pull the code for clover and build it. Nothing else.

 

So you literally replace Boot Services? Interesting...

 

Yeah, see no reason why not, only the pages are stored in memory map. There is no harm in replacing the pool allocation and free methods with a different ones.

 

 

How do you merge two separate drivers into a single one with VS?

 

I don't know what you mean, build it differently? Or use ILMerge or something else similar. Also probably never going to do that.....

 

 

When one driver caln replace ten, I am indeed worried...

 

No, lol, I said that the other way around, that you could replace one driver with ten if needed. There doesn't need to be a one to one module replacement.

 

 

Oh, I forgot. Well, don't alloc LoaderCode/Data then?

 

It's the default allocation method for applications in EDK2. An EFI application is always loader code, plus it needs to be since we still want some stuff around after exit boot services. Cleaning up after allocations is probably a much better choice, and maybe only allocating loader data when it must be used. Don't want to go back through and fix allocations or garbage collect in clover2. There's no point.

 

How often do you pull a fresh EDK2? ;P

 

More often than I care to admit, haha. But even still just pulling updates takes a few minutes sometimes and I'm rarely far behind.

Share this post


Link to post
Share on other sites

Yeah, see no reason why not, only the pages are stored in memory map. There is no harm in replacing the pool allocation and free methods with a different ones.

Well, *Pages and GetNemoryMap too, otherwise you'll be out of sync. ;)

 

I don't know what you mean, build it differently? Or use ILMerge or something else similar.

ILMerge is for .NET, but that's the idea, yeah.

 

No, lol, I said that the other way around, that you could replace one driver with ten if needed. There doesn't need to be a one to one module replacement.

Ohh, I said to replace Clover's with Apple's, so ur message sounded like more Apple drivers than Clover ones... Yeah, though I don't know a single Apple module that could just be split, so it's 1:1 either way.

 

It's the default allocation method for applications in EDK2. An EFI application is always loader code, plus it needs to be since we still want some stuff around after exit boot services. Cleaning up after allocations is probably a much better choice, and maybe only allocating loader data when it must be used. Don't want to go back through and fix allocations or garbage collect in clover2. There's no point.

What except for AptioFix needs to survive ExitBS? Dont know anything tbh. And yeah, forget v2 ;)

 

More often than I care to admit, haha. But even still just pulling updates takes a few minutes sometimes and I'm rarely far behind.

Guess having EDK2 on a HDD separate from the OS, a i7-3770 and 50MBit/s spoiled me? ;P No update ever even remotely reached 10s.

Share this post


Link to post
Share on other sites

Well, *Pages and GetNemoryMap too, otherwise you'll be out of sync. ;)

 

I'm using those, why would it be out of sync? I'm using those to allocate the pool memory, as high as possible with AllocateMaxAddress and the address set to 0xFFFFFFFFFFFFFFFF to begin.

 

ILMerge is for .NET, but that's the idea, yeah.

 

Yeah, brain fart, wasn't thinking. Is there a tool that does that in EDK2 base tools? Cause then you can just use that.... I also don't see why you want to merge modules though.

 

Ohh, I said to replace Clover's with Apple's, so ur message sounded like more Apple drivers than Clover ones... Yeah, though I don't know a single Apple module that could just be split, so it's 1:1 either way.

 

I thought you meant firmware modules, but I have no idea man. I'm not going to be going crazy making unnecessary modules just so there's two hundred of them, lol.

 

What except for AptioFix needs to survive ExitBS? Dont know anything tbh. And yeah, forget v2 ;)

 

I think that is a runtime driver. I'm not exactly sure what needs to survive and what doesn't, that was kinda my point. But I'd definitely like it to be as little as possible. Plus good memory management is better anyway.

 

Guess having EDK2 on a HDD separate from the OS, a i7-3770 and 50MBit/s spoiled me? ;P No update ever even remotely reached 10s.

 

I have it on a separate SSD, an overclocked i5-2500K, 16GB overclocked RAM and 100Mbps internet.......... I wish I ever saw below or close to 10s....

 

EDIT: Clover2 builds faster than it takes to pull both EDK2 and clover2....

Share this post


Link to post
Share on other sites

I'm using those, why would it be out of sync? I'm using those to allocate the pool memory, as high as possible with AllocateMaxAddress and the address set to 0xFFFFFFFFFFFFFFFF to begin.

 

Not reliable, all that guarantees is that it won't exceed that address, it doesn't guarantee that it will be the highest address range available below that point

 

Yeah, brain fart, wasn't thinking. Is there a tool that does that in EDK2 base tools? Cause then you can just use that.... I also don't see why you want to merge modules though.

 

It's not a tool, it's done pre-compile. You save space because static libraries are only present once.

 

I have it on a separate SSD, an overclocked i5-2500K, 16GB overclocked RAM and 100Mbps internet.......... I wish I ever saw below or close to 10s....

 

EDIT: Clover2 builds faster than it takes to pull both EDK2 and clover2....

 

lol, pull as in "git pull", so only the diff from the revs newer than yours ;p

Share this post


Link to post
Share on other sites

Not reliable, all that guarantees is that it won't exceed that address, it doesn't guarantee that it will be the highest address range available below that point

 

Seems to be that's what it does in the three firmwares I've run it on. Although, yes I guess you are correct that it doesn't guarantee to be the highest by the spec, just that the entire region is below that address. Oh well, I'll just change it to find the highest region available from the memory map and use AllocateAddress instead.

 

 

It's not a tool, it's done pre-compile. You save space because static libraries are only present once.

 

So, how can this not be done in VS? Seems like it could be easily done, create libraries for the modules and then create modules that use them...

 

 

lol, pull as in "git pull", so only the diff from the revs newer than yours ;p

 

Yes, I'm referring to that as well, that's what pull does. If you don't have anything it's still pulling changes, just all of them. Maybe you just have a better route over the internets, maybe I have more hops to get to the server or something.... Who knows, but I don't want to deal with EDK2 anymore. Especially since it's kinda easier to make modules without it....

 

EDIT: Oh yeah, and without EDK2 you can use C++ (you still need some C for the interaction with the spec), but it's pretty cool. Granted there is no CRT, so you have to be careful about not creating globals and also you need to override new, new[], delete, and delete[] operators to allocate from pool memory.

EDIT2: After some thought it is probably possible to look at the code for the CRT for VS and GCC and build a library that performs these functions and then C++ would probably work almost fully. I know there are some things that wouldn't still though, most of that stuff can be disabled and ignored though.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   1 member

  • Similar Content

    • By Aldaro
      Gigabyte, in their infinite wisdom, decided to remove the option to disable serial ports, and not being able to do so has been causing me some problems. I know that I have to either use a patch in clover, or create a custom SSDT to disable super I/O, but I honestly do not know how to go about doing this. One of the weirder problems I'm experiencing is the inability to connect to Apple Music (error 11556) unless I go into my network settings, and delete my serial connection. If anyone could help me out with this, that'd be greatly appreciated; anyway, thank you for taking the time to read this.
       
      SPECS:
      Mobo GIGABYTE Z390 M GAMING (UEFI F8)
      CPU: i5 9600k
      RAM: 32GB DDR4 @ 2666 Mhz
      GPU: AMD Radeon RX 580 w/ 8GB of VRAM (MSI armor oc edition)
      Storage Samsung 970 evo 500GB
    • By cvad
      View File Bootdisk Utility
      Make bootable USB Flash Disk for MAC OS X with Latest Clover bootloader revision fast and easy by one click! under OS Windows.
      Special utility from cvad & russian MAC community for new hackintosh users.
       
      Enjoy...
       
      For more information and complete instructions please see this topic.
       
       
       
       
      Feel free to "Rate File"
      Submitter cvad Submitted 04/28/2013 Category Bootloaders  
    • By e97
      HackPro X99 System
      Until Apple blesses us with the MacPro7,1 – this is for those that require tools to do their work.
      An appropriate bicycle for the mind.
       
       

       

       

       
      Specs:
       
      CPU: Intel Xeon E5-2678 v3 (12 core, 2.5 GHz / 3.3 GHz Boost)
      Motherboard: SZMZ X99-8D3
      RAM: 16GB DDR3-14900R 1866Mhz ECC RDIMM modules
      GPU: Radeon RX Vega 64 8GB
      Storage: Phison E12 m.2 NVMe PCI-E 3.0 x4 SSD
      Water blocks: BARROW CPU + GPU
      Radiator: 360mm x 25mm slim
      Pump: DDC
       
      Case dimensions: 431 mm x 342 mm x 177 mm
       
       
       
      XCPM OFF
       

       
      XCPM ON
       

       
      OpenCL
       

       
       
       
      iMacPro1,1
       

       
       

       
      OpenCL
       

       
       
      NVMe
       

       
       
      Win 10 x64 v1809
       
      AIDA64 - Cache & Memory
       

       
       
      Download:  https://github.com/xe97/X99-8D3-Clover
       
       
       
       
       
      Anyone else I forgot
       
       
    • By digivish
      Hi All - quick thing - I have a NUC 8i7BEH with 32GB RAM and 2 x 1TB SSD drives. Each drive has its own OS - Windows 10 and Catalina 10.15.
       
      Clover works well - Catalina Boots, so does Windows.
      Catalina - has sound over HDMI (to my monitor's speakers)
      Windows - no audio device found - It does show Realtek and Intel Display Drivers - but the speaker has a red"x" and in Devices, there is no entry for Microphone Array under Audio Input/Output. It does, however, show Intel display over the HDMI - but actually no sound.
       
      I have tried reinstalling Realtek drivers - now here's the thing...when it installs, it first uninstalls existing Realtek drivers - at this stage (and it's important) the sound starts working - as if uninstalling did the trick. As part of the installing, I have to reboot and upon reboot, it actually reinstalls the Realtek drivers. After that, I'm back to square 1. Unsure if it's the config.plist or boot args in clover. But something with Clover for sure.
       
      I have tested this by removing the Mac Drive with clover and just booting directly to Windows 10 bootloader and everything works as it should, I have sound over HDMI and the audio device shows. Just not when I boot with Clover.
       
      has anyone experienced this and have thoughts or pointers.
       
      Thanks a ton!
×