Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

Badruzeus
Badruzeus
Posted
Posted
36 minutes ago, chris1111 said:

I have a lots of Anim theme and all working perfect no issue

I try also BGM and black_green without any issue

Interesting! Might be caused by different display sizes? Mine is just 800x600. Using animated theme, try with 768, 600 or even 480px resolution height and let me know (alternatively pressing 'F9' on Clover GUI).

 

Or if you have more recent prebuilt CLOVERX64.efi then plz attach it here (my test was using GitHub release). Thanks.

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted
24 minutes ago, Badruzeus said:

Interesting! Might be caused by different display sizes? Mine is just 800x600. Using animated theme, try with 768, 600 or even 480px resolution height and let me know (alternatively pressing 'F9' on Clover GUI).

 

Or if you have more recent prebuilt CLOVERX64.efi then plz attach it here (my test was using GitHub release). Thanks.

here you go

 

 

r5114 (d3da5e1a2).zip

  • Like 1
Link to comment
Share on other sites
Pene
Pene
Posted
Posted (edited)
17 hours ago, Badruzeus said:

Anyway, with r5114 I get 'system halted' error immediately when a theme which contains 'anime' is in use || debug.log below is using 'Gothic' (and to make sure I've tried several animated themes as well including; BGM, Clovernity, DarkBoot*, Neon, Shield, etc. with similar result). Thanks.

 

debug.log_r5114_AOH.zip

I again could not reproduce it, but I think I see why that crash could happen, so hope I fixed it: CLOVERX64.zip

Edited by Pene
Updated binary to 1ec5726
  • Like 1
  • Thanks 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
1 hour ago, Alpha22 said:

Clover_r5108

 

 

 

from the version of Clover_5109 to 5114 I find the double writing of the Clover version in the lower left

 

Clover_r5114

 

 

Did you see my screenshot with version 5114?

Link to comment
Share on other sites
Pene
Pene
Posted
Posted (edited)

@Slice


Regarding your commit "detect unknown linux versions":

This has the effect for some distros, of no longer loading custom linux icons that were defined in LinuxEntryData, for example MX linux will no longer have "mx,linux", so only "linux" icon will be loaded

 

If I look at LinuxEntryData, I see some had "special" icon naming:

\EFI\LinuxMint\ -> mint

\EFI\arch_grub\ -> arch

\EFI\opensuse\ -> suse

\EFI\ORACLE\ -> solaris

\EFI\elementary\ -> eos

\EFI\pclinuxos -> pclinux

\EFI\MX19 -> mx

 

Edited by Pene
  • Confused 1
Link to comment
Share on other sites
Pene
Pene
Posted
Posted
2 minutes ago, maclinuxG4 said:

add at your list manjaro, i have a partition on my hack thanks (EFI/manjaro)

manjaro has standard naming (\EFI\Manjaro\grubx64.efi and "manjaro" as icon), so nothing to add.

 

 

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
44 minutes ago, Pene said:

@Slice


Regarding your commit "detect unknown linux versions":

This has the effect for some distros, of no longer loading custom linux icons that were defined in LinuxEntryData, for example MX linux will no longer have "mx,linux", so only "linux" icon will be loaded

 

If I look at LinuxEntryData, I see some had "special" icon naming:

\EFI\LinuxMint\ -> mint

\EFI\arch_grub\ -> arch

\EFI\opensuse\ -> suse

\EFI\ORACLE\ -> solaris

\EFI\elementary\ -> eos

\EFI\pclinuxos -> pclinux

\EFI\MX19 -> mx

 

We can create an array for this substitutions in procedure 

const XImage& XTheme::LoadOSIcon(const XString& Full)

  • Like 1
Link to comment
Share on other sites
Pene
Pene
Posted
Posted (edited)
2 hours ago, Slice said:

Or before it called, before line

XString IconXS = OSName + ",linux"_XS;

make a substitution from OSName to "special" icon names.

Yes, this sounds good.

Speaking of icons, I also see a report on GitHub that undetected OS no longer has icon (I think that what's he trying to say, that for entries that are not windows/linux/Mac, no icon gets loaded).

 

And indeed, that is also true, we are setting in loader.cpp: 

    case OSTYPE_OTHER:
    case OSTYPE_EFI:
      OSIconName = L"clover";
      ShortcutLetter = 'E';
      Entry->LoaderType = OSTYPE_OTHER;
      break;
    default:
      OSIconName = L"unknown";
      Entry->LoaderType = OSTYPE_OTHER;
      break;

So before there was XTheme, for OSTYPE_OTHER the icon "os_clover" was loaded (not sure why os_clover for other OS, but that's how it worked).

 

But now, after the change to XTheme, there is nothing to handle loading of os_clover and os_unknown icons.

The only icons that get loaded are the ones specified in IconsNames[] array, and we have no os_clover or os_unknown there. Maybe they should be added? Not sure how you prefer to handle this.

(The only exception to loading icons that are not specified in that array is made by LinuxScan() that specifically loads the icon specified from disk).

Edited by Pene
Link to comment
Share on other sites
Pene
Pene
Posted
Posted (edited)
12 hours ago, Slice said:

os_clover is not good idea for OSTYPE_OTHER but os_unknown can be implemented if any theme contains it.

Yes, I didn't understand why it was used for OSTYPE_OTHER also. Anyway, what was the original purpose of os_clover, is it still relevant?

By the way, I looked in some themes and I see many contain os_unkonwn, so it seems we can use that instead.

 

Edited by Pene
Link to comment
Share on other sites
Pene
Pene
Posted
Posted
On 4/23/2020 at 9:39 AM, Alpha22 said:

screenshot1.png

The only possible explanation I can see for this is that your volume label is also named 5114. Any install scripts by any chance change the volume label?

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
18 hours ago, Alpha22 said:

yes

where is wrong in my case

Check if you have invisible file on EFI partition

.VolumeLabel.txt

And tell us what is the method to install Clover you used.

  • Like 1
Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted (edited)
On 6/24/2019 at 12:34 AM, vector sigma said:

To be clear I've already checked the kernel and the below code seems to at least patch all occurrences as it is programmed for: 


BOOLEAN KernelIvyBridgeXCPM(VOID *kernelData, LOADER_ENTRY *Entry, BOOLEAN use_xcpm_idle)
{
  UINT8       *kern = (UINT8*)kernelData;
  CHAR8       *comment;
  UINT32      i;
  UINT32      patchLocation;
  UINT64      os_version = AsciiOSVersionToUint64(Entry->OSVersion);

  // check whether Ivy Bridge
  if (gCPUStructure.Model != CPU_MODEL_IVY_BRIDGE) {
    DBG("Unsupported platform.\nRequires Ivy Bridge, aborted\n");
    DBG("KernelIvyBridgeXCPM() <===FALSE\n");
    return FALSE;
  }

  // check OS version suit for patches
  // PMheart: attempt to add 10.14 compatibility
  if (os_version < AsciiOSVersionToUint64("10.8.5") || os_version >= AsciiOSVersionToUint64("10.15")) {
    DBG("Unsupported macOS.\nIvy Bridge XCPM requires macOS 10.8.5 - 10.13.x, aborted\n");
    DBG("KernelIvyBridgeXCPM() <===FALSE\n");
    return FALSE;
  } else if (os_version >= AsciiOSVersionToUint64("10.8.5") && os_version < AsciiOSVersionToUint64("10.12")) {
    // 10.8.5 - 10.11.x no need the following kernel patches on Ivy Bridge - we just use -xcpm boot-args
    DBG("KernelIvyBridgeXCPM() <===\n");
    return TRUE;
  }

  DBG("Searching _xcpm_pkg_scope_msr ...\n");
  if (os_version >= AsciiOSVersionToUint64("10.12")) {
    // 10.12+
    patchLocation = 0; // clean out the value just in case
    for (i = 0; i < 0x1000000; i++) {
      if (kern[i+0] == 0xBE && kern[i+1] == 0x07 && kern[i+2] == 0x00 && kern[i+3] == 0x00 &&
          kern[i+4] == 0x00 && kern[i+5] == 0x31 && kern[i+6] == 0xD2 && kern[i+7] == 0xE8) {
        patchLocation = i+7;
        DBG("Found _xcpm_pkg_scope_msr\n");
        break;
      }
    }

    if (patchLocation) {
      for (i = 0; i < 5; i++) {
        kern[patchLocation+i] = 0x90;
      }
      DBG("Applied _xcpm_pkg_scope_msr patch\n");
    } else {
      DBG("_xcpm_pkg_scope_msr not found, patch aborted\n");
      DBG("KernelIvyBridgeXCPM() <===FALSE\n");
      return FALSE;
    }
  }

  comment = "_xcpm_bootstrap";
  if (os_version <= AsciiOSVersionToUint64("10.12.5")) {
    // 10.12 - 10.12.5
    STATIC UINT8 find[] = { 0x83, 0xC3, 0xC4, 0x83, 0xFB, 0x22 };
    STATIC UINT8 repl[] = { 0x83, 0xC3, 0xC6, 0x83, 0xFB, 0x22 };
    applyKernPatch(kern, find, sizeof(find), repl, comment);
  } else if (os_version < AsciiOSVersionToUint64("10.13")) {
    // 10.12.6
    STATIC UINT8 find[] = { 0x8D, 0x43, 0xC4, 0x83, 0xF8, 0x22 };
    STATIC UINT8 repl[] = { 0x8D, 0x43, 0xC6, 0x83, 0xF8, 0x22 };
    applyKernPatch(kern, find, sizeof(find), repl, comment);
    // PMheart: attempt to add 10.14 compatibility
  } else if (os_version < AsciiOSVersionToUint64("10.15")) {
    // 10.13/10.14
    STATIC UINT8 find[] = { 0x89, 0xD8, 0x04, 0xC4, 0x3C, 0x22 };
    STATIC UINT8 repl[] = { 0x89, 0xD8, 0x04, 0xC6, 0x3C, 0x22 };
    applyKernPatch(kern, find, sizeof(find), repl, comment);
    // PMheart: attempt to add 10.15 compatibility
  } else if (os_version < AsciiOSVersionToUint64("10.16")) {
    STATIC UINT8 find[] = { 0x8D, 0x43, 0xC4, 0x3C, 0x22 };
    STATIC UINT8 repl[] = { 0x8D, 0x43, 0xC6, 0x3C, 0x22 };
    applyKernPatch(kern, find, sizeof(find), repl, comment);
  }

uless my cpu isn't involved, but should since is it a Core i5 3210M if I correctly understood the code.

 

Can anyone confirm that this (actually the latest code) works with 10.15.4 ?

I set KernelXCPM=Yes and for 10.14.6, XCPM mode is enabled.

If I now boot 10.15.4, with the same config.plist file, XCPM mode is not enabled.

 

Is this patch still valid: 

.
.
.
else if (os_version < AsciiOSVersionToUint64("10.16")) {
    STATIC UINT8 find[] = { 0x8D, 0x43, 0xC4, 0x3C, 0x22 };
    STATIC UINT8 repl[] = { 0x8D, 0x43, 0xC6, 0x3C, 0x22 };
    applyKernPatch(kern, find, sizeof(find), repl, comment);
.
.
.

 

Edited by MacNB
Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted
7 minutes ago, vector sigma said:

Sorry I'm still with 10.15.3

 

10.15.3 is > 10.15 which means it is < 10.16 which means that patch must be getting applied for you.

If you run this check from terminal:  

sysctl -n machdep.xcpm.mode

does it return 1 or 0 ?

thx

Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
8 minutes ago, MacNB said:

 

10.15.3 is > 10.15 which means it is < 10.16 which means that patch must be getting applied for you.

If you run this check from terminal:  


sysctl -n machdep.xcpm.mode

does it return 1 or 0 ?

thx

Of course that is working, but you ask something else

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...