Clover General discussion

arsradu · June 18, 2016

Put inside your EFI folder as is. At boot edit config:"config" to be config:"test" in the option of the Clover's menu.

@asradu, the pc will not explode if you try as I said (your original config leaves untouched)

Maybe it will melt down. You don't know... )

Will try it, Micky, but as I told you, I can't reboot my computer now. I will try it when I get near it again.

fusion71au · June 19, 2016

I've got this problem. Booting 10.11.5. This happens after selecting the drive,

Here is my config,

config.plist.zip

I confirm that and it happens with latest version 3566.

I get the same screen after selecting to boot OSX using a config.plist with Clover DSDT autopatching enabled....

<?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">
	<key>ACPI</key>
	<dict>
		<key>DSDT</key>
		<dict>
			<key>Debug</key>
			<false/>
			<key>DropOEM_DSM</key>
			<false/>
			<key>Fixes</key>
			<dict>
				<key>AddDTGP_0001</key>
				<true/>
				<key>FixAirport_4000</key>
				<true/>
				<key>FixDarwin_0002</key>
				<true/>
				<key>FixDisplay_0100</key>
				<true/>
				<key>FixHDA_8000</key>
				<true/>
				<key>FixHPET_0010</key>
				<true/>
				<key>FixIPIC_0040</key>
				<true/>
				<key>FixLAN_2000</key>
				<true/>
				<key>FixSATA_0400</key>
				<true/>
				<key>FixShutdown_0004</key>
				<true/>
				<key>FixUSB_1000</key>
				<true/>
			</dict>
			<key>ReuseFFFF</key>
			<false/>
		</dict>

Details of System

System Desktop GA P55aUD3/Intel i5-750/ATI HD5770
Clover legacy boot r3561. Same problem if I replace CLOVERX64.efi with older revision r3469. However r3368 and older (r3259) boot successfully. Clover r3561 also boots successfully on the system if I use a manually patched DSDT in /ACPI/patched
Note the third stage "boot" file was boot6 from r3561 in all tests above.

If I change the "boot file" to boot6 from r3368, I get a hanging blank screen instead of a screen with orange text.

Debug log from unsuccessful boot with CLOVERX64.efi_r3561 attached.

check clover r3566

https://mega.nz/#!qMdBRC5L!rjyMQzgzRaMujj5OZrDjX_G9afzSdn-gD8tiUJflmh4

Same issue persists with r3566 using config.plist with Clover DSDT autopatching enabled....boots OK using config.plist with only manually patched DSDT.

EDIT: Update

The "X64 Exception Type" error when using Clover's DSDT auto-patching on my system was eliminated by using CloverX64 compiled with gcc49 instead of xcode (like official build) - see post#11018.

debug_r3561.log.zip

Sherlocks · June 19, 2016

I get the same screen after selecting to boot OSX using a config.plist with Clover DSDT autopatching enabled....
<?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">
	<key>ACPI</key>
	<dict>
		<key>DSDT</key>
		<dict>
			<key>Debug</key>
			<false/>
			<key>DropOEM_DSM</key>
			<false/>
			<key>Fixes</key>
			<dict>
				<key>AddDTGP_0001</key>
				<true/>
				<key>FixAirport_4000</key>
				<true/>
				<key>FixDarwin_0002</key>
				<true/>
				<key>FixDisplay_0100</key>
				<true/>
				<key>FixHDA_8000</key>
				<true/>
				<key>FixHPET_0010</key>
				<true/>
				<key>FixIPIC_0040</key>
				<true/>
				<key>FixLAN_2000</key>
				<true/>
				<key>FixSATA_0400</key>
				<true/>
				<key>FixShutdown_0004</key>
				<true/>
				<key>FixUSB_1000</key>
				<true/>
			</dict>
			<key>ReuseFFFF</key>
			<false/>
		</dict>
Details of System

System Desktop GA P55aUD3/Intel i5-750/ATI HD5770

Clover legacy boot r3561. Same problem if I replace CLOVERX64.efi with older revision r3469. However r3368 and older (r3259) boot successfully. Clover r3561 also boots successfully on the system if I use a manually patched DSDT in /ACPI/patched

Note the third stage "boot" file was boot6 from r3561 in all tests above.

If I change the "boot file" to boot6 from r3368, I get a hanging blank screen instead of a screen with orange text.

Debug log from unsuccessful boot with CLOVERX64.efi_r3561 attached.

check clover r3566

https://mega.nz/#!qMdBRC5L!rjyMQzgzRaMujj5OZrDjX_G9afzSdn-gD8tiUJflmh4

Sherlocks · June 19, 2016

Anyone who knows kernel bin patch like KextToPatch in config?

나의 LG-F410S 의 Tapatalk에서 보냄

Mohamed Khairy · June 19, 2016

Hi all

I have notebook Asus TP500LNG

I have two problem

First one

It has 8 gb of ram 4gb of them is built in

Macos read only 4gb

Second one

after clover rev 3504 my Nvidia card isn't disabled don't know if patched ssdt is loaded correctly to me after changes done on clover on ssdt section

Here is my darwindump and my clover config and a picture folder

clover.zip

DarwinDumper_2.9.9.3a_AMI_X64_3566_Sierra_mido.zip

Thanks on advance

joevt · June 19, 2016

It has 8 gb of ram 4gb of them is built in

Macos read only 4gb

In the bootlog, the Smbios table 17 says the two DIMMs are from different manufacturers. Later in the bootlog, the spd scanning code only sees the second DIMM.

In Windows, use a program like Thaiphoon Burner (SMBus -> Search for SMB Devices) or RW-Everything (Access -> DIMM SPD), to find the spd devices. List the controller number, the SMBus address, and the spd contents (256 bytes) here. It may be that the built in memory doesn't have an SPD and the BIOS hard codes part of the SMBIOS table 17 data.

Since the DIMMs appear to be only DDR (not DDR3 or DDR4), the XMPDetection option in config.plist does nothing. If the SPD of the built in DIMM can't be read, then maybe setting the Trust option to <true/> might work. If it doesn't, then you will have to specify your DIMMs in the SMBIOS section of the config.plist.

after clover rev 3504 my Nvidia card isn't disabled don't know if patched ssdt is loaded correctly to me after changes done on clover on ssdt section

I think you need to explain why your Nvidia card should be disabled, and how you think that is accomplished by your config.plist and ACPI patches.

Pressing F5 in Clover is supposed to dump patched DSDT, but I don't think that includes SSDTs so I don't know how you're supposed to know if it was added or patched successfully. I think Clover should dump the patched tables to a different folder named something like "post" or "after" or whatever.

The bootlog suggests the patches were successful. First, there's this:

DSDT found in Clover volume OEM folder: EFI\CLOVER\ACPI\patched\DSDT.aml

I guess being found means it is getting used? Maybe Clover should be more explicit about that.

Then later, there's

Table: SSDT  OptTabl  6637 dropped
Table: SSDT  SgPch  3533 dropped
Table: SSDT  SaSsdt   16161 dropped

Those dropped tables are then replaced, as shown by the following

Inserting SSDT-8.AML from EFI\CLOVER\ACPI\patched ... Success
Inserting SSDT-7.AML from EFI\CLOVER\ACPI\patched ... Success
Inserting SSDT-6.AML from EFI\CLOVER\ACPI\patched ... Success

Opening them in MaciASL.app shows those are the same tables that were dropped (OptTabl, SgPch, SaSsdt). Maybe the Clover log should say what tables the files declare.

Micky1979 · June 19, 2016

I think you need to explain why your Nvidia card should be disabled, and how you think that is accomplished by your config.plist and ACPI patches.

look at SSDT-7:

Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (Zero, \_SB.PCI0.RP05.PEGP._ADR)
            _OFF ()
        }

We need that ( calling _OFF ()) for a long battery life and low temperature. This since the display is attached to the igpu and cannot be switched to the discrete one .

BTW here works good, he should look at kernel log for some detailed info..

RehabMan · June 20, 2016

Hi all

I have notebook Asus TP500LNG

I have two problem

First one

It has 8 gb of ram 4gb of them is built in

Macos read only 4gb

Second one

after clover rev 3504 my Nvidia card isn't disabled don't know if patched ssdt is loaded correctly to me after changes done on clover on ssdt section

Here is my darwindump and my clover config and a picture folder

clover.zip

DarwinDumper_2.9.9.3a_AMI_X64_3566_Sierra_mido.zip

Thanks on advance

As far as Nvidia disabling, your problem is not with Clover, but rather your ACPI coding...

You're calling _OFF from _INI. _OFF calls SGOF. SGOF:

        Method (SGOF, 0, Serialized)
        {
            If (LEqual (CCHK (Zero), Zero))
            {
                Return (Zero)
            }

            Store (Zero, ONOF)
            Store (\_SB.PCI0.LPCB.EC0.RRAM, 0x0521)
            Local0
            And (Local0, 0xCF, Local0)
            \_SB.PCI0.LPCB.EC0.WRAM (0x0521, Local0)
            \_SB.PCI0.LPCB.EC0.WRAM (0x0520, 0x95)
            \_SB.PCI0.LPCB.EC0.WRAM (0x03A4, Zero)
            \_SB.PCI0.LPCB.EC0.WRAM (0x03A5, Zero)
            Store (\_SB.PCI0.LPCB.EC0.RRAM, 0x0575)
            Local0
            \_SB.PCI0.LPCB.EC0.WRAM (0x0576, Local0)
            Store (LCTL, ELCT)
            Store (SVID, HVID)
            Store (SDID, HDID)
            Store (LREN, LTRE)
            Store (One, LNKD)
            While (LNotEqual (LNKS, Zero))
            {
                Sleep (One)
            }

            SGPO (HLRS, One)
            SGPO (PWEN, Zero)
            Return (Zero)
        }

As you can see, it manipulates the EC. EC is not ready when _INI is called. You can read about it in the ACPI spec. The EC cannot be used until the host EC driver calls _REG in EC scope (with the correct params... again, details in the ACPI spec). You may already know about this because I see the call to SPIN in your _REG code in DSDT, which usually comes from _OFF. But you may have not looked at methods that _OFF calls, such as SGOF. In summary, all code that relies on the EC in the _OFF code path must be moved to _REG.

You need to move all the EC related code in SGOF and move it to be executed when _REG is called to indicate the EC is ready (move means delete from SGOF and add to be executed in _REG).

Also, don't forget that config.plist/ACPI/SortedOrder must be used to set SSDT load order. For all practical purposes, SSDT load order without it is non-deterministic. Also, DropOem=true is required since you have patched SSDTs in ACPI/patched. And you should plan on including all non-dynamic SSDTs in ACPI/patched. You cannot use DropTables to drop individual SSDTs so you can replace them with those in ACPI/patched. The ACPI loader is single pass, therefore order dependent. Individual table drops, followed by replacement in ACPI/patched changes the order of the SSDTs as seen by the ACPI loader.

For highly coupled SSDTs, breaking the order breaks the code.

There are cases where you can drop individual tables and replace them. Specifically, if you drop all tables that are dependent on each other, eg. the order dependent SSDT set..., then you can replace that set with ACPI/patched content, but you still must insure they load in the original order. For example, one obvious exception to the "don't drop/replace individual tables" is the one where all the tables you're dropping/replacing are a group of tables at the end.

Mohamed Khairy · June 20, 2016

In the bootlog, the Smbios table 17 says the two DIMMs are from different manufacturers. Later in the bootlog, the spd scanning code only sees the second DIMM.

In Windows, use a program like Thaiphoon Burner (SMBus -> Search for SMB Devices) or RW-Everything (Access -> DIMM SPD), to find the spd devices. List the controller number, the SMBus address, and the spd contents (256 bytes) here. It may be that the built in memory doesn't have an SPD and the BIOS hard codes part of the SMBIOS table 17 data.

Since the DIMMs appear to be only DDR (not DDR3 or DDR4), the XMPDetection option in config.plist does nothing. If the SPD of the built in DIMM can't be read, then maybe setting the Trust option to <true/> might work. If it doesn't, then you will have to specify your DIMMs in the SMBIOS section of the config.plist.

I think you need to explain why your Nvidia card should be disabled, and how you think that is accomplished by your config.plist and ACPI patches.

Pressing F5 in Clover is supposed to dump patched DSDT, but I don't think that includes SSDTs so I don't know how you're supposed to know if it was added or patched successfully. I think Clover should dump the patched tables to a different folder named something like "post" or "after" or whatever.

The bootlog suggests the patches were successful. First, there's this:
DSDT found in Clover volume OEM folder: EFI\CLOVER\ACPI\patched\DSDT.aml
I guess being found means it is getting used? Maybe Clover should be more explicit about that.

Then later, there's
Table: SSDT  OptTabl  6637 dropped
Table: SSDT  SgPch  3533 dropped
Table: SSDT  SaSsdt   16161 dropped
Those dropped tables are then replaced, as shown by the following
Inserting SSDT-8.AML from EFI\CLOVER\ACPI\patched ... Success
Inserting SSDT-7.AML from EFI\CLOVER\ACPI\patched ... Success
Inserting SSDT-6.AML from EFI\CLOVER\ACPI\patched ... Success
Opening them in MaciASL.app shows those are the same tables that were dropped (OptTabl, SgPch, SaSsdt). Maybe the Clover log should say what tables the files declare.

thanks

using first program Thaiphoon Burner it reads only second memory but built in one is unknown

using rw everything cant read them

about nivida card it is useless on the notebook on macos so disabling it for long battery life and less temp

look at SSDT-7:
Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (Zero, \_SB.PCI0.RP05.PEGP._ADR)
            _OFF ()
        }
We need that ( calling _OFF ()) for a long battery life and low temperature. This since the display is attached to the igpu and cannot be switched to the discrete one .

BTW here works good, he should look at kernel log for some detailed info..

yup

As far as Nvidia disabling, your problem is not with Clover, but rather your ACPI coding...

You're calling _OFF from _INI. _OFF calls SGOF. SGOF:
        Method (SGOF, 0, Serialized)
        {
            If (LEqual (CCHK (Zero), Zero))
            {
                Return (Zero)
            }

            Store (Zero, ONOF)
            Store (\_SB.PCI0.LPCB.EC0.RRAM, 0x0521)
            Local0
            And (Local0, 0xCF, Local0)
            \_SB.PCI0.LPCB.EC0.WRAM (0x0521, Local0)
            \_SB.PCI0.LPCB.EC0.WRAM (0x0520, 0x95)
            \_SB.PCI0.LPCB.EC0.WRAM (0x03A4, Zero)
            \_SB.PCI0.LPCB.EC0.WRAM (0x03A5, Zero)
            Store (\_SB.PCI0.LPCB.EC0.RRAM, 0x0575)
            Local0
            \_SB.PCI0.LPCB.EC0.WRAM (0x0576, Local0)
            Store (LCTL, ELCT)
            Store (SVID, HVID)
            Store (SDID, HDID)
            Store (LREN, LTRE)
            Store (One, LNKD)
            While (LNotEqual (LNKS, Zero))
            {
                Sleep (One)
            }

            SGPO (HLRS, One)
            SGPO (PWEN, Zero)
            Return (Zero)
        }
As you can see, it manipulates the EC. EC is not ready when _INI is called. You can read about it in the ACPI spec. The EC cannot be used until the host EC driver calls _REG in EC scope (with the correct params... again, details in the ACPI spec). You may already know about this because I see the call to SPIN in your _REG code in DSDT, which usually comes from _OFF. But you may have not looked at methods that _OFF calls, such as SGOF. In summary, all code that relies on the EC in the _OFF code path must be moved to _REG.

You need to move all the EC related code in SGOF and move it to be executed when _REG is called to indicate the EC is ready (move means delete from SGOF and add to be executed in _REG).

Also, don't forget that config.plist/ACPI/SortedOrder must be used to set SSDT load order. For all practical purposes, SSDT load order without it is non-deterministic. Also, DropOem=true is required since you have patched SSDTs in ACPI/patched. And you should plan on including all non-dynamic SSDTs in ACPI/patched. You cannot use DropTables to drop individual SSDTs so you can replace them with those in ACPI/patched. The ACPI loader is single pass, therefore order dependent. Individual table drops, followed by replacement in ACPI/patched changes the order of the SSDTs as seen by the ACPI loader.

For highly coupled SSDTs, breaking the order breaks the code.

There are cases where you can drop individual tables and replace them. Specifically, if you drop all tables that are dependent on each other, eg. the order dependent SSDT set..., then you can replace that set with ACPI/patched content, but you still must insure they load in the original order.

thanks

I will try this

cecekpawon · June 20, 2016

Is there a possibility for packing theme files into archives like tar or dmg or iso, and having Clover read them from packed instead of having them on filesystem as individual files?

Would like to hear more this awesome features ...

Hentz · June 20, 2016

Someone has an idea of where it may come this random crash?

It reboots one or two times and it goes without a glich.... strange !

Clover r3561

Merci

Riley Freeman · June 20, 2016

check clover r3566

https://mega.nz/#!qMdBRC5L!rjyMQzgzRaMujj5OZrDjX_G9afzSdn-gD8tiUJflmh4

I'm using this on the laptop now. Two things I've noticed in Sierra (after a clean install). The HD4000 IOGraphics patch that I use to fix the exploding Apple logo on second stage boot isn't working. Also, I haven't had any kernel panics from AppleALC so far.

Has something changed since 3561 with kext/kernelcache or whatever?

Sherlocks · June 20, 2016

I'm using this on the laptop now. Two things I've noticed in Sierra (after a clean install). The HD4000 IOGraphics patch that I use to fix the exploding Apple logo on second stage boot isn't working. Also, I haven't had any kernel panics from AppleALC so far.

Has something changed since 3561 with kext/kernelcache or whatever?

You can check clover commit. Slice did that kernelcache blacklist return. Did you use my second stage boot fix? Yosemite and el capitan use same binary about second stage. But its changed in sierra.

나의 LG-F410S 의 Tapatalk에서 보냄

Riley Freeman · June 20, 2016

Yep I have the new fix for Sierra. Both are in my KextsToPatch section. I had a look through the recent commits and saw some going over and back with kernelcache blacklisting. Just wondering if this might have fixed the AppleALC panics or broken my patch for HD4000.

The old patch is working fine for El Capitan on the same system, but I don't know if that is cache related as this Sierra install is new.

I enabled debug and checked the debug.log but can't see any sign of trouble.

Sherlocks · June 20, 2016

Yep I have the new fix for Sierra. Both are in my KextsToPatch section. I had a look through the recent commits and saw some going over and back with kernelcache blacklisting. Just wondering if this might have fixed the AppleALC panics or broken my patch for HD4000.

The old patch is working fine for El Capitan on the same system, but I don't know if that is cache related as this Sierra install is new.

I enabled debug and checked the debug.log but can't see any sign of trouble.

Your laptop not work KextToPatch in Sierra? Sorry my english is bad.

Commit of Kernel cache return is related in "without cache boot".

My old laptop works Clover HD 3000 binary patch about HDMI,DSUB and ALC270 in Sierra

나의 LG-F410S 의 Tapatalk에서 보냄

Riley Freeman · June 20, 2016

After a couple of reboots it seems to be applying the HD4000 fix now. So that's OK.

Patching must have been working to some degree because I need the AsusAICPUPM patch to boot.

arsradu · June 21, 2016

Ok, so Arbitrary method to inject Layout-id...no go.

I tried injecting layout ID as integer, data, string (in hex)... Nothing. Checking ioreg after each reboot and the layout ID for HDEF@1F,3 doesn't move an inch. It's still <00 00 00 00>. HDAEnabler injects Layout ID 5 into another device. So that didn't work either.

Also tried your test config, Micky. Unfortunately with the same result.

Any other idea?

cecekpawon · June 21, 2016

ssdt?

arsradu · June 21, 2016

ssdt?

Haven't tried that. But something else worked: device-properties injection (like we did for second-stage boot logo). Finally sound!

<key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
	<dict>
		<key>PinConfigurations</key>
		<data>
		</data>
		<key>layout-id</key>
		<data>
		AQAAAA==
		</data>
	</dict>

Thanks, Riley, for the idea.

cecekpawon · June 21, 2016

yep you should choose one: efi strings / arbitrary / inject device, not to mixed them. ** ssdt never failed. congrat!

RehabMan · June 21, 2016

Ok, so Arbitrary method to inject Layout-id...no go.

I tried injecting layout ID as integer, data, string (in hex)... Nothing. Checking ioreg after each reboot and the layout ID for HDEF@1F,3 doesn't move an inch. It's still <00 00 00 00>. HDAEnabler injects Layout ID 5 into another device. So that didn't work either.

Also tried your test config, Micky. Unfortunately with the same result.

Any other idea?

You should attach your config.plist and ioreg (v2.1).

yep you should choose one: efi strings / arbitrary / inject device, not to mixed them. ** ssdt never failed. congrat!

Yes... these options are mutually exclusive. And I don't remember which take priority over the other...

Slice · June 21, 2016

In theory efi strings will overwrite DSDT/SSDT _DSM settings so take priority.

But they work only if the device already present in DSDT. If not then strings will be ignored.

RehabMan · June 21, 2016

In theory efi strings will overwrite DSDT/SSDT _DSM settings so take priority.

Actually that one I do know... _DSM/ACPI injection will always override what Clover does.

But they work only if the device already present in DSDT. If not then strings will be ignored.

Yes, there must always be an ACPI identity for the device (obviously always present if using ACPI, but also need the identity for Clover EFI injects), otherwise ignored by OS X.

Sherlocks · June 21, 2016

@Slice, i have a question. Where Osx read Vram size bios(DVMT)? Only graphic kext? Or kernel? Have we chance to change DVMT in clover? Ex. Fake

나의 LG-F410S 의 Tapatalk에서 보냄

Slice · June 21, 2016

@Slice, i have a question. Where Osx read Vram size bios(DVMT)? Only graphic kext? Or kernel? Have we chance to change DVMT in clover? Ex. Fake

나의 LG-F410S 의 Tapatalk에서 보냄

Search in DSDT

Clover General discussion

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites