Jump to content

Clover General discussion


ErmaC
29,872 posts in this topic

Recommended Posts

1 hour ago, Slice said:

You repeated previous post which is not containing information. You also repeat the mistake. Not 5903 but 5093.

Did you change one file? Or the whole USB stick?

Can you make preboot.log in the both cases?

What about Clover 5101, 5100, 5099 etc?

Clover breaks at rev. 5100 attached preboot.log for working 5099 and not working 5100. I appreciate your help, johnm

preboot5099.log

preboot5100.log

Link to comment
Share on other sites

10 hours ago, jmacie said:

Clover breaks at rev. 5100 attached preboot.log for working 5099 and not working 5100. I appreciate your help, johnm

preboot5099.log

preboot5100.log

Good.

Test, please, attached version if the problem is already resolved. If not then do the follow:

1. Boot with 5099 to Clover GUI. Press F5. Save /EFI/CLOVER/ACPI/origin/DSDT-XXX.aml somewhere. Mark it as 5099.

2. Boot with 5102 attached here, press F5 and save the same file. It will be few bytes different.

Attach both files here. I will analyse them.

CLOVERX64.efi.zip

  • Like 2
Link to comment
Share on other sites

7 hours ago, Slice said:

Good.

Test, please, attached version if the problem is already resolved. If not then do the follow:

1. Boot with 5099 to Clover GUI. Press F5. Save /EFI/CLOVER/ACPI/origin/DSDT-XXX.aml somewhere. Mark it as 5099.

2. Boot with 5102 attached here, press F5 and save the same file. It will be few bytes different.

Attach both files here. I will analyse them.

CLOVERX64.efi.zip

Attached did not work, sending dsdt's, Thank you, they are the same byte size though

DSDTs.aml.zip

Edited by jmacie
Link to comment
Share on other sites

2 minutes ago, Slice said:

Sorry, but I gave you Clover

Starting Clover revision: 5102 (c++_globals, commit 81fdb66)

while in your preboot.log

0:100  0:000  Starting Clover revision: 5102 (master, commit 12d559ae)

Yeah, sorry I don't know what any of that means, but I appreciate your time

Link to comment
Share on other sites

Just now, jmacie said:

Yeah, sorry I don't know what any of that means, but I appreciate your time

Can you change one file CLOVERX64.efi with the version I uploaded?

Or may be replace BOOTX64.efi by the file CLOVERX64.efi renamed to BOOTX64.efi

Link to comment
Share on other sites

28 minutes ago, Slice said:

Can you change one file CLOVERX64.efi with the version I uploaded?

Or may be replace BOOTX64.efi by the file CLOVERX64.efi renamed to BOOTX64.efi

Yes, now working. I put in both your CLOVERX64.efi  and also put it in boot folder and renamed to BOOTX64.efi. Thank you. What will I do in the future?

Link to comment
Share on other sites

Hey all,
I'm not sure if this is the best place to post this. I have a mac pro 2010, I'm trying to run Clover so I can access the bootloader with a non UEFI graphics card (Powercolor Vega 56).
I can't get the bootloader to show when this card is installed, it just gives me a black screen, I assume it has something to do with my config.plist.
I've tried running the config-genconfig but it just gives me a segmentation 11 fault.
I'm running Mojave 10.14.6. I'm really not sure what to do anymore.
Cheers.

Link to comment
Share on other sites

On 12/29/2019 at 12:35 AM, joevt said:

I was able to do this without using OpenCore or Clover on my MacPro3,1 Mac Pro (Early 2008) running Catalina 10.15.

 

There's a set of nvram properties starting at 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:AAPL,PathProperties0000 and counting up 0001, 0002, etc. I made a script to do the following:

1) convert nvram properties to binary

2) translate that to plist using gfxutil

3) find ioregistry device tree plane paths of upstream bridge of Thunderbolt controllers

4) use output from gfxutil to convert ioregistry device tree plane paths to efi device paths

5) modify plist with new properties using those efi device paths

6) convert plist to binary using gfxutil

7) convert binary to nvram properties

 

The attached example includes my modified/updated version of gfxutil (rewritten to use edk2 device path library). It adds PCI-Thunderbolt properties to my four Thunderbolt controllers. This is not sufficient to improve or change any behavior (there is no difference in behavior with or without this property). This is probably an incorrect use of device properties because the PCI-Thunderbolt property is normally set by a function in an ACPI SSDT and is therefore stored in the IO Registry as type Number. The Apple Device Properties Protocol can only create IO Registry properties of type Data (just a series of bytes). A proper solution will require a kext or SSDT. In the case of an SSDT, something like Clover or OpenCore is required, therefore you might as well use them to set properties instead of this method...

 

https://github.com/acidanthera/gfxutil

joevt_gfxutil.zip

Why don't you create your fork in Github? It has cool patches.

 

Edited by startergo
Link to comment
Share on other sites

8 hours ago, startergo said:

Why don't you create your fork in Github? It has cool patches.

  

It's at https://github.com/joevt/gfxutil

 

The zip file contains a script and BBEdit worksheet that are not in GitHub.

 

The script has some useful shell functions (for EFI Boot vars, getting and setting AAPL,PathProperties). The script also aliases the gfxutil command so I don't need to install it in one of the path directories.

The BBEdit worksheet shows how to use the script (just use the "source" command to load it). And it contains an example of adding device properties to AAPL,PathProperties.

 

Link to comment
Share on other sites

1 hour ago, joevt said:

It's at https://github.com/joevt/gfxutil

 

The zip file contains a script and BBEdit worksheet that are not in GitHub.

 

The script has some useful shell functions (for EFI Boot vars, getting and setting AAPL,PathProperties). The script also aliases the gfxutil command so I don't need to install it in one of the path directories.

The BBEdit worksheet shows how to use the script (just use the "source" command to load it). And it contains an example of adding device properties to AAPL,PathProperties.

 

Nice. Joe why don't you create a pull request to merge it in the acidanthera?

Link to comment
Share on other sites

6 hours ago, joevt said:

I dunno. The changes might be too great? It adds a dependency on edk2, so the gfxutil source code folder needs to exist next to the edk2 source folder.

That should not be a problem. EDK folder is always inside Open Core package for building. You can't build OC without the EDK folder either.

Link to comment
Share on other sites

×
×
  • Create New...