Jump to content

Clover Change Explanations


Slice
188 posts in this topic

Recommended Posts

Rev 5144 release.

There is a bridge to OpenCore quirk "ProvideCurrentCpuInfo".

You can find it in config-sample.plist.

There is also a menu entry in section "Binaries patching" assuming the quirk is actually Kernel patch.

Screenshot 2022-01-29 at 13.32.05.png

 

The patch is destructive, it may break the kernel so you should set FALSE initially. Then boot into Clover GUI and change here to TRUE.

If you can successfuly boot then you may change FALSE to TRUE in your config.plist.

Else if you hang at apple screen then just Reset and boot as is. The setting will be FALSE default.

 

For my Skylake CPU I catch the hang.

There are some tales that the quirk is useful for Alder Lake CPU.

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

Rev 5144 commit 4266f4ddf3f582bac1770f4093dc5302bc0c9e10

HWTarget can be default.

 

The Clover will set appropriate value based on Model set.

The setting is needed for software update in Monterey. If you didn't see new Monterey update then check if you set incorrect value in config.plist and better to comment it out

	<key>RtVariables</key>
	<dict>
		<key>#HWTarget</key>
		<string>J160AP</string>

 

  • Like 1
Link to comment
Share on other sites

Rev 5142+

Using new OpenRuntime.efi.

There is incompatibility with older version. Clover before 5142 requires OpenRuntime.efi version 1.1 while 5142+ requires version 1.2.

What to do if you sometime want to reboot with older version?

I made special folder drivers/5142 where I placed OpenRuntime-v12.efi. And common folder drivers/UEFI contains OpenRuntime-v11.efi.

Screenshot 2022-02-06 at 18.35.35.png

How it works?

Old Clover see no the folder 5142 and uses common folder drivers/UEFI and read here openRuntime-v11.efi.

New Clover see the folder drivers/5142 and read here new OpenRuntime-v12.efi which is in priority.

That's all!

  • Thanks 1
Link to comment
Share on other sites

  • 1 month later...

Rev 5145 commit 89658955f 

Correct ATI Injection.

 

It was very ancient method to inject graphics card properies and we almost forgot about it. But no!

Users of new Navi cards RX5600-RX6900 noticed poor performance under Monterey 12.3.

A simple workaround was found you have to use named framebuffer namely:

RX6900 -> Carswell

RX6800 -> Belknap

RX5700 -> Adder

RX5500 -> Python

RX6600 -> Henbury

 

It is easy to do with Clover now

Graphics->Inject->ATI=YES

Graphics->FBName=Carswell  ...

WhateverGreen is not involved in the solution.

 

For my RX570 I tested with framebuffer Orinoco. It works but I had no performance issue to compare.

Снимок экрана 2022-03-19 в 12.11.15.png

 

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Rev 5146 release

There were several ways to inject devices properties Apple's way: Inject=YES, Arbitrary, AddProperties, and Properties.

Now I have to claim Arbitrary, AddProperties to be deprecated and we can use Inject and Properties simultaneously. It was impossible before.

See screen. There is single property vasia=Radeon 578 and also Inject->ATI=YES. both worked!

Screenshot 2022-03-25 at 19.15.40.png

 

There is also a possibility to not inject some properties

Devices->NoDefaultProperties=YES

In this case Inject->ATI will not produced most keys except those that needed for FakeID and probably for mobile cards.

 

Arbitrary and AddProperties are still supported but I will recommend to not use them and rewrite your config to modern Properties.

 

 

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

  • 3 months later...

Rev 5147 release

Made for Venture compatibility. There is updated OC subproject and internal Clover corrections.

 

commit 7b2dddaa

Repair startup sound broken because of inaccuracy in OC project

 

commit 5fb7d28ff

Repair DefaultBackgroundColour. Now the driver AppleUiTheme is embedded into Clover that is the fix.

In config.plist you may set

        <key>BootGraphics</key>
        <dict>
            <key>UIScale</key>
            <integer>1</integer>
            <key>DefaultBackgroundColor</key>
            <string>0xBFBFBF</string>
            <key>EFILoginHiDPI</key>
            <integer>1</integer>
        </dict>

To see dark apple on grey screen.

Set UIScale to 2 to see double sized apple.
 

  • Like 7
Link to comment
Share on other sites

  • 4 weeks later...

Release 5148

Compatibility with Ventura beta 3 due to embedded OC update.

 

commit 735987a

SMCHelper.efi is excluded from package because its functionality is embedded into Clover.

On real Macs the SMC controller (or T2 chip) works before the system loaded, has own memory and controlls hardware independent on macOS.

We can partially emulate the controller by FakeSMC.kext but it works only after the system loaded.

Clover has additional service working during reboot:

FakeSMC catches AppleSMC->write(key, value) calls and save then into NVRAM, for example

fakesmc-key-EPCI-ui32	%08%c0%f0%00
fakesmc-key-MSAc-ui16	%00%00

When we reboot the computer these values will be saved. Legacy computer also has a service to save this into nvram.plist.

After reboot Clover checks NVRAM or nvram.plist and grabs SMC keys from there. It stores these keys into database supported by AppleSmcProtocol.

This protocol was provided by SMCHelper.efi driver and asked by Apple's boot.efi for own purpose.

See log

->LocateProtocol(gAppleSMCProtocolGuid, 0, 0/545A1A80) = Success
->AppleSMC.SmcReadValue SMC=4D535463 (MSTc) len=1
--> data=: 00 
->AppleSMC.SmcReadValue SMC=4D534163 (MSAc) len=2
--> data=: 00 00 

Now the protocol is embedded into Clover.

There is also AppleSmcStateProtocol which is also provided by this driver and now by Clover.

Also Clover translate some keys into device-tree to be extracted again be FakeSMC and used by macOS.

Clover also produces some keys depending on SMBIOS model because they different on different Macs. If we changed SMBIOS model during boot then we logically expected SMC keys will correspond to new model.

This is the life cycle of SMC keys.

 

Don't use VirtualSMC, it has no such functionality.

 

Moreover FakeSMC should be updated to version 3.5.4

 

 

Edited by Slice
Sorry, wrong FakeSMC info.plist
  • Like 5
  • Thanks 1
Link to comment
Share on other sites

Forgot to say new Clover feature

Commit 735987a

 

image.png

This is approximately same reset SMC controller as on real Mac do 

Shift+Option+Control during power up.

  • Like 8
  • Thanks 2
Link to comment
Share on other sites

  • 2 months later...

Release 5149

Embedded some drivers into Clover:

DataHubDxe, SMCHelper, AppleKeyAggregator, AppleUITheme, AppleImageCodec.

You may keep them in drivers folder for compatibility with older Clover versions and there will be no conflict with double drivers.

 

commit d5a69286c740f00c92e1b16ded33dba4e51b2b24

use count for dsdt patches 

For more developer flexibility there was implemented "Count" key in DSDT patches

Example

                    <dict>
                        <key>Comment</key>
                        <string>Rename HECI to IMEI</string>
                        <key>Disabled</key>
                        <false/>
                        <key>Find</key>
                        <data>SEVDSQ==</data>
                        <key>Replace</key>
                        <data>SU1FSQ==</data>
                        <key>Skip</key>
                        <integer>0</integer>
                        <key>Count</key>
                        <integer>0</integer>
                    </dict>

 

commit 70a37b142caf53360fa54ebd3c9b8496b193f3e6

I encounter the problem that the chip VLC805 which is USB 3.0 controller can't be cure from BIOS Ownership. So that FixOwnership in Clover leads to hang.

So I excluded the VIA controllers (this and similar) from the procedure and now FixOwnership is a safe quirk.

 

commit e56b549dca2cb22e7247a84921791d32b2855371

Implement TscSyncTimeout quirk.

It is provided by embedded OpenCore. I just provide an interface to the quirk in config.plist and in Clover GUI.

Quirks section:

 			<key>TscSyncTimeout</key>
			<integer>750000</integer>

This value proved to be needed for Xeon E5-2650v2.

  • Like 5
Link to comment
Share on other sites

  • 8 months later...

Release 5152 Sonoma ready.

Commit 2cb4b24a5d8b6e1b82ac81491a0788b8ec1c670b

The task is follow: I want to use SMBIOS iMacPro1,1 when boot to Mojave but I prefer to choose iMac19,1 when booting to Ventura or Sonoma.

  So I decided  to make SMBIOS auto choose depending on booted OS. I remind that it will not influence on Linux or Windows.

I prepare config.plist containing such entries

Screenshot 2023-06-17 at 21.52.41.png

And hope Clover will choose SMBIOS_capitan when I boot to ElCapitan and choose SMBIOS_ventura when I boot to Ventura.

 

Syntaxis same as OS Icons name in Themes "hsierra", "cap", "mojave" etc. Comparison is true if OsIconName is a substring of SMBIOS_XXXX dictionary name. For example "cap" is substring of "SMBIOS_capitan".

 

Backward compatibility If boot masOS whose name is not in the list then "SMBIOS" will be loaded. In the case above Sonoma has no specific entry so "SMBIOS" will be used.

 

Manual adjust Enter Clover GUI and see what is here

 

image.jpegYou may choose one of your entries and edit it to your permanent need entering to "SMBIOS->"

Then you will boot into any macOS with the edited value.

Choose "auto" if you want automatic choose. The menu will show you "SMBIOS" dictionary in this case while real SMBIOS will be automatic chosen.

 

Understandable?

  • Like 8
  • Thanks 2
  • Confused 1
Link to comment
Share on other sites

  • 2 months later...

Commit 90b68db32

Nvram support with legacy boot.

 

It was previously but only for GUID = gAppleBootGuid which is the default GUID in nvram command if other not specified. But it is not enough.

We want also save variable boot0082 for hibernation and IASCurrentInstallPhase for update system or install new one. These variables marked by other GUID.

So I modified nvram utility get from https://github.com/apple-oss-distributions/system_cmds/blob/13d383ddb305dc1672243e5384ba18b58949cc2c/nvram.tproj/nvram.c

such a way it will print more variables by common command

nvram -x -p

To not mix with system utility I rename it to nvram2.

Standard Clover compilation will compile this utility as well and it will work... only for your system.

To make the utility universal it must be compiled on older system. Mojave for example.

The script installed for legacy Clover

/etc/rc.shutdown.d/80.save_nvram_plist.local

should be modified in line 47 so that there will be nvram2 instead of nvram

gNVRAMbuf=$(/usr/local/bin/nvram2 -x -p)

and you have to place the new nvram2 utility somewhere in system folder like

 

sudo cp ~/Downloads/nvram2 /usr/local/bin

I am not sure if Clover.pkg will correctly do the work in new systems like Ventura so why I propose a manual way. Better ask @chris1111.

 

Attention! New utility and script will work only with new Clover since this commit. Else you will loose nvram at all.

Otherwise new Clover will correctly work with old nvram utility just without new features.

 

nvram2.zip

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Commit 0ea0020c48efff41c9badde82abe4e3a27ce4994

I reverted XCODE8 toolset to be working in old macOS like Mojave and made new toolset XCODE14 for use with Xcode14 in Ventura and up.

 

And now release 5155.

  • Like 5
Link to comment
Share on other sites

×
×
  • Create New...