Jump to content

Clover General discussion


ErmaC
29,866 posts in this topic

Recommended Posts

BTW, I am also the author of iBored, a GUI disk editor that works on OSX, Windows and Linux. I've added special features to it over the years whenever I needed something (such as support for iPodLinux). If any of you can think of features that help with Hackintosh or Clover, let me know. I'm happy to help.

  • Like 1
Link to comment
Share on other sites

Oh, so that's another misunderstanding of mine about how Clover works. That means that Clover is NOT implementing its own EFI-"BIOS" then but uses the one on the board (made by AMI)? I thought Clover is a "RealEFI", and thus would have full control over the entire communication between the EFI drivers and the EFI "OS"?

 

Well, I still have some holes in understanding how BIOS, EFI, and the particular implementations on PCs and Macs work. You wouldn't know of some good intro articles on that, would you?

Clover package has two related files

boot == modified DUET == CloverEFI implementation. Used in legacy boot.

CloverX64.efi == GUI may works with UEFI BIOS or with CloverEFI

Link to comment
Share on other sites

https://github.com/CupertinoNet/ApplePkg

Oh, so that's another misunderstanding of mine about how Clover works. That means that Clover is NOT implementing its own EFI-"BIOS" then but uses the one on the board (made by AMI)? I thought Clover is a "RealEFI", and thus would have full control over the entire communication between the EFI drivers and the EFI "OS"?

 

Well, I still have some holes in understanding how BIOS, EFI, and the particular implementations on PCs and Macs work. You wouldn't know of some good intro articles on that, would you?

 

Clover is an UEFI application and not some FakeEFI what-so-ever... and in contrast to what everyone else 'says', there is no 'legacy Clover'. For UEFI emulation on legacy systems, a modded DUET (from the EDK2 project) is used which directly starts the Clover app.

 

Check these words. ;)

Regarding intro articles:

Here you can get a quick overview of the UEFI phases.

Here you can see some Apple-specific stuff.

And otherwise, read parts of the UEFI specification. It's long, but you don't need to know what each and every protocol does, it's enough if you have an idea what the phases do specifically. Furthermore, check EDK2 for reference code.

  • Like 4
Link to comment
Share on other sites

Depends on what you mean by 'bug'. No, long device paths will still be buggy, but you can now add short via 'addp' instead of 'add'.

It will be good if it is.

Link to comment
Share on other sites

Clover sources should be written in EDK2 code style.

Look, please, https://github.com/tianocore/tianocore.github.io/wiki/Code-Style-C

(this site has temporary problems now)

I see you don't use tab, in fact each indentation is different from what you can see in a normal C code in a unix system. Did you use any editor in particular to do that?

Link to comment
Share on other sites

Thanks, will look into the article you linked to. That'll shut me up here for a while ;)

 

A clarification first, though:

 

Clover is an UEFI application and not some FakeEFI what-so-ever... and in contrast to what everyone else 'says', there is no 'legacy Clover'. For UEFI emulation on legacy systems, a modded DUET (from the EDK2 project) is used which directly starts the Clover app.

 

1. Clover is an application that uses UEFI as its OS. It interferes with the boot process only so much as to set parameters and call some functions. But it does not intercept or provide UEFI functions.

 

2. Who reads the config.plist? I guess Clover (and not the UEFI OS) does that, and it uses it to set said params etc.

 

3. When I boot a Hackintosh from EFI, then that means it's done by the UEFI code installed on my board's EFI ROM.

 

4. So, when I do a legacy boot, then a custom UEFI OS is loaded (via boot code in MBR/PBR), and that's called DUET. Which is under our full control and that allows us also to avoid the AptioFix issue. When, then, do we not always use the legacy boot if we can? That should avoid so many problems, right?

Link to comment
Share on other sites

To the end a legacy booter can load the kernel/kernelcache/kexts and patch it before be in the memory-map.. so there's no need to reallocate anything...appear to be easier.

But easy != better


I mean that you cannot boot Windows UEFI in UEFI mode if you boot legacy (I'm wrong? :huh: ..sorry no Win here). With Clover you can (but emulate UEFI.. so is no longer really UEFI :jester: ).

Finally Clover let you have your choice

 

both boot boot.efi with Clover in OSX.

Link to comment
Share on other sites

Thanks, will look into the article you linked to. That'll shut me up here for a while ;)

 

A clarification first, though:

 

 

1. Clover is an application that uses UEFI as its OS. It interferes with the boot process only so much as to set parameters and call some functions. But it does not intercept or provide UEFI functions.

 

2. Who reads the config.plist? I guess Clover (and not the UEFI OS) does that, and it uses it to set said params etc.

 

3. When I boot a Hackintosh from EFI, then that means it's done by the UEFI code installed on my board's EFI ROM.

 

4. So, when I do a legacy boot, then a custom UEFI OS is loaded (via boot code in MBR/PBR), and that's called DUET. Which is under our full control and that allows us also to avoid the AptioFix issue. When, then, do we not always use the legacy boot if we can? That should avoid so many problems, right?

 

1. UEFI is not an OS mate, it's a firmware interface. Yes, Clover does not provide or interfere with UEFI functions, though some of its drivers, such as AptioFix, do.

2. Yes, it is Clover that reads config.plist.

3. Yes. And by the way, it's usually not a ROM, but NVRAM (i.e. writable freely in constrast to (EEP)ROM).

4. Legacy boot is slower and lacks NVRAM support. It's best to use what is provided. ottherwise it is: UEFI -> emulates legacy -> boot DUET -> loads TianoCore UEFI -> boots OS.

  • Like 2
Link to comment
Share on other sites

1. UEFI is not an OS mate, it's a firmware interface.

 

To me, who started with Apple ][ and VC-20, that UEFI looks quite the OS - it provides most of the basic requirements an OS offer: Resource (cpu, memory, hardware access) allocation and control. Anything more is just fancy stuff an OS doesn't need to provide but delegates to its drivers :)

An interface is just a declaration of interoperability. An OS and a kernel _implement_ interfaces.

 

Unles I really still misunderstand what UEFI does (still didn't get to read that all, still trying to get my HackMac going properly). Anyway, you've answered all my questions, thanks a lot!

  • Like 1
Link to comment
Share on other sites

To me, who started with Apple ][ and VC-20, that UEFI looks quite the OS - it provides most of the basic requirements an OS offer: Resource (cpu, memory, hardware access) allocation and control. Anything more is just fancy stuff an OS doesn't need to provide but delegates to its drivers :)

An interface is just a declaration of interoperability. An OS and a kernel _implement_ interfaces.

 

Unles I really still misunderstand what UEFI does (still didn't get to read that all, still trying to get my HackMac going properly). Anyway, you've answered all my questions, thanks a lot!

There is a lot missing from UEFI if you were trying to consider it a modern OS.

  • Like 2
Link to comment
Share on other sites

An OS and a kernel _implement_ interfaces.

 

There is exactly the point, there is no kernel! UEFI is not meant to have permanent control over the hardware. UEFI PI (everything until BDS) is primarily meant for 1) platform initialization 2) exposing information for the OS to grab 3) Recovery in case of failure. BDS is the last 'active' UEFI phase, and its purpose is to determine and load an OS loader. If it finds an OS loader, UEFI Boot Services will be terminated. If it finds a normal UEFI app, system will be in TSL (as described in the phase list) and continue to launch the next one it finds when control is returned.

 

I agree, it has many of the features and characteristics of an OS, but it does not have a central kernel and is not meant to be the permanent owner of the system. Everything it provides is centered around pre-boot tasks.

  • Like 3
Link to comment
Share on other sites

'Clover boot Options' (did I get that right?) is for UEFI boot option management.

"Clover Boot Options".

 

I don't understand why there's a "Clover Boot Options" for each installation of Clover when all the menu items appear to do the same thing (am I wrong?) The first menu item (heading? - not selectable) states the location of the Clover installation. This appears to be the only difference between each of the "Clover Boot Options" menus.

Then there's

"Add Clover boot options for all entires"

"Remove all Clover boot options"

"Print al UEFI boot options to log"

"Delete all duplicate UEFI boot options" (that's one I added - not useful if you've fixed the duplicate entries problem by adding a Clover boot entry)

"Return"

Link to comment
Share on other sites

I see you don't use tab, in fact each indentation is different from what you can see in a normal C code in a unix system. Did you use any editor in particular to do that?

Yes, Xcode

Screen Shot 2016-07-07 at 22.43.48.png

To the end a legacy booter can load the kernel/kernelcache/kexts and patch it before be in the memory-map.. so there's no need to reallocate anything...appear to be easier.

But easy != better

I mean that you cannot boot Windows UEFI in UEFI mode if you boot legacy (I'm wrong? :huh: ..sorry no Win here). With Clover you can (but emulate UEFI.. so is no longer really UEFI :jester: ).

Finally Clover let you have your choice

 

both boot boot.efi with Clover in OSX.

My computer #4 in signature, pure old style PC BIOS based, can boot Window7-64 in UEFI mode with legacy Clover by /EFI/microsoft/boot/bootmgfw.efi located in the same EFI partition as Clover.

  • Like 1
Link to comment
Share on other sites

Should work now

attachicon.gifCLOVERX64.efi-3593.zip

Almost perfect : patch is skipped if MatchOS not set ... Is it normal ? ( I thought it was the opposite )

macOS 10.12.DP2
sw_vers -productVersion 10.12
Clover r3593

MatchOS   not set            skipped > not OK
MatchOS   10.12              OK
MatchOS   10.12.x            OK
MatchOS   10.11.x            OK 
MatchOS   10.11.x,10.12      OK 
MatchOS   10.11.x,10.12.x    OK

Link to comment
Share on other sites

MatchOS not set skipped > not OK

No, it should be corrected.

 

MatchOS 10.11.x OK

 Is it OK?
 


"Clover Boot Options".

...
"Delete all duplicate UEFI boot options" (that's one I added - not useful if you've fixed the duplicate entries problem by adding a Clover boot entry)
"Return"

It will be interesting to add this option. Can you give me it?

Link to comment
Share on other sites

Morning folks, finally have a day off work so though I would create a new partition for testing Sierra PB   :thumbsup_anim:

 

Other than building the latest Clover and copying kexts to 10.12 folder is there anything obvious I need to do (I am trying to catch up with this thread but it moves so fast at the moment   :construction: )?

Link to comment
Share on other sites

×
×
  • Create New...