Jump to content
Micky1979

Build_Clover.command, another Script to build standard Clover (or customized)

1,805 posts in this topic

Recommended Posts

Advertisement

@Sherlocks: If you were using CGP or another tool before trying out Micky's script, make sure you start with a fresh src folder. You might run into issues otherwise.

 

It's better to let it start from scratch.

Share this post


Link to post
Share on other sites

@droples that is a message printed by boot1f32 (or its "alt" variant) and not by boot3/6/7, I can't see nothing wrong with it (otherwise you will see "b1f: error"). What do you mean?

 

Hi Micky! Good work.

I should explain here.

Different variants of boot file boot1/3/6/7 exists to have a possibility choose one at startup by pressing a digit 1/3/6/7 as well as other digits or letter. Letter has a problem of case and keyboard.

We can make as follow

boot1 = Chameleon

boot2 = ntldr --- I don't know if it can work such way ;)

boot3 = CloverEFI 32 bits

boot6 = CloverEFI 64 bits

All this assignments are arbitrary, you can use them other way. Just remember what is what.

Currently Clover package has follow assignments

boot3 = CloverEFI 32 bits

boot6 = CloverEFI 64 bits

boot5 = CloverEFI 64 bits LOW_EBDA

boot7 = CloverEFI 64 bits LOW_EBDA USE_BIOS_BLOCKIO

boot8 = CloverEFI 64 bits USE_BIOS_BLOCKIO

 

All of them should inform user who is who and print on the screen one digit as you see on droples screen

 

b1f: init5

b1f: init comes from boot1f32 sector PBR

5 comes from boot5.

(I am sorry I was lazy to correct boot6 to print "6" it still printed "5" and boot7 printed "L", boot8 printed "B")

I will be glad if someone correct all of them.

This symbol is located at the begin of boot file at offset 0xa9. Hex 0x35 means "5", hex 0x42 means "B" and so on. Can be corrected at clover build script by, for example, dd command.

Share this post


Link to post
Share on other sites

Hi Micky! Good work. 

 

Thanks  :)

 

b1f: init5

b1f: init comes from boot1f32 sector PBR

5 comes from boot5.

(I am sorry I was lazy to correct boot6 to print "6" it still printed "5" and boot7 printed "L", boot8 printed "B")

I will be glad if someone correct all of them.

This symbol is located at the begin of boot file at offset 0xa9. Hex 0x35 means "5", hex 0x42 means "B" and so on. Can be corrected at clover build script by, for example, dd command.

 

done   :lol:, that should work:

#!/bin/bash

#s1 is the path to boot5, boot6, boot7 etc

setInitBootMsg (){

    local byte="35"
    case "${1}" in
    *boot2)
        byte="32"
    ;;
    *boot3)
        byte="33"
    ;;
    *boot4)
        byte="34"
    ;;
    *boot5)
        byte="35"
    ;;
    *boot6)
        byte="36"
    ;;
    *boot7)
        byte="37"
    ;;
    *boot7-MCP79)
        byte="4d"
    ;;
    *boot8)
        byte="38"
    ;;
    *boot9)
        byte="39"
    ;;
    *)
        return;
    ;;
    esac

    if [[ -f "${1}" ]]; then
        printf "\x${byte}" | dd conv=notrunc of="${1}" bs=1 seek=$((0xa9))
    fi
}

setInitBootMsg "${1}"

.. maybe can be inserted in ebuild.sh in both X64 and IA32 statement?

# Install CloverEFI file
echo "Copy CloverEFI:"
copyBin "${BUILD_DIR}"/FV/boot "$CLOVER_PKG_DIR"/Bootloaders/x64/$cloverEFIFile
setInitBootMsg "$CLOVER_PKG_DIR"/Bootloaders/x64/$cloverEFIFile
....

# CloverEFI
copyBin "${BUILD_DIR}"/FV/boot "$CLOVER_PKG_DIR"/Bootloaders/ia32/$cloverEFIFile
setInitBootMsg "$CLOVER_PKG_DIR"/Bootloaders/ia32/$cloverEFIFile 

PS boot7-MPC79 ??  "b1f: initM" is ok?

 

EDIT

replacement is ok, to be tested booting-up the PC..

Share this post


Link to post
Share on other sites

New v2.9:

 

  • v2.9: added back -mc flag for boot7 in standard compilation.
  • v2.9: boot7-MPC79 removed from building when use custom macro.

 

@droples, this should fix the nuance you show me, please let me know

Share this post


Link to post
Share on other sites

looks ok, no?

EDIT
 
BTW you got an error downloading Clover:

svn: E000002: Can't open file '/Users/droplets/src/edk2/Clover/.svn/pristine/16/16ee93d446191bdfffd6efb43928ba9da2931d3a.svn-base': No such file or directory

That happen if you try to build the same src folder (with different subversion), i.e. in different OSX version. Here how to cure: http://stackoverflow.com/questions/18627616/cannot-upgrade-svn-cant-open-directory-svn-text-base-no-such-file-or-direct

Share this post


Link to post
Share on other sites

I'm sorry I did not see. These were problems with the Internet.

 

attachicon.gifnew_logCompile_build_clover2.9.txt.zip

 

PS

For personal use, I removed section (# build for chipset only NVIDIA NFORCE-MCP79 cloverEFI.64.blockio2 package) from  buildpkg.sh.

attachicon.gifwithout_blockio2.jpg

attachicon.gifwithout_blockio2.zip

 

Try this one,  build only boot6 if you select "x64 only",  skipping MCP79 blockio2 without touch the source.

Also added as default, for standard compilation, the "-D NO_GRUB_DRIVERS_EMBEDDED" flag, as should be for all architectures (I think, Slice can confirm..please).

To test this, you have to restore the original buildpkg.sh (just delete it and update Clover using option 2, and will be restored).

Build_Clover.command_v3.0.zip

Share this post


Link to post
Share on other sites

Try this one,  build only boot6 if you select "x64 only",  skipping MCP79 blockio2 without touch the source.

Also added as default, for standard compilation, the "-D NO_GRUB_DRIVERS_EMBEDDED" flag, as should be for all architectures (I think, Slice can confirm..please).

To test this, you have to restore the original buildpkg.sh (just delete it and update Clover using option 2, and will be restored).

Build_Clover.command_v3.0

Yes, MCP79   in the Installer is not visible.

post-617057-0-32691100-1471173837_thumb.jpg

Build_Clover3.0_boot6.txt

Share this post


Link to post
Share on other sites

Thanks :) , v3.0 added at the Download section!

 

 

  • v3.0: added "-D NO_GRUB_DRIVERS_EMBEDDED" for standard compilations. 
  • v3.0: skip boot7-MCP79 for "x64 only" builds (thanks droples).

Share this post


Link to post
Share on other sites

 

Thanks :) , v3.0 added at the Download section!

 

 

  • v3.0: added "-D NO_GRUB_DRIVERS_EMBEDDED" for standard compilations. 
  • v3.0: skip boot7-MCP79 for "x64 only" builds (thanks droples).

 

Your 3.0 post still downloads 2.9

Share this post


Link to post
Share on other sites

New v2.9:

 

  • v2.9: added back -mc flag for boot7 in standard compilation.
  • v2.9: boot7-MPC79 removed from building when use custom macro.

 

@droples, this should fix the nuance you show me, please let me know

No, -mc flag doesn't produce boot7-MPC79. It was added because this is one of old boot files that really works with MCP79. Any new Clover can and I don't know why.

This question requires additional development.

Share this post


Link to post
Share on other sites

Yep, I mean for normal boot7:

./ebuild.sh -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE5

'-mc' was removed by mistake.

 

About boot7-MCP79 I see that is already compiled, the script only make a temporary backup (boot7-MCP79.back) so that buildpkg.sh cannot find it... and the choice is not added to the package. That only if you add macros, or you want a package with boot6 only (as for @droples post), normal compilation of the pkg instead contains all boot6, 7 and MCP79.

 

did you see that post about fix the init message, is ok for you?

Share this post


Link to post
Share on other sites
#define FIRMWARE_VERSION "2.31"
#define FIRMWARE_BUILDDATE "2016-08-14 13:16:44"
#define FIRMWARE_REVISION L"3696"
#define REVISION_STR "Clover revision: 3696"
#define BUILDINFOS_STR "Args: ./ebuild.sh -ia32 -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE5 | Command: build -D NO_GRUB_DRIVERS_EMBEDDED -D USE_LOW_EBDA -p Clover/Clover.dsc -a IA32 -b RELEASE -t XCODE5 -n 5 | OS: 10.11.6 | XCODE: 7.3.1"
 

ebuild.sh is called more than one time and "Version.h" is re-created each times, and the bad is that FIRMWARE_BUILDDATE and BUILDINFOS_STR change, is that the problem ?

Yes can be done automatically or we can use additional args to be received by ebuild.sh so we can also decide to update only some line, just let me understand better your intention.

Share this post


Link to post
Share on other sites
#define FIRMWARE_VERSION "2.31"
#define FIRMWARE_BUILDDATE "2016-08-14 13:16:44"
#define FIRMWARE_REVISION L"3696"
#define REVISION_STR "Clover revision: 3696"
#define BUILDINFOS_STR "Args: ./ebuild.sh -ia32 -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE5 | Command: build -D NO_GRUB_DRIVERS_EMBEDDED -D USE_LOW_EBDA -p Clover/Clover.dsc -a IA32 -b RELEASE -t XCODE5 -n 5 | OS: 10.11.6 | XCODE: 7.3.1"
 

ebuild.sh is called more than one time and "Version.h" is re-created each times, and the bad is that FIRMWARE_BUILDDATE and BUILDINFOS_STR change, is that the problem ?

Yes can be done automatically or we can use additional args to be received by ebuild.sh so we can also decide to update only some line, just let me understand better your intention.

 

The bad thing is ebuild.sh rebuild all modules even if they are not actually changed.

I recompiled Clover several times per day and I don't want to wait all modules to be recompiled again and again.

Additional arg is simplest way but not the best.

Produce ver.txt, compare it with old_ver.txt, if differ then produce Version.h  :rolleyes:

Share this post


Link to post
Share on other sites

compiled with Xcode 8  with Clover_command v3.0 = ok

 

0:100  0:000  Starting Clover revision: 3705 on American Megatrends EFI
0:100  0:000  Build with: [Args: ./ebuild.sh -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE5 | Command: build -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -p Clover/Clover.dsc -a X64 -b RELEASE -t XCODE5 -n 3 | OS: 10.12 | XCODE: 8.0]

Share this post


Link to post
Share on other sites

The bad thing is ebuild.sh rebuild all modules even if they are not actually changed.

I recompiled Clover several times per day and I don't want to wait all modules to be recompiled again and again.

Additional arg is simplest way but not the best.

Produce ver.txt, compare it with old_ver.txt, if differ then produce Version.h  :rolleyes:

Hi Slice try this one:

ebuild.sh.zip

it skip the autogen of newer makefiles each time (the option is provided by edk2 in build.py), so that now all is rebuilted based on timestamp/guid/sha etc (I guess), and here is a lot faster.

...that only if local version differ from the one in:

"~/src/edk2/Clover/rEFIt_UEFI/Version.h".

and offcourse if exist (sign that Clover was at least compiled once).

 

The first time the revision did not match, behave as usual and so everything is rebuilted from scratch. Please test.

 

EDIT

here is the same + it also correct the init message for boot3, boot6, boot7 etc. Tested and working:

b1f: init7  :lol: 

ebuild.sh.zip

 

EDIT II

if that help we can add an argument to override this new default behavior, so that "SkipAutoGen" get skipped by force.

Usually when build my programs in Xcode for distribution I want to be sure that everithing is cleaned and done from scratch as per some limitations like when adding for example new header(s) in the project and/or I have more stuff to be linked.

Share this post


Link to post
Share on other sites

compiled with Xcode 8  with Clover_command v3.0 = ok

 

0:100  0:000  Starting Clover revision: 3705 on American Megatrends EFI

0:100  0:000  Build with: [Args: ./ebuild.sh -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE5 | Command: build -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -p Clover/Clover.dsc -a X64 -b RELEASE -t XCODE5 -n 3 | OS: 10.12 | XCODE: 8.0]

thanks for testing this script! 

Share this post


Link to post
Share on other sites

Hi Slice try this one:

attachicon.gifebuild.sh.zip

it skip the autogen of newer makefiles each time (the option is provided by edk2 in build.py), so that now all is rebuilted based on timestamp/guid/sha etc (I guess), and here is a lot faster.

...that only if local version differ from the one in:

"~/src/edk2/Clover/rEFIt_UEFI/Version.h".

and offcourse if exist (sign that Clover was at least compiled once).

 

The first time the revision did not match, behave as usual and so everything is rebuilted from scratch. Please test.

 

EDIT

here is the same + it also correct the init message for boot3, boot6, boot7 etc. Tested and working:

b1f: init7  :lol: 

attachicon.gifebuild.sh.zip

 

EDIT II

if that help we can add an argument to override this new default behavior, so that "SkipAutoGen" get skipped by force.

Usually when build my programs in Xcode for distribution I want to be sure that everithing is cleaned and done from scratch as per some limitations like when adding for example new header(s) in the project and/or I have more stuff to be linked.

It works but no new effect.

I change one line and expected one file will be recompiled.

Screen Shot 2016-08-18 at 7.33.53.png

I didn't remember why we have two files

"$CLOVERROOT"/rEFIt_UEFI/Version.h

"$CLOVERROOT"/Version.h

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   0 members

    No registered users viewing this page.

  • Similar Content

    • By fusion71au
      Run Vanilla OS X El Capitan, Sierra, High Sierra or Mojave in VirtualBox 5.x.x on a Windows Host
      Following on from my previous guide on how to create a VMware virtual machine running Vanilla OS X El Capitan in Windows, I’ve decided to write a similar guide for creating a VirtualBox El Capitan VM. 
       
      The virtual machine should be useful for testing El Capitan and also for creating installers for use on a real machine/hackintosh.
       
      There are other tutorials and videos on the net about running OS X on Windows machines using pre-made VMDK disk images but you can never guarantee what else is in there….
       
      I’ve gathered info for this guide from several threads in the Multibooting and Virtualisation section of this forum and also the wider internet eg
       
      @colt2 HOW TO: Create a bootable El Capitan ISO for VMware
      @dsmccombs comment on faking Ivybridge Processor
      @E:V:A http://forum.xda-developers.com/showpost.php?p=55572430&postcount=6
      @Tech Reviews video tutorial https://www.youtube.com/watch?v=t7X07U63lwg.
      VirtualBox Forum: Status of OSX on OSX
       
      Requirements
         Intel PC with four or more CPU cores running Windows 7 X64 or later OS (2 or more cores needed for OS X)    4GB or more RAM (2GB or more will be needed for OS X)    Hard Disk with at least 40GB free for Virtual Machine    Oracle VM VirtualBox v 5.0.34    Install OS X El Capitan app and Mac or Hack to prepare installation iso <-- Now, no longer necessary to have previous access to a Mac or Hack by building the Installer.app from scratch - see post#75    16GB or larger exFAT formatted USB stick to transfer El Capitan iso from Mac/Hack to Host PC  
      Prepare Installation ISO on your Mac or Hack
      1.  On your Mac or Hack, download "Install OS X El Capitan.app" from the App Store into your Applications folder.
      2.  Download and unzip the CECI.tool (attached to this post) into your ~/Downloads folder. The commands in this executable script are shown below for informational purposes.  Note: you will need approx 16GB of free space on your hard disk for the script to complete.
       
       
       
      3.  Open OS X terminal, then run the following commands to execute the script:
      cd downloads chmod +x CECI.tool ./CECI.tool 4.  At the end of the process, you will have an El Capitan iso on your desktop - copy this onto an exFAT formatted USB for use on the PC Host later.
       
       
      Create an El Capitan Virtual Machine in VirtualBox
      1.  Open the VirtualBox program and click the "New" button to create a new VM.
       

       
      2.  Select Mac OS X and Mac OS X 10.11 El Capitan (64 -bit) for Operating System type and version.  I named my Virtual Machine "El_Capitan", then clicked next...
       

       
      3.  Leave the Memory size at the recommended 2048 MB, then click next.
       

       
      4.  Choose to "Create a virtual hard disk now", then click the create button.
       

       
      5.  For the hard disk file type, the default is VDI (VirtualBox Disk Image) but I have selected VMDK for inter-operability with VMWare.  Click next...
       

       
      6.  For Storage on physical hard disk, I have chosen the default Dynamically allocated (grows larger to a set limit as you need more disk space).
       

       
      7.  On the File location and size screen, you can set the location of the new virtual hard disk and its size - I recommend changing disk size to 40GB or larger.  When you click the create button, you will now see your new VM in the VirtualBox main GUI.
       

       
      8.  Click the settings button on the Main Menu to tweak a few settings....
         a.  On the System/Motherboard tab in Boot Order, you can uncheck the Floppy Drive (who has these now?)
       

       
         b.  On the System/Processor tab, you can increase the allocated CPU cores to 2
       

       
         c.  On the Display tab, you can increase the allocated Video Memory to 128MB
       

       
         d.  On the Storage tab, click on the icon of the Optical Drive and select "Choose Virtual Optical Disk File". 
       

       
      Navigate and select the El Capitan ISO we created earlier...
       

       
         e.  Click the OK button to finalise the VM settings.
       
       
      Patch El Capitan vbox configuration file with DMI Settings from a Mac
      1.  From the start menu, type cmd and click run as administrator to open an administrative command prompt. 
       

       
      2.  Choose a Mac Model similar to your host system, then type the following lines, followed by <enter>  after each line.  Make sure you first close all VirtualBox Windows and the VirtualBox program, otherwise any changes you make won't stick...
       
      Eg iMac11,3
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "iMac11,3" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-F2238BAE" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1 MacBookPro11,3
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "MacBookPro11,3" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-2BD1B31983FE1663" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1 Macmini6,2
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "Macmini6,2" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-F65AE981FFA204ED" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1 3.  Optional- For some host systems eg those with Haswell and newer CPUs, you might have to spoof an older CPU to avoid VirtualBox errors.  You can try from one of the following if this happens:

      To spoof Lynnfield i5 750 CPU
      VBoxManage.exe modifyvm "El_Capitan" --cpuidset 00000001 000106e5 06100800 0098e3fd bfebfbff To spoof IvyBridge CPU
      VBoxManage.exe modifyvm "El_Capitan" --cpuidset 00000001 000306a9 04100800 7fbae3ff bfebfbff or
      VBoxManage.exe modifyvm "El_Capitan" --cpuidset 00000001 000306a9 00020800 80000201 178bfbff 4.  Close the command prompt window.
       
       
      Installation of El Capitan
      We are now ready to start the El_Capitan Virtual Machine....
       



       
      Installation should be relatively straight forward, just following the prompts of the OS X installer:
      1.  Select language, agree to legal terms
       

       
      2.  Use Disk Utility from the Utilities Menu to erase and format the virtual hard drive as a single partition GUID Mac OS X Extended.  I named my drive "Macintosh HD" but you can enter whatever you like eg El_Capitan.
       

       
      3.  Quit DU and choose Macintosh HD to install El Capitan on.
      4.  After 20-30 min (depending on how fast your system is), the installation will complete.  At this point, unmount the El Capitan ISO by clicking the Devices menu from the VM window, click Optical Drives, then choose Remove disk from virtual drive.  The VM is now ready to reboot into OS X from the virtual hard drive.
      5.  At the welcome screen, choose your country and keyboard layout.  You can skip transfer information, location services and logging in with your Apple ID if you wish…
      6.  Create a User Account and select your Time Zone.  You can skip sending diagnostics and usage data to Apple….
      7.  Finally, you will arrive at the El Capitan Desktop.
       

       
      8.  Network/internet and audio should work OOB but on my system, the sounds were distorted.  Unfortunately, there is no QE/CI and the VM resolution will be fixed without the ability to dynamically resize the VM window (no VirtualBox additions for OS X guests atm). 
       
       
      Customization with VBoxManage
      1.  You can change the default resolution of 1024*768 (after shutting down the VM) with the VBoxManage command from the Windows Administrative Command Prompt:
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" VBoxInternal2/EfiGopMode N (Where N can be one of 0,1,2,3,4,5) referring to the 640x480, 800x600, 1024x768, 1280x1024, 1440x900, 1920x1200 screen resolution respectively.
       
      Update:  For VirtualBox 5.2.x, the command for changing screen resolution has changed...
       
      VBoxManage setextradata "<MyVM>" VBoxInternal2/EfiGraphicsResolution XxY (where X=Horizontal screen resolution, Y=Vertical screen resolution)
      eg
      VBoxManage setextradata "<MyVM>" VBoxInternal2/EfiGraphicsResolution 1280x1024 2.  Adding serials and other SMBIOS details for the System Information Screen
      VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemSerial" "W8#######B6" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardSerial" "W8#########1A" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVendor" "Apple Inc." VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemFamily" "iMac" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBIOSVersion" "IM112.0057.03B" A listing of known issues with Mac OS X guests can be found in the VirtualBox Manual - link https://www.virtualbox.org/manual/ch14.html.
       
      Vanilla Mavericks and Yosemite, Snow Leopard from Retail DVD
      The same VM settings for El Capitan will also boot and run vanilla installations of OS X Mavericks and Yosemite .  Attached to this post are installer scripts to create bootable Mavericks (CMI.tool) and Yosemite (CYI.tool) ISOs for VirtualBox and VMware.
       
      With the respective OS X installer apps in the Applications folder, download and run the installer tools using terminal ie
       
      To create a Mavericks ISO on your desktop
      cd downloads chmod +x CMI.tool ./CMI.tool To create a Yosemite ISO on your desktop
      cd downloads chmod +x CYI.tool ./CYI.tool Here is a screenshot of the VM running Mavericks 10.9.5...
       

       
      Finally, those without a Mac/Hack to prepare the install media can purchase a retail Snow Leopard DVD directly from Apple and install OSX 10.6.3 on their virtual machines (Snow Leopard, Lion and Mountain Lion run quite happily in VirtualBox with 1 CPU, 1-2 GB of RAM and the rest of the settings unchanged from above).  Once you update by combo update to SL 10.6.8, you can directly download El Capitan from the App Store for free .
       

       
      UPDATE macOS Sierra 10.12 to 10.12.6: For macOS Sierra, use CSI.tool in post#51.
      UPDATE macOS High Sierra 17A365:  For macOS High Sierra, use CHSI.tool in post#73.
      UPDATE macOS Mojave Beta:  For macOS Mojave Beta, use CMJI.tool on page 4 of thread.
       
      Good luck and enjoy
      CECI.tool.zip
      CYI.tool.zip
      CMI.tool.zip
    • By fantomas1
      -----------------------------
      Mise à jour 12/07/2018
      -----------------------------
       
      La sortie de macOS 10.14 Beta m'oblige à mettre ce topic à jour. Plus de détails dans ce post.
       

       

       
      -----------------------------
      Mise à jour 09/06/2017
       
      -----------------------------
       
      La sortie de macOS 10.13 Beta m'oblige à mettre ce topic à jour. Plus de détails dans ce post.
       

       
       
       
      -----------------------------
      Mise à jour 15/06/2016
      -----------------------------
       
      Une petite mise à jour du topic pour confirmer le bon fonctionnement du patch à la volé de Clover (r3561) avec macOS Sierra.
       

       
       
       
      -----------------------------
      Mise à jour 24/08/2015
      -----------------------------
       
      ok, très bien,
       
      comme pour la HD6770, la nouvelle méthode du patch à la volé est de nouveau fonctionnel et avec les dernières versions de Clover.
       
      pour ma part, je suis sur El Capitan DB7 et Clover r3259
       

       
       
      par contre, je suis toujours obligé de m’aider de l’astuce avec FakeSMC pour que mes kexts soient toujours chargés, mais au moins cela marche.   
       
       
       
       
      et pour config.plist, cela donne ça :
       

       
       
      ceci est juste un exemple avec ma HD4830, il va de soi que vous devez mettre Device-ID de votre carte graphique !!!
       
       
       
       
       
      Salut à tou(te)s
       
      Comme certain(e)s le savent, les cartes graphiques dites "Exotiques" ne sont pas supportés par le système d'exploitation d'Apple.
      En sus d'ajouter l'identifient de la carte graphique (Device ID) dans l'Info.plist du ou des kexts concernés, il faut aussi interagir sur la partie "binaire" du kext par le biais du "patching".
       
      Dans notre cas, les cartes graphiques exotiques sont les cartes AMD (anciennement ATI) de la série HD 48xx, et plus précisément les HD 4830, HD4850, HD4870x2 et HD4890.*
       
      Donc le but est de faire fonctionner ces cartes graphiques de manière stable et fluide en activant QE_CI, chose nécessaire pour en profiter pleinement du système d'exploitation.
       
      * Juste avant de commencer, vous l'avez peut-être remarqué, la HD4870 n'est pas sur la liste suscitée et pour cause c'est que cette carte graphique est nativement supportée par le système d'exploitation d'Apple. Son Device ID est 0x94401002 que vous pouvez trouvé dans l'Info.plist des kexts concernés et c'est celui-ci que nous allons utiliser afin de le remplacer par le Device ID de notre carte graphique.
       
      ** Ce tuto est fait pour fonctionner sous OS X Mavericks, mais il doit fonctionner aussi avec les autres. La seule chose différente c'est l'adresse binaire à patcher.    
       
       
      Très bien, comme le titre le suggère, nous allons voir comment faire reconnaître ces cartes graphiques sous Clover et obtenir par la même un QE_CI activé et parfaitement fonctionnelle.
       
      Je vais utiliser ma Sapphire HD4830 512 MB GDDR3 PCI-E (comme cobaye    ) pour ce test et qui a pour Device ID 0x944c1002.
       
      Pour que ce test réussisse, nous allons donc utiliser ces 2 kexts, à savoir AMD4800Controller.kext (pour la partie QE) et ATIRadeonX2000.kext (pour la partie CI) et allons ajouter notre Device ID dans l'Info.plist. via le tweak "KernelAndKextPatches"
       
      Donc les valeurs à entrer dans notre config.plist sont celle-ci :
      <key>KernelAndKextPatches</key>     <array>         <dict>             <key>Name</key>             <string>AMD4800Controller</string>             <key>InfoPlistPatch</key>             <string>Yes</string>             <key>Find</key>             <string>0x94401002</string>             <key>Replace</key>             <string>0x944C1002</string>         </dict>         <dict>             <key>Name</key>             <string>ATIRadeonX2000</string>             <key>InfoPlistPatch</key>             <string>Yes</string>             <key>Find</key>             <string>0x94401002</string>             <key>Replace</key>             <string>0x944C1002</string>         </dict>     </array> Comme vous pouvez le voir, la clé "InfoPlistPatch" sert à injecter notre Device ID "uniquement" dans Info.plist, sans y toucher à la partie "binaire" de nos kexts. La clé "Find" a pour fonction de trouver le Device ID que l'on veut remplacer par le notre en utilisant la clé "Replace".
       
      Très bien, maintenant comme nous l'avons dit au début de ce tutoriel, ajouter notre Device ID n'est pas suffisant pour faire fonctionner pleinement notre carte graphique, il faut encore interagir sur la partie "binaire" de nos kexts. Dans notre cas, il va falloir agir uniquement sur un kext, çàd sur ATIRadeonX2000.kext et plus particulièrement sur ATIRadeonX2000.kext/Contents/MacOS/ATIRadeonX2000
       
      Et pour cela, nous allons faire comme ceci :
      <key>KextsToPatch</key> <array> <dict>     <key>Name</key>     <string>ATIRadeonX2000</string>     <key>Find</key>     <data>0F8394010000</data>     <key>Replace</key>     <data>909090909090</data> </dict> </array> Là nous pouvons voir que la clé "InfoPlistPatch" n'est pas utilisée et donc ces valeurs n'auront aucun effet sur l'Info.plist mais agiront uniquement au niveau de la partie "binaire". 
       
      Et voici les valeurs en leur forme complète que vous devrez ajouter dans votre config.plist
      <key>KernelAndKextPatches</key>     <array>         <dict>             <key>Name</key>             <string>AMD4800Controller</string>             <key>InfoPlistPatch</key>             <string>Yes</string>             <key>Find</key>             <string>0x94401002</string>             <key>Replace</key>             <string>0x944C1002</string>         </dict>         <dict>             <key>Name</key>             <string>ATIRadeonX2000</string>             <key>InfoPlistPatch</key>             <string>Yes</string>             <key>Find</key>             <string>0x94401002</string>             <key>Replace</key>             <string>0x944C1002</string>         </dict>         <dict>             <key>Name</key>             <string>ATIRadeonX2000</string>             <key>Find</key>             <data>0F8394010000</data>             <key>Replace</key>             <data>909090909090</data>        </dict>     </array> Très bien, maintenant il ne nous reste plus qu'à autoriser l'injection des kexts, sans quoi le patch ne fonctionnera pas. Et nous allons le faire via le tweak "InjectKexts" comme ceci :
      <key>SystemParameters</key> --> clé principale <dict>       <key>InjectSystemID</key>       <true/>       <key>InjectKexts</key> --> sous clé       <string>Yes</string> </dict>  
       
      Si certain(e)s d'entre vous préfèrent utiliser le logiciel "Clover Configurator" pour plus de facilité, voici comment entrer ces valeurs :
       
      Allez sur l'onglet "Kernel And Kext Patches" et faites comme ceci :
       
       
       
      *Ne faites pas attention sur le majuscule/minuscule, cela ne fait aucune différence
       
       
      Et pour injecter les kexts, aller sur l'onglet "System Parameters" et mettez l'option Inject Kexts sur Yes comme ceci :
       

       
       
      Voilà, vous n'avez plus qu'à enregistrer les ajustements, redémarrer votre pc et apprécier le résultat.
       
       
      MAIS ... seulement voilà ... il y a un problème ... 
       
      Quoi ? 
       
      Initialement, les kexts ne sont pas présents dans le kernelcache à cause de "OSBundleRequired=Safe Boot" (ils ne sont pas chargés en local par défaut mais en mode sans échec) et donc le patchage "à la volé" (on the fly) ne fonctionnera pas.
       
      Donc quoi, tout ça pour rien ?
       
      Non, bien-sûr, voici l'astuce pour remédier à cela :
       
      Dans un premier temps, il vous faut booter l'OS sans kernelcache. Si vous utiliser Clover Configurator, il vous suffit juste de cocher l'option "No Caches" dans l'onglet "System and Parameters" ou bien vous le faites directement dans votre config.plist :
      <key>SystemParameters</key> <dict>       <key>InjectSystemID</key>       <true/>       <key>InjectKexts</key>       <string>Yes</string>       <key>NoCaches</key>       <true/> </dict> Ceci aura donc pour effet de bloquer kernelcache et obliger boot.efi de charger le kernel et les kexts séparément. Clover et FSInject vont ensuite intercepter tous les chargements des kexts par boot.efi et changer "OSBundleRequired=Safe Boot" en "OSBundleRequired=Root" à la volé (on the fly) et forceront boot .efi à charger les kexts. Et ensuite dans un second temps, Clover va patcher l'Info.plist de ces deux kexts et la partie binaire de ATIRadeonX2000, kernel va les charger et ils seront rattachés à votre carte graphique.
       
      Une fois ceci fait (donc les kexts utilisés), il vous suffit de faire sudo touch /System/Library/Extensions. Ceci créera un nouveau kernelcache qui cette fois-ci contiendra vos kexts utilisés. Ensuite il ne vous reste plus qu'à redémarrer normalement (en décochant l'option No Caches dans Clover Configurator) et le patch fonctionnera à merveille.
       
       
      Oui, mais ... là aussi ...
       
      Quoi encore ?
       
      Seulement voilà, pour une raison ou une autre, il peut arriver que kernelcache se reconstruit tout seul et le patch "à la volé" ne fonctionne plus.
       
      Alors je fais quoi moi en attendant ?
       
      L'astuce la plus efficace pour le moment est d'injecter les infos de vos kexts à l'intérieur de l'Info.plist de FakeSMC.kext comme des IOKitPersonalities additionnels.
       
      ????Kézako????
       
      Ces infos vous les trouverez dans l'Info.plist de ces 2 kexts, sous IOKitPersonalities. Les voici :
       
      Pour AMD4800Controller.kext
      <key>Controller</key> <dict>         <key>ATY,Cardinal</key>         <dict>                 <key>aty_config</key>                 <dict>                         <key>CFG_NO_PP</key>                         <true/>                 </dict>          </dict>          <key>CFBundleIdentifier</key>          <string>com.apple.kext.AMD4800Controller</string>          <key>IOClass</key>          <string>AMD4800Controller</string>          <key>IOMatchCategory</key>          <string>IOFramebuffer</string>          <key>IOName</key>          <string>AMD4800Controller</string>          <key>IOPCIMatch</key>          <string>0x94401002 0x944a1002</string>          <key>IOProbeScore</key>          <integer>65050</integer>          <key>IOProviderClass</key>          <string>IOPCIDevice</string>         <key>aty_config</key>          <dict>                 <key>CFG_NO_PP</key>                  <false/>                  <key>CFG_PAA</key>                  <integer>0</integer>                  <key>CFG_USE_USCN</key>                  <false/>          </dict>          <key>aty_properties</key>          <dict>                  <key>PP_GFXClockGatingEnabled</key>                  <integer>1</integer>          </dict> </dict> Et pour ATIRadeonX2000.kext
      <key>ATIRadeonX2000</key> <dict>         <key>ATIEnableWideBlitSupport</key>         <true/> <key>ATIUseTearingWideBlit</key> <false/> <key>CFBundleIdentifier</key> <string>com.apple.ATIRadeonX2000</string> <key>GpuDebugPolicy</key> <integer>0</integer> <key>IOCFPlugInTypes</key> <dict> <key>ACCF0000-0000-0000-0000-000a2789904e</key> <string>ATIRadeonX2000GA.plugin</string> </dict> <key>IOClass</key> <string>ATIRadeonX2000</string> <key>IODVDBundleName</key> <string>ATIRadeonX2000VADriver</string> <key>IOKitDebug</key> <integer>0</integer> <key>IOMatchCategory</key> <string>IOAccelerator</string> <key>IOPCIMatch</key> <string>0x94001002 0x94011002 0x94021002 0x94031002 0x95811002 0x95831002 0x95881002 0x94c81002 0x94c91002 0x95001002 0x95011002 0x95051002 0x95071002 0x95041002 0x95061002 0x95981002 0x94881002 0x95991002 0x95911002 0x95931002 0x94401002 0x94421002 0x944A1002 0x945A1002 0x94901002 0x949E1002 0x94801002 0x95401002 0x95411002 0x954E1002 0x954F1002 0x95521002 0x95531002 0x94a01002</string> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>IOSourceVersion</key> <string>8.24.11</string> <key>IOVARendererID</key> <integer>16908288</integer> <key>sensor-properties</key> <array> <dict> <key>device_type</key> <data> Z3B1LXNlbnNvcg== </data> <key>location</key> <string>GPU</string> <key>name</key> <string>gpu-sensor</string> <key>polling-period</key> <data> AAAAAQAAAAA= </data> <key>reg</key> <data> AAAAAg== </data> <key>sample-period</key> <data> AAAAAACYmAA= </data> <key>sensor-id</key> <data> AAAABg== </data> <key>version</key> <data> AAAAAg== </data> <key>zone</key> <data> AAAAAg== </data> </dict> </array </dict>  
      Et voici donc l'Info.plist de FakeSMC.kext dans son intégrité, vous pouvez jeter un oeil, histoire de voir à quoi cela ressemble :
       
      FakeSMC_Info.plist.zip
       
      Et pour les moins casse-têtes, voici FakeSMC.kext modifié que j'utilise pour charger les 2 kexts :
       
      FakeSMC.kext.zip
       
       
      Voilà, avec ceci, vous n'aurez plus besoin de savoir si oui ou non les kexts sont dans le kernelcache.
       
       
      Crédits attribués à :
       
      netkas  pour son incontournable QE_CI Exotic patch (même s'il n'importe plus son support)
       
      Slice  & co. pour leur bébé nommé Clover
       
      dmazar  pour son astuce avec FakeSMC.kext   (pour plus d'info, voir ici)
       
      duffs (rarement ici, plus sur le site de netkas) pour son astuce de comment patcher la partie binaire avec Clover, ce fût lors de la sortie de OS X Mavericks DP1
       
      nyolc8  pour le support de QE_CI Exotic patch pour Mavericks
       
      fantomas1  pour ......... pour ... quoi déjà ? Ah ben non ... non ... pour rien ...
    • By Slice
      Now I want to add vector graphics support in Clover. See rev 4560 and later.
      It is not working yet but designers may begin to create Vector Themes.
      It supposed to consist of SVG elements and has design size. It will be rendered to any screen size scaled from design size.
       
      What application in macOS can create SVG graphics?
      Inkscape is not working in macOS 10.11+. Pity.
      LibreOffice Draw works with SVG but buggy.
      Boxy SVG cost 10$ but looks good enough. It creates the best in simplicity files and have more then enough features.
      Illustrator is good but expensive.
       
      How to improve SVG file?
      Clover has restricted support for SVG. It is your job to make compatible file and as small as possible to speedup rendering.
      Some helps:
      Help:Inkscape – From invalid to valid SVG Inkscape files
      From invalid to valid SVG Adobe Illustrator files
      From invalid to valid SVG files of other editors: BKchem, ChemDraw and CorelDRAW
      Help:Illustrator – Assistance with creating and saving SVG images in Adobe Illustrator that will pass W3C validation
      User:Quibik/Cleaning up SVG files manually
      Later I will write own instructions specific to Clover abilities.
       
      How to create SVG fonts?
      You can google to find ready-to-use SVG fonts.  I found some problems with too beaty fonts: slow rendering and overflow crash. Be careful.
      You can get ttf or otf fonts and convert them into svg by using online WEB services. Not a problem to google.
      But then I want to find a way to simplify the font to reduce a size and speedup rendering.
      You can create own font by FontForge It is opensource and available for Windows, Mac and GNU+Linux. It creates otf font which you can convert to svg font.
       
       
×