Jump to content
188 posts in this topic

Recommended Posts

Rev 4004

Code introduced in Rev 3710 to modify the boot character only works for

Start64H1.com, Start64H2.com, Start64H2.com, Start64H4.com

and corrupts the boot code for

Start64H5.com, Start64H6.com, start32H.com2

Modified ebuild.sh to exclude modifying the corrupted boot code

  • Like 4

Rev 4006

Removed codes differentiated OldWay and NewWay for DSDT fixing. Now NewWay always.

For those who have old ways fixes set you have to revise config.plist upgrading to new Clover version.

  • Like 12
  • 2 weeks later...

Rev 4020

A possibility to patch boot.efi on the fly and a possibility to disable some of these patches from Clover GUI.

 

What is "boot.efi"? 

Clover is Boot Manager providing us a chooser between different OS bootloaders:

bootmgfw.efi for Windows

grubx64.efi for Linux

boot.efi for MacOS.

Each substance of MacOS has own boot.efi located on the same volume in /System/Library/CoreServices/

This is EFI application working in EFI environment provided by UEFI BIOS or by CloverEFI.

 

What boot.efi does?

- create DeviceTree and fill it with initial information from EFI (SMBIOS, ACPI, DeviceProperties etc)

- load kernel, kexts, caches...

- make memory map

- performs start OS, or hibernate wake, or NET load, or something else

- ask user for password at FileVault2

- other preOS procedures

 

Is it opensource? No.

But we have some similar sources to see how it works

     macosxbootloader (Hackintosh version).    

and by Pike'R Alpha at github. I don't know the origin of the sources.

//	created:	4:11:2009   10:40
//	filename: 	Console.cpp
//	author:		tiamo

Looking at the sources we can find what to patch for our purpose.

  • Like 14

Rev 4028, 4030, 4031

  • Renamed build_gcc5.sh to build_gcc6.sh and modified to build GCC 6.3 toolchain with LTO support.
  • To build with GCC 6.3, still use -gcc53 toolchain parameter to ebuild.sh.
  • Corrected mistake in r3730 that made -gcc53 toolchain use native GCC instead of cross-compiler.  Update: In Rev 4030, location of GCC for -gcc53 toolchain is determined based on whether building on Linux or Darwin.
  • Added script buildmtoc.sh to build mtoc from cctools-895.  Default install location is $TOOLCHAIN_DIR/bin/mtoc.NEW.
  • Update: In Rev 4031, adapted CloverPackage/makeiso script to work on Linux.
Edited by Zenith432
  • Like 12

Rev 4034

  • build_gcc6.sh built both native Darwin GCC and cross-compile GCC for linux-gnu.
  • Clover does not use the native Darwin GCC.
  • native Darwin GCC was only used to build the cross-compile binutils and GCC.
  • Xcode can build the cross-compile binutils and GCC.
  • Eliminated the building of native Darwin GCC from build_gcc6.sh.
  • The cross-compile binutils and GCC are now built using Xcode.
  • Eliminated dependence in Clover on mere existence of $TOOLCHAIN_DIR/bin (the cross-compile tools are in $TOOLCHAIN_DIR/cross).  However, if you build nasm with buildnasm.sh - it is still placed in $TOOLCHAIN_DIR/bin and run from there.
  • Like 13
  • 5 weeks later...

Rev 4050 - 4052

  • Created XCODE8 toolchain with following differences from XCODE5
  • Uses clang native -target x86_64-apple-darwin instead of hybrid -target x86_64-windows-macho.
  • #defines EFIAPI to __attribute__((ms_abi)) similar to GCC builds.
  • Uses __builtin_ms_va_list for VA_LIST.
  • Changed BUILDRULEORDER from "S s nasm" to "nasm S s" so nasm is used on assembly sources.

This toolchain exposed some type mismatches for functions with EFIAPI.  Also exposed some use of incorrect va_list in variadic functions that are not EFIAPI (present in OpensslLib and GrubFS).  These issues are present in GCC build as well, and should have been discovered.  They weren't, and GCC generates incorrect code in some of the cases.  Anyhow, I fixed all these instances.
[Edit: apologies to GCC, it's set to -mabi=ms in tools_def.txt, so uses ms_abi on all functions.  GCC does discover the type mismatches without this setting.]

 

A brief history of va_list issue with -target x86_64-windows-macho, just for the record

  • Before LLVM clang 3.7, Apple clang 7.3, this target only had __builtin_va_list.  This implementation worked (other than some bugs in old versions of Xcode), but it creates a va_list that is incompatible with the one created by Microsoft in Win64 ABI.
  • [Microsoft implements va_list using a char* which points to the parameters spilt on the stack and is passed by value.  The clang implementation places the Microsoft va_list in a struct that has same build as sysv_va_list (24 bytes, 16-byte aligned), and passes the sysv_va_list by reference (address of the Microsoft va_list).]
  • LLVM clang 3.7 to 3.8.x, Apple clang 7.3 to 8.0 had a __builtin_ms_va_list for this target.  The va_list was a char* the same as Microsoft, passed by value.  It generally worked, but there was a bug that __builtin_va_arg would not always advance the pointer by the correct # of bytes (LLVM bug 27663).  This bug has not been fixed, but instead, the target no longer supports __builtin_ms_va_list and gives a compile-time error message when this type is passed to __builtin_va_arg.  It can't be used anymore.

In -target x86_64-apple-darwin, there is an implementation of __builtin_ms_va_list, which works similar to the Microsoft one (and same as GCC.). In this target it is necessary to use __attribute__((ms_abi)) to get Win64 ABI for a function.  There are other side-effects of using this target.  For example, any Win64ABI function that calls a SYSV_ABI function spills the SSE registers XMM6-XMM15.  This is because they're considered non-volatile in Win64ABI, but volatile in SYSV_ABI.  As a result of this overhead, the code generated by XCODE8 is generally bigger than the code generated by XCODE5.
I've also compared XCODE8 with -flto and -fno-lto, and there's almost no difference in the size of CLOVERX64.efi.

 

Edit: For the record, Apple's boot.efi is compiled with clang+mtoc, -target x86_64-windows-macho and uses __builtin_va_list for VA_LIST.

Edited by Zenith432
  • Like 9

Rev 4049

Compatibility with 10.12.4 installer.

It has new boot.efi location and will not work with previous Clover revisions.

 

Rev 4053

Use UTC time for nvram.plist.

The problem is a file on HFS+ partition has UTC modification date while same file on FAT32 (EFI partition) has local time.

Clover will compare several nvram_plists found on different partitions to decide who is newer. In this case time zone difference leads to bug.

This commit modifies save_nvram script to make same time stamp.

  • Like 10
  • 3 weeks later...

Rev 4058

Updated EDID injection by Sherlocks.

There are no more old keys "CustomEDID" and "InjectEDID".

There must be as follow (as introduced in rev 3737)

	<key>Graphics</key>
	<dict>
		<key>EDID</key>
		<dict>
			<key>Custom</key>
			<data>AP///////wAGECGSAAAAAAASAQOAIRV4CunVmVlTjigmUFQAAAABAQEBAQEBAQEBAQEBAQEB3iGgcFCEHzAgIFYAS88QAAAY3iGgcFCEHzAgIFYAS88QAAAAAAAA/gBXNjU3RwAxNTRXUDEKAAAA/gAjMz1IZYSq/wIBCiAgAJo=</data>
			<key>Inject</key>
			<true/>
			<key>VendorID</key>
			<string>0x1006</string>
			<key>ProductID</key>
			<string>0x9221</string>
		</dict>

This is from config-sample.plist

  • Like 8
  • 1 month later...
  • 1 month later...

Rev 4110

Fixed External Clock calculation and QPI.
No more need to follow this process. Clover automatically resolves it now.
Note: Real Mac’s report a hw.busfrequency = 100000000

To achieve that with Clover here’s what to do:
1 - Drop SMBIOS table type 132 for Sandy Bridge and newer CPU’s. Clover does this if you set QPI to a string value of 0.
2 - Set SMBIOS table type 4->ExternalClock to 0 (or 25Mhz as a real Mac). This currently has to be done in the source code and re-compile Clover.

Rev 4111

Improved CPU log
 - Finally: ExternalClock=25MHz BusSpeed=100000kHz CPU=2300MHz PIS: hw.busfrequency=100000000Hz

added NvidiaNoEFI thanks to FredWst. link

 - If I choose Nvidia injection with bad EFI bios screen is coming scrambled.

	<key>Graphics</key>
	<dict>
		<key>#NvidiaNoEFI</key>
		<false/>
  • Like 15
  • 2 weeks later...
  • 2 weeks later...

Rev 4129


Support if EDID could not be read.


 - Clover can't read EDID on some system "EdidDiscovered size=0"


 - if want to use EDID, have to follow this



<key>EDID</key>
<dict>
<key>Custom</key>
<data>
your EDID data from windows or linux
</data>
<key>Inject</key>
<true/>

  • Like 4

Rev 4130

improved DualLink if can't read correct resolution

 - Support DualLink in GUI

post-980913-0-41510100-1501685708_thumb.png

 - Clover can read correct resolution on most of system. but can't read correct resolution on some system. example, lenovo laptop. Link

 - Default DualLink auto-detection. if has problem to read resolution, try

   Low resolution(1366x768-) - DualLink = 0

   High resolution(1400x1050+) - DualLink = 1

	<key>Graphics</key>
	<dict>
		<key>DualLink</key>
		<integer>you want</integer> 

Rev 4132

Fixed DualLink in GUI

 - DualLink is only applicable to intel graphics and amd radeon graphics except nvidia graphics(confirmed from RealMac).

 

Rev 4135

Added option to easily use debug in GUI

 - Easily use debug of KernelAndKextPatches in GUI. no need to set "Debug = true" on KernelAndKextPatches in config.plist. 

 - Of course, it supports "Debug = true" on KernelAndKextPatches in config.plist if want to always see debug log

post-980913-0-20782700-1501770568_thumb.png

  • Like 7

Rev 4154

Boolean "KernelIvyXCPM" under "KernelAndKextPatches" to enable XCPM on Ivy Bridge CPUs. It looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>KernelAndKextPatches</key>
        <dict>
                <key>KernelIvyXCPM</key>
                <true/>
        </dict>
</dict>
</plist>

Note: If you had to enable AsusAICPUPM/AppleIntelCPUPM in the past to bypass AICPUPM kernel panic, then you might also need to turn on KernelPm with the new KernelIvyXCPM. Thanks to @ACIDSkyRU for pointing this out.

Edited by PMheart
  • Like 10

Rev 4161
check for BiosVersion and BiosReleaseDate by Sherlocks
- if user has old BiosVersion and BiosReleaseDate at config, no more need to always update manually.
- The clover judges the user's BiosVersion and BiosReleaseDate and keeps them up-to-date.
- Of course, it is based on the latest clover platformdata. The newer BiosVersion can be used at config by user when update macOS.
- User can avoid problems such as Thunderbolt update messages on some smbios or high Sierra installation problems.

Standard BiosReleaseDate : MM/DD/YY or MM/DD/YYYY
-The standard format differs depending on the model. Clover automatically adapts this part to the model. Either of these can be used at config.

 

Rev 4162
Fixed a problem with displaying the ram when using injection on the latest NVIDIA graphics families. link

  • Like 11

Rev 4170

Added ability within the Clover GUI to set/unset Nvidia value for
NvidiaSingle and NvidiaNoEFI

The NvidiaNoEFI change was made by suggestion and patch by FredWst
reference topic here -> http://www.insanelymac.com/forum/topic/306156-clover-bugissue-report-and-patch/?p=2443062

The parameters are readed (if exist) from config.plist

This is a handy way to test those value without edit the config.plist to find the
expected result.

ErmaC

  • Like 3

Rev 4179
check for FirmwareFeatures and FirmwareFeaturesMask by Sherlocks
- if user has old
FirmwareFeatures and FirmwareFeaturesMask at config, no more need to always update manually until release new update or macOS.
- The clover judges the user's
FirmwareFeatures and FirmwareFeaturesMask and keeps them up-to-date.
- Of course, it is based on the latest clover platformdata. The newer
FirmwareFeatures can be used at config by user when update macOS.
- User can avoid problems such as high Sierra installation problems.

 

 

macOS High Sierra has the requirements as smbios for installation.

 

if you tried to install High Sierra from all method, then failed,

 - Consider the following:

  1. link  thanks to chris1111 

  2. link  thanks to fusion71au

  3. link  thanks to crazybirdy, for Firmware Check Patch

  • Like 16
  • 2 weeks later...

Rev 4193

Fix parity bits for DDR3 and DDR4 proposed by joevt here

 

Rev 4194

Fix MaxBrightness for Intel HD3000/4000 proposed by Dr.Hurt here

New setting in config plist

	<key>Devices</key>
	<dict>
		<key>SetIntelMaxBacklight</key>
		<true/>

  • Like 10

Rev 4195

Set backlight control for Nvidia mobile cards.

Снимок экрана 2017-09-06 в 23.47.50.png

 

In my case there are:

DSDT_FIX: AddPNLF_1000000

OEM SSDT NvdTable, but _DSM -> ZDSM corrected by Clover. No new _DSM

No additional kexts.

 

A trick to assign keys to reduce/increase brightness:

insert temporarily USB keyboard

Control Panel -> Keyboeard -> Shotcuts -> Screen (appeared due to USB keyboard)

assign F1 to Reduce brightness and F2 to Increase. No other combinations!

After removing the USB keyboard assigning will continue working.

  • Like 6

Rev 4196

Set Intel Max Backlight Value in config an in menu.

	<key>Devices</key>
	<dict>
		<key>#SetIntelBacklight</key>
		<false/>
		<key>SetIntelMaxBacklight</key>
		<true/>
		<key>IntelMaxValue</key>
		<integer>1808</integer>

The value is proposed to be decimal and common recommendation

Sandy or IvyBridge:  1808

Haswell or Broadwell: 2776

Skylake or Kabylake: 1295

  • Like 9

Rev 4200

Compatibility with Windows 7.

Old fix FixDarwin_0002 made ACPI behaviour like Windows XP (Windows 2001 SP #). Usually it gives OSYS=0x7D2.

It is too old for modern computers. For example USB3.0 may not work.

So I made new fix "FixDarwin7_10000" which makes compatibility with Windows 7 SP1 (Windows 2009). It should gives OSYS=0x7D9.

 

Discussion: I will not make Windows 2012 or 2016 because MacOSX is more ACPI system and more oriented on DSDT then W2012 which has own drivers no matter what ACPI said.

  • Like 13
  • 2 weeks later...

Rev 4202

Kext Injection Management.

Allow user to disable specific kext(s) in Clover/Options/Kext Injection Management. This provide user flexible to debug kexts especially in new system.

 

Rev 4204

User can block plugin kext in Kext Injection Management as well.

 

Discussion: some users also require disable kext injection in config.plist as well. 

 

Rev 4208

Fix APFS installation issue on ESP/EFI partition by Rehabman.

 

Rev 4209

Remove options that are unrelated to Clover in menu by Slice.  Because we now have more general way to disable specific kext injection.

  • Like 8
×
×
  • Create New...