Just an idea from VBoxFs: injection of FakeSMC on file system driver level for booting CD install. They have fsw_hfs_inject() call, but unfortunately not implemented. Plus "blacklisting of certain files on FS driver level" (AppleIntelCPUPowerManagement.kext).

Using HomeBrew and my script ( CloverBrewer) which utilises cbuild.sh for Clover and a modified cbuildrEFIt.sh for rEFIt
I have successfully built Clover IA32/X64 using gcc4.63.
Have tested boot(X64) and CLOVERX64.efi.Seems to work ok.No names in rEFIt though??

My script does this: (short rant about Homebrew or goto Then:)

Using Homebrew (brew) you can install/uninstall all sorts of things.
e.g
binutils:
To install: brew install binutils, brew will do its thing: (Downloading, installing etc)
To uninstall: brew uninstall binutils.
Done..

Then:
Utilises HomeBrew and installs 'brew' if NOT found. (HIGHLY recommend installing it)
installs: binutils, gmp, libmpc, mpfr
These are depends for gcc-4.6.3.tar.bz2, so if there NOT there they INSTALLED.
Then installs gcc-4.6.3.tar.bz2 (latest and greatest.
Using 'brew install PATHTO/gcc463.rb --use-gcc
Then continues with script

Builds IA32 and X64 versions of Clover/rEFIt ( 2 1/2 minutes)
Copies boot to Media/Bootloaders/(IA32/X64)/boot.

IT will prompt you to copy your EFI folder to Media if NOT there and wait for keypress.

Copy said folder to Media , and press any key,and it will:

Make devicestrings, strings.dat and places it into Media/EFI/devices/
Copy Clover(IA32/X64).efi to Media/EFI/BOOT
Make you a cup of coffee.

IT is auto set to gcc46 (X64/IA32) release.
Just rm the Build folder, it will know its NOT there and do a cleanall
otherwise it does a clean, then builds.
Don't know if the cleanall/clean is necessary, i.e can X64 settings build IA32??

Anybody want to test, preferably on clean system, just let me know.
I Love Homebrew, which is my MAIN reason for using my own script to buildstrap the other scripts.

@slice
Is there a switch for pciroot (0/1) or do i need to edit dsdt.
also memory not showing correctly in System Profiler.

Thanks slice, your doing great job.

Will iron out the bugs, if any and upload it.

It is a bug of VBoxHfs driver. I will think how to correct this.


Yes, this is already implemented, just not announced

About memory I think it is a bug in SMBIOS that Clover is still not corrected.
I had such a bug with older revision but with rev314 all is fine for me.

It looks to be possible because boot.efi uses our HFS driver to load kexts.
There is a best way to influence on the driver is to implement a new protocol like we did with APPLE_GETVAR_PROTOCOL.
But there must be our own protocol and VboxHfs should connect to it.
If the hfs driver got a command to read files from s/l/e it can first load drivers from EFI/kexts (through the protocol calls) and then return back to involved functions.
This will not work if kernelcache loaded.
Or may be implement adding extra-kexts to kernelcache on the fly? What is the structure of the kernelcache?

Load FakeSMC instead of CpuPM?

For me, on 32bit, the VBoxHFS built same way as dmazar described in #907 (and also using jadran's new build script and GCC46), appears to be much slower to read kernel and startup mkext, compared to the "old" MP2,1 binary version (based purely on how fast the read progress goes on the screen). Although perhaps I'm doing something wrong. The resulting VBoxHFS.efi is around 20kB vs 19kB for the others, but the resulting boot file is around 3kB smaller than when using the old HFS binary. But it does boot.

Speaking of loading without caches: was iBoot EFI able to inject kexts on ExitBootServices?

If this is not doable, then your suggestion to override file system driver on EFI level seems like a doable solution. Separate driver (that can even be loaded from /EFI/drivers) that intercepts boot.efi's request for HFS file system and inserts it's own implementation. This implementation just redirects calls to real HFS driver to real volume, or, in case of S/L/E, additionally reads entries from clover's volume and injects them into result. This could work with any HFSPlus.efi.

Did not go into details, but seems doable. But it could be used only when forcing booting without caches, like CD install. And then ... new versions are not comming on a CD any more.

I see a problem. HFS driver gets many calls from boot.efi. At what moment we should perform our action?

yes its possible to inject kexts in OnExitBootServices event with some limitations, you have to load them before the event occurs.

Are you working on it?

I see the first steps like this:

boot.efi should first get EFI_SIMPLE_FILE_SYSTEM (FS) protocol with BS->OpenProtocol (or maybe some other protocol discovery method?). then should call FS->OpenVolume to get EFI_FILE_PROTOCOL. It should then use this EFI_FILE_PROTOCOL.Read for reading dirs and files.

So, probably OpenProtocol should be taken and when request for EFI_SIMPLE_FILE_SYSTEM comes for HFS volume handle different then clover's it should create it's own implementation with OpenVolume. When this OpenVolume is called, then it should return it's own implementation of EFI_FILE_PROTOCOL.

Alternative is to change EFI_FILE_PROTOCOL implementation directly in VBoxHfs.

One more issue: independent (out of clover) drivers would not know which is clover's volume. So clover would need to publish it somehow, or this override should be made inside clover.

It is slower to me also. Plus still does not have volume label support. Extracted HFSPlus.efi looks like a better choice after all.

boot.efi may call OpenVolume several times. We don't know exactly. The most interesting moment is when it open dir SLE. At this moment we can rewrite the dir contents to contain FakeSMC and then override reading it from our cache created before.

There is no problem to publish resources and Clover volume. As I said before we can implement own protocol to have a connection between boot.efi and clover.

I am still not working on the problem, just discuss if it possible.

About VBoxHfs I don't see it is slow and Volume Label Support will be added.

I think, that with vboxhfs clover moves away from grey zone...

really should rewrite the HFS driver to be native, rather than use the convoluted methods used in VBoxHFS and VBoxIso9660 etc.

the code is pretty bad ie copies structures when ptrs should be used.

Managed to override EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and EFI_FILE_PROTOCOL on boot volume and as a side effect get trace of how boot.efi is reading files.

I'll leave it here - maybe somebody will find something useful in there.
 BootEfi_FS_Trace.zip ( 25.5K ) Number of downloads: 20

Sounds great, STLVNUB. I would like to test your script. I agree that Homebrew is an awesome way to build software that has dependencies.

The binaries available in the first post don't seem to be able to hand over control to the kernel. It loads the KEXTs (either from kernel cache or from /S/L/E fine, but afterwards the machine simply reboots.

I have tried with and without graphics injector and also with and without my custom DSDT.

This is on a GA-Z68MX with an i7 2600, 16GB RAM, and booting Lion 10.7.3 from an internal SSD.

Although the EFI shell lists all my volumes just fine (3 drives with multiple partitions each), Clover can only see the first partition of the first drive. All drives are SATA in AHCI mode.

Ok, good to hear someone else likes "HOMEBREW". at least it won't make you drunk.
Find attached CloverBreweryTool v0.0.
[attachment=4188:CloverBreweryTool.zip]
If you can test it on a Clean system, that would be great.
The script will check for HomeBrew and download/install if not found.
It will do same for wget and git.( well hopefully anyway)

Script will update brew and proceed to ' brew install gcc463'
If all goes well, it will then make a Media folder containing Bootloader and EFI folders for later use.
It will also dump device strings, strings.dat to Media/EFI/devices.

CloverBrewery auto builds both IA32 and X64 (GCC46 of course) versions of Clover/rEFIt and places Clover boot files into Media/Bootloader/(IA32/X64)
It places CLOVERIA32.efi and CLOVERX64.efi into Media/EFI/BOOT
Keeps logs in folder LOGS as well.

Build time is under 3 minutes here.

May be some bugs, but works great from here and can/will be be vastly expanded/improved.

Enjoy.

This post has been edited by STLVNUB: Mar 18 2012, 12:33 AM

Hi STLVNUB

I thought I'd try your CloverBreweryTool on a fresh installation of 10.8 DP2.

So to report back to you, the first issue is /usr/local doesn't exist.
Here's output from Terminal:

I didn't continue any further for now. I'll test this for you as and when you provide updates

Thanks STLVNUB.

I have tried to run your script, but not gotten to a successful compilation.

I get stuck at the point where the script goes to town and actually starts building EDK2:


I suppose that you have GCC installed in /opt/local/ia32 and /opt/local/x64 from a manual installation following Slice's instructions, whereas your script does not seem to install anything to this location.

I have also made some changes to give the user the option to install Homebrew into the current directory instead of /usr/local. I think this is very useful because some people don't want anything in /usr/local because it typically conflicts with binary installations.
I have attached my modified version.
 CloverBreweryTool.command.zip ( 3.46K ) Number of downloads: 5

It would be great if you could enhance your script such that it builds everything in the current directory.

Thanks zhell, though I had to made a couple of tweaks to overcome a couple of problems:
- Add the CopyToClover folder from STLVNUB's CloverBreweryTool folder.
- Add the following after the else in function main() because I was getting an $BREW_PREFIX unbound variable error.



I think this applies here too as I see this: