Clover Problems and Solutions

Slice · July 21, 2015

It was Chameleon idea to list all possible cards with all possible subsystems ID. There was a special thread on a forum to collect all data.

The idea was dead. It's impossible to follow market.

I propose another idea. Let bootloader knows only classes of cards and let users to customize all they want.

	<key>Devices</key>
	<dict>
		<key>NoDefaultProperties</key>
		<false/>
		<key>AddProperties</key>
		<array>
			<dict>
				<key>Device</key>
				<string>NVidia</string>
				<key>Key</key>
				<string>AAPL,HasPanel</string>
				<key>Value</key>
				<data>AQAAAA==</data>
			</dict>
			<dict>
				<key>Device</key>
				<string>NVidia</string>
				<key>Key</key>
				<string>AAPL,Haslid</string>
				<key>Value</key>
				<data>AQAAAA==</data>
			</dict>
		</array>

RehabMan · July 21, 2015

It was Chameleon idea to list all possible cards with all possible subsystems ID. There was a special thread on a forum to collect all data.

The idea was dead. It's impossible to follow market.

I propose another idea. Let bootloader knows only classes of cards and let users to customize all they want.
	<key>Devices</key>
	<dict>
		<key>NoDefaultProperties</key>
		<false/>
		<key>AddProperties</key>
		<array>
			<dict>
				<key>Device</key>
				<string>NVidia</string>
				<key>Key</key>
				<string>AAPL,HasPanel</string>
				<key>Value</key>
				<data>AQAAAA==</data>
			</dict>
			<dict>
				<key>Device</key>
				<string>NVidia</string>
				<key>Key</key>
				<string>AAPL,Haslid</string>
				<key>Value</key>
				<data>AQAAAA==</data>
			</dict>
		</array>
 

Currently, the default property injection will overwrite what is placed in AddProperties (order dependency?)

Unless the properties listed in AddProperties are not injected by default (for that device), NoDefaultProperties needs to be true for AddProperties to work as expected.

This is just fine, as all properties injected by default can easily be seen in ioreg and copied to AddProperties as desired.

TheRacerMaster · July 21, 2015

It was Chameleon idea to list all possible cards with all possible subsystems ID. There was a special thread on a forum to collect all data.

The idea was dead. It's impossible to follow market.

I propose another idea. Let bootloader knows only classes of cards and let users to customize all they want.

I think the current method is OK, just make it so the users can override some of the properties. Some properties (such as AAPL,boot-display) can be auto-detected by Clover (since this is applied to the port that connects to the primary display), which is easier than manually modifying it. Otherwise, it works fine. I also researched info for the cards and changed some of their names/FakeIDs/default framebuffers (they're in the edited version).

Also, does the PluginType option not work anymore? Or does it only work when generating C-States/P-States?

Slice · July 21, 2015

Also, does the PluginType option not work anymore? Or does it only work when generating C-States/P-States?

Yes, It will be written into SSDT generated for P-states. What else?

TheRacerMaster · July 21, 2015

Yes, It will be written into SSDT generated for P-states. What else?

Would it be possible to do it in the OEM SSDT? I can use my OEM SSDTs without any problems (but I need to inject _DSM method into them to set plugin-type).

Also, I was wrong about the AMD device properties. Setting a custom model string (using AddProperties in config.plist) works fine and overrides the name the injection does. So the naming issue shouldn't be a problem. The default model names/framebuffers/fakeids should be updated, though.

Slice · July 22, 2015

Would it be possible to do it in the OEM SSDT? I can use my OEM SSDTs without any problems (but I need to inject _DSM method into them to set plugin-type).

If you can make your own SSDT then you can add here the method _DSM

    Scope (\_PR.C000)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                     0x03
                })
            }

            Return (Package (0x02)
            {
                "plugin-type", 
                One
            })
        }
    }

Also, I was wrong about the AMD device properties. Setting a custom model string (using AddProperties in config.plist) works fine and overrides the name the injection does. So the naming issue shouldn't be a problem. The default model names/framebuffers/fakeids should be updated, though.

When sf.net will be up I will look your updates.

TheRacerMaster · July 30, 2015

Another Intel graphics correction, 0x0152 is HD 2500, not HD 4000. iMac13,X had some CPUs with HD 2500 (i5-3470, etc.) and some CPUs with HD 4000 (i7-3770, etc.). On iMacs with HD 2500 it still shows up as HD 4000. It's purely cosmetic and Apple probably left it as HD 4000 since the IGPU doesn't show in System Information on iMacs and they assumed no one would (normally) see it.

Original:

  { 0x0152, "Intel HD Graphics 4000"  },  //iMac

Should be:

  { 0x0152, "Intel HD Graphics 2500"  },  //iMac

Also, here is another ID:

  { 0x010A, "Intel HD Graphics P3000"  },  //Xeon E3 1200 v1, needs FakeID

Slice · July 31, 2015

Another Intel graphics correction, 0x0152 is HD 2500, not HD 4000. iMac13,X had some CPUs with HD 2500 (i5-3470, etc.) and some CPUs with HD 4000 (i7-3770, etc.). On iMacs with HD 2500 it still shows up as HD 4000. It's purely cosmetic and Apple probably left it as HD 4000 since the IGPU doesn't show in System Information on iMacs and they assumed no one would (normally) see it.

Original:
  { 0x0152, "Intel HD Graphics 4000"  },  //iMac
Should be:
  { 0x0152, "Intel HD Graphics 2500"  },  //iMac
Also, here is another ID:
  { 0x010A, "Intel HD Graphics P3000"  },  //Xeon E3 1200 v1, needs FakeID

Accepted into 3253, as well as some names for AMD.

TheRacerMaster · August 2, 2015

The VideoPorts option in config.plist behaves strangely for me. I have it set like this...

		<key>VideoPorts</key>
		<integer>4</integer>

...but for some reason, Clover interprets this number as 114 (?):

20:139  0:000  (AtiPorts) Nr of ports set to: 114

And as a result, properties are injected for 10 ports in the IORegistry under the GFX0 device (assuming Clover or the AMD drivers or something else cap it to 10), although since they are invalid they only appear in the GFX0 device (not under the Framebuffer, so it's mainly cosmetic).

Maniac10 · August 3, 2015

I've been using VideoPorts exactly like that and it always did what was expected. Perhaps there's an error in the plist?

		<key>VideoPorts</key>
		<integer>4</integer>

22:552  0:000   use N ports setting from config.plist: 4
22:552  0:000  (AtiPorts) Nr of ports set to: 4

Which Clover rev? You should upload you config and boot.log so devs can study your case.

TheRacerMaster · August 6, 2015

Ah sorry, here's my config.plist & log. Using the latest revision of Clover (3253).

Edit: Fixed the archive, sorry about that.

Archive.zip

smolderas · August 6, 2015

The VideoPorts option in config.plist behaves strangely for me. I have it set like this...
		<key>VideoPorts</key>
		<integer>4</integer>
...but for some reason, Clover interprets this number as 114 (?):
20:139  0:000  (AtiPorts) Nr of ports set to: 114
And as a result, properties are injected for 10 ports in the IORegistry under the GFX0 device (assuming Clover or the AMD drivers or something else cap it to 10), although since they are invalid they only appear in the GFX0 device (not under the Framebuffer, so it's mainly cosmetic).

Neither am I the right person, nor have I right to say anything about the code, but it seems the code is correct:

Prop = GetProperty (DictPointer, "VideoPorts");
      if (Prop != NULL) {
        gSettings.VideoPorts   = (UINT16)GetPropertyInteger (Prop, 0);
      }

and the declaration of getProperyInteger:

INTN
GetPropertyInteger (
  TagPtr Prop,
  INTN Default
  )
{
  if (Prop == NULL) {
    return Default;
  }

  if (Prop->type == kTagTypeInteger) {
    return (INTN)Prop->string;    
  } else if ((Prop->type == kTagTypeString) && Prop->string) {
    if ((Prop->string[1] == 'x') || (Prop->string[1] == 'X')) {
      return (INTN)AsciiStrHexToUintn (Prop->string);
    }

    if (Prop->string[0] == '-') {
      return -(INTN)AsciiStrDecimalToUintn (Prop->string + 1);
    }

    return (INTN)AsciiStrDecimalToUintn (Prop->string);
  }
  return Default;
}

As long as you are not on a 32-Bit CPU and the value is not greater than 4 bytes, you are good to go ...

Ah sorry, here's my config.plist & log. Using the latest revision of Clover (3253).

There are 2 DSDT files in that archive.zip.

You can check the plist-files for errors with the following command:

plutil -lint config.plist

TheRacerMaster · August 6, 2015

Oops, had two archives with the same name and attached the right one this time. I checked the plist with plutil and it didn't report any errors:

~ ❯❯❯ plutil -lint /Volumes/EFI/EFI/CLOVER/config.plist
/Volumes/EFI/EFI/CLOVER/config.plist: OK

I used Xcode to edit it.

Maniac10 · August 6, 2015

The plist is fine and the VideoPorts key is correct, but I believe the framebuffer should be "Radeon", not "RadeonFramebuffer". At least that's how it's been working for me since I got the 270x.

TheRacerMaster · August 8, 2015

Hmm, it works fine with Radeon instead of RadeonFramebuffer (even though they both seem to be the same, they both inject RadeonFramebuffer in the IORegistry).

RehabMan · August 9, 2015

Trying to build current Clover with CGP:

[CC] Reclaim
/Users/Admin/Projects/clover.git/toolchain/cross/lib/gcc/x86_64-clover-linux-gnu/4.9.2/../../../../x86_64-clover-linux-gnu/bin/ld: cannot open linker script file /Users/Admin/Projects/clover.git/edk2/BaseTools/Scripts/gcc4.9-ld-script: No such file or directory
[CC] FtwMisc
collect2: error: ld returned 1 exit status
make: *** [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/DEBUG/WatchdogTimer.dll] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Core/RuntimeDxe/RuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/PCD/Dxe/Pcd]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/OsxDxeIpl/DxeIpl]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/OsxDxeCore/DxeMain]


build.py...
 : error F002: Failed to build module
	/Users/Admin/Projects/clover.git/edk2/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf [X64, GCC49, RELEASE]

- Failed -
Build end time: 09:59:36, Aug.09 2015
Build total time: 00:00:16

Cloverx64 release  ERROR!!


Ejecting RAM disk
"disk3" unmounted.
"disk3" ejected.

Some change in edk2 not accounted for?

Slice · August 10, 2015

Trying to build current Clover with CGP:

[CC] Reclaim
/Users/Admin/Projects/clover.git/toolchain/cross/lib/gcc/x86_64-clover-linux-gnu/4.9.2/../../../../x86_64-clover-linux-gnu/bin/ld: cannot open linker script file /Users/Admin/Projects/clover.git/edk2/BaseTools/Scripts/gcc4.9-ld-script: No such file or directory
[CC] FtwMisc
collect2: error: ld returned 1 exit status
make: *** [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/DEBUG/WatchdogTimer.dll] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Core/RuntimeDxe/RuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/PCD/Dxe/Pcd]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/OsxDxeIpl/DxeIpl]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe]


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/Admin/Projects/clover.git/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/OsxDxeCore/DxeMain]


build.py...
 : error F002: Failed to build module
	/Users/Admin/Projects/clover.git/edk2/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf [X64, GCC49, RELEASE]

- Failed -
Build end time: 09:59:36, Aug.09 2015
Build total time: 00:00:16

Cloverx64 release  ERROR!!


Ejecting RAM disk
"disk3" unmounted.
"disk3" ejected.

Some change in edk2 not accounted for?

:thumbsdown_anim:

The problem is EDK2 bad.

SInce revision 3000 I implemented Link Time Optimization into our build rules. The idea came from EDK2 developers but they can't implement it because of mistakes in IntelFrameworkPkg that nobody going to correct. I did it in my Clover sources (Clover/Patches_for_EDK2/BaseTools/Source/Python/AutoGen/GenC.py). They don't because it is ugly hack. Now we have LTO while EDK2 still not have it.

With LTO we reduces sizes of CloverX64.efi and of BOOT file. The last one is essential for some users (Zenith432) who have very low EBDA region address. Standard DUET will overlap it. With LTO legacy part became smaller and we can move page descriptors to lower addresses not overlaps EBDA.

We can, vanilla DUET no.

New EDK2 changes contradicts our compiling rules so the best I can make now it is just reverting their changes to our working rules.

For a future I want to claim: DONT UPDATE EDK2 until you are good developer to fight with the problems.

For this reason I don't see a reason to use CGP. You may live simpler way

svn up

./ebuild.sh

RehabMan · August 10, 2015

дьявол.gif

The problem is EDK2 bad.

SInce revision 3000 I implemented Link Time Optimization into our build rules. The idea came from EDK2 developers but they can't implement it because of mistakes in IntelFrameworkPkg that nobody going to correct. I did it in my Clover sources (Clover/Patches_for_EDK2/BaseTools/Source/Python/AutoGen/GenC.py). They don't because it is ugly hack. Now we have LTO while EDK2 still not have it.

With LTO we reduces sizes of CloverX64.efi and of BOOT file. The last one is essential for some users (Zenith432) who have very low EBDA region address. Standard DUET will overlap it. With LTO legacy part became smaller and we can move page descriptors to lower addresses not overlaps EBDA.

We can, vanilla DUET no.

New EDK2 changes contradicts our compiling rules so the best I can make now it is just reverting their changes to our working rules.

For a future I want to claim: DONT UPDATE EDK2 until you are good developer to fight with the problems.

For this reason I don't see a reason to use CGP. You may live simpler way

svn up

./ebuild.sh

This is a new machine just now getting edk, so it is getting current source. No choice to get an older EDK...

Just tried your solution now... same result. Tried also './ebuild.sh -cleanall && ./ebuild.sh', no dice...same result.

Is there documentation for "how to build Clover" without CGP?

Edit: Got it to work.

Started sniffing around the files in edk2/Clover. Didn't find a README, nor any *.txt files that were any help. But I did find update.sh. It has a line at the very end:

echo "now you can do: cp -R Patches_for_EDK2/* ../"

So, I did:

cp -R Patches_for_EDK2/* ../

From edk2/Clover, and then was able to build.

droples · August 10, 2015

Clover3255,EDK2-18198 - No problems with the compilation

iMac-Droplets:edk2 droplets$ svn up
Updating '.':
A    StdLib/Include/ieeefp.h
A    StdLib/Include/Aarch64
A    StdLib/Include/Aarch64/arm-gcc.h
....
U    BaseTools/Bin/Win32/BootSectImage.exe
U    BaseTools/Bin/Win32/TianoCompress.exe
U    BaseTools/Bin/Win32/GenPatchPcdTable.exe
Updated external to revision 86.

At revision 18198.
iMac-Droplets:Clover droplets$ svn up
Updating '.':
U    Clover.dsc
U    Patches_for_EDK2/Conf/tools_def.txt
....
U    build_gcc5.sh
Updated to revision 3255.
........
........
iMac-Droplets:edk2 droplets$ 
iMac-Droplets:Clover droplets$ ./buildgcc-4.9.sh -x64 -all
- Building GCC toolchain for x64
..........
..........
./makepkg
........
--------------------------
 Building process complete!
 --------------------------
 Build info.
 ===========
  Package name: Clover_v2.3k_r3255.pkg
  MD5:          fdf49b27fc9801088d8ccdd4ad148a92
  Version:      v2.3k
  Stage:        v2.3k
  Date/Time:    2015-08-10 21:53:07
  Built by:     droplets
  Copyright     2012-2015

  adding: Clover_v2.3k_r3255.pkg (deflated 0%)
  adding: Clover_v2.3k_r3255.pkg.md5 (stored 0%)
total 91720
drwxr-xr-x   9 droplets  staff       306 Aug 10 21:56 .
drwxr-xr-x  14 droplets  staff       476 Aug 10 21:56 ..
-rw-r--r--@  1 droplets  staff  23306361 Aug 10 21:56 Clover_v2.3k_r3255.pkg
-rw-r--r--   1 droplets  staff        68 Aug 10 21:56 Clover_v2.3k_r3255.pkg.md5
-rw-r--r--   1 droplets  staff  23263186 Aug 10 21:56 Clover_v2.3k_r3255.zip
drwxr-xr-x   3 droplets  staff       102 Aug 10 21:55 Resources
drwxr-xr-x   7 droplets  staff       238 Aug 10 21:55 build
drwxr-xr-x   3 droplets  staff       102 Aug 10 21:56 package
drwxr-xr-x   7 droplets  staff       238 Aug 10 21:55 utils
iMac-Droplets:CloverPackage droplets$

dgsga · August 11, 2015

I like to dispense with gcc and CGP altogether and just use clang to build clover. At the moment it is possible to build clover natively in clang with a minor tweak to nvidia.c in rEFIt_UEFI. This gives a CLOVERX64.efi which is 629KB vs 644KB for gcc5. The nvidia.c tweak is to remove lines 1934 and 1936 as the if (nvcard) statement always returns true. Quite a difference in size so code must be more efficient...

Slice · August 11, 2015

I like to dispense with gcc and CGP altogether and just use clang to build clover. At the moment it is possible to build clover natively in clang with a minor tweak to nvidia.c in rEFIt_UEFI. This gives a CLOVERX64.efi which is 629KB vs 644KB for gcc5. The nvidia.c tweak is to remove lines 1934 and 1936 as the if (nvcard) statement always returns true. Quite a difference in size so code must be more efficient...

I know that CloverX64.efi can be compiled by Clang. But boot file=Efildr20=CloverEFI can't.

dgsga · August 12, 2015

I comment out a couple of unneeded inf's (related to SCSI and IDE) to get efildr to compile

Slice · August 12, 2015

I comment out a couple of unneeded inf's (related to SCSI and IDE) to get efildr to compile

Is it working? I got only blinking underscore while the same compiled by gcc working.

calibre™ · August 12, 2015

This is a new machine just now getting edk, so it is getting current source. No choice to get an older EDK...

Just tried your solution now... same result. Tried also './ebuild.sh -cleanall && ./ebuild.sh', no dice...same result.

Is there documentation for "how to build Clover" without CGP?

Edit: Got it to work.

Started sniffing around the files in edk2/Clover. Didn't find a README, nor any *.txt files that were any help. But I did find update.sh. It has a line at the very end:
echo "now you can do: cp -R Patches_for_EDK2/* ../"
So, I did:
cp -R Patches_for_EDK2/* ../
From edk2/Clover, and then was able to build.

This workaround is good?

Slice · August 12, 2015

It is not workaround, it is official way to do. It is my way as I didn't use CGP.

cd Clover
./update.sh
cp -R Patches_for_EDK2/* ../
./ebuild.sh

Clover Problems and Solutions

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