Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3205 posts in this topic

Recommended Posts

Slice
Slice
Posted
Posted
6 hours ago, vector sigma said:

So I guess the only intresting part for the app is the SoundVolume?

SoundDevice and SoundIndex can be interesting for review but we can't know what to change. It is Clover affair  to help user to change and remember these vars.

vector sigma
vector sigma
Posted
Posted (edited)
42 minutes ago, Slice said:

SoundDevice and SoundIndex can be interesting for review but we can't know what to change. It is Clover affair  to help user to change and remember these vars.

I can, I guess, count the audio devices and have them in the interface through the IO, but I'm not sure will be listed in the same order.

Or I can parse the boot log... may be taking the number from this: 

found 2 handles with audio

or (idea), if you can log them  with a known prefix: 

Audio device: index - Name

then I can easily make an array of devices ... and so make appear them in the interface, the same as clover show in the GUI. What do you think?

Edited by vector sigma
  • Like 1
  • 1 month later...
Slice
Slice
Posted
Posted

I tested new BaseTools from recent EDK2 with our additions.

XCODE5 and XCODE8 toolsets work but GCC53 not.

It looks like new feature  $(DEPS_FLAGS) is in contradiction with LTO which is not used by EDK2 vs our toolsets.

Look please if there is something I missed.

BaseTools-new.7z

Slice
Slice
Posted
Posted

Windows compilation is still no go even with new BaseTools 

cl : Command line error D8036 : '/FRd:\projects\clover\Build\Clover\RELEASE_VS2010x86\X64\MdePkg\Library\BasePrintLib\BasePrintLib\OUTPUT\PrintLib.SBR' not allowed with multiple source files
DriverEntryPoint.c
cl : Command line error D8036 : '/FRd:\projects\clover\Build\Clover\RELEASE_VS2010x86\X64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\DevicePathFromText.SBR' not allowed with multiple source files
cl : Command line error D8036 : '/FRd:\projects\clover\Build\Clover\RELEASE_VS2010x86\X64\MdePkg\Library\UefiLib\UefiLib\OUTPUT\Acpi.SBR' not allowed with multiple source files
UefiBootServicesTableLib.c
UefiRuntimeServicesTableLib.c
MemoryAllocationLib.c
BaseReportStatusCodeLib.c

Strange but there are no our codes or our build rules.

apianti
apianti
Posted
Posted

Oh, I am using CLANGPDB on every platform because it appears to provide the same output on every platform. The problem is it takes very significant effort to fix the current repository to build currently in windows because of the diversion from edk2. I have also got it working using VS2019. Although, I just tried to update to the latest and redo what I did and now I can't get it to work but I only spent about twenty minutes, I don't have anymore time to test. It is just broken dependencies from switching back to edk2.

  • 1 month later...
Pene
Pene
Posted
Posted
On 10/24/2019 at 1:05 AM, Pene said:

GCC9 issues on Catalina were a mix of:

- GMP having to be compiled (for now) with no-stack-check flag in order not to produce segmentation fault, until the cause of this issue is fully tracked.

- the Availability.h issue (a patch for that is available now from homebrew)

- need to set CPATH to Xcode's path, as /usr/include is no longer available on Catalina.

 

I committed corresponding workarounds to build_gcc9.sh, so now it should be able to produce a working gcc9 toolchain with Catalina. Make sure to erase old attempts before it can work, as GMP needs to be recompiled. 

These patches are no longer needed with latest GCC9.3 & GMP6.2.0 (confirmed with latest Xcode 11.3.1), so I updated the toolchain.

Setting CPATH to Xcode's path is the only one still needed from the issues that were present previously.

 

  • Thanks 1
  • 3 months later...
vector sigma
vector sigma
Posted
Posted (edited)
3 hours ago, Slice said:

@vector sigma

Why? 


Removing UEFI/OpenRuntime.efi because OcQuirks.efi is installed

 

maybe i'm wrong, but I can't see how this should happen: 

  cd "$EFI_ROOT_DIR/EFI/CLOVER/drivers/$driver_dir"
  if [[ "$driver" == OcQuirks.efi ]]; then
    for driver in *.efi
    do
      low=$(echo "${driver}" | tr '[:upper:]' '[:lower:]')
      if [[ "$driver" != $driver_name ]] && \
      [[ "$low" == *aptiofix* || "$low" == *memfix*  || "$low" == *memoryfix* ]]; then
        echo "Removing ${driver_dir}/${driver} because $driver_name is installed" >> "$install_log"
        rm -f "${driver}"
      fi
    done
  else
    for driver in *.efi
    do
      low=$(echo "${driver}" | tr '[:upper:]' '[:lower:]')
      if [[ "$driver" != $driver_name ]] && \
      [[ "$low" == *aptiofix* || "$low" == *memfix*  || "$low" == *memoryfix* \
      || "$low" == *ocquirks* || "$low" == *openruntime* ]]; then
        echo "Removing ${driver_dir}/${driver} because $driver_name is installed" >> "$install_log"
        rm -f "${driver}"
      fi
    done
  fi

..or I can't see a mistake. 

EDIT

going to try..

 

EDIT II

Real sorry guys, found my own mistake: 

if [[ "$driver" == OcQuirks.efi ]]; then

should have been: 

if [[ "$driver_name" == OcQuirks.efi ]]; then

fixed. @Slice the release of the pkg at github is wrong then...

 

EDIT

uploaded a fixed package at github. 

Edited by vector sigma
  • Like 2
Slice
Slice
Posted
Posted

Write here as remind for myself.

Since C++ I have only daylight theme (?). 

2:964  0:000  === [ InitXTheme ] ==============================
2:964  0:000  use Daylight theme

While Clover-5098 makes me Night.

  • Like 2
  • 2 weeks later...
Slice
Slice
Posted
Posted

I think the problem with BigSur installation is in procedure InjectKexts(...) which are developed years ago.

It worked when prelinkedkernel is used . But probably it is not working when we install bigsur with KernelCollection file. Where to get such information?

OpenCore is successful because it used other method to inject kexts.

  • Like 2
  • Sad 1
vector sigma
vector sigma
Posted
Posted

Looks like that overriding gBS->LoadImage with your own protocol, like you do in OsxFatBinaryDrv, it is a good moment for patching the prelinked kernel and injecting kexts w/o patching the booterExtention() function. I mean (not an easy task ok), to transplanting kexts directly in the mach-o binary and bye bye SIP and other patches. All just before the kernel goes to the memory map. 

make any sense? 

  • Like 1
mhaeuser
mhaeuser
Posted
Posted

@vector sigma This is exactly how OC works, but LoadImage() does not work of course because it's for UEFI images loaded into UEFI environment, you will have to hook SimpleFS. You can refer to OcVirtualFsLib and OcAppleKernelLib. You do not need to re-compress the PK so long as it does not report to be compressed after modification.

  • Like 1
vector sigma
vector sigma
Posted
Posted (edited)
21 minutes ago, Download-Fritz said:

@vector sigma This is exactly how OC works, but LoadImage() does not work of course because it's for UEFI images loaded into UEFI environment, you will have to hook SimpleFS. You can refer to OcVirtualFsLib and OcAppleKernelLib. You do not need to re-compress the PK so long as it does not report to be compressed after modification.

I'll take a look but I'm very poor with EDK programming.. About the compression is as I thought then, as boot.efi should check for the header and doing accordingly. 

Edited by vector sigma
Slice
Slice
Posted
Posted

Clover has no problem with prelinkedkernel. As we know BigSur worked with Clover if the system preinstalled somehow.

The problem is with BootKernelExtensions.kc used during installation. So we have to find a way to inject our kexts into it assuming it is already unpacked in memory.

And at first step inject one kext namely FakeSMC will be enough.

vector sigma
vector sigma
Posted
Posted (edited)

Hi @Slice, I made my own parser and if I'm not mistaken the BootKernelExtensions.kc has some differences from the old prelinkedkernel:

 

  1. __PRELINK_INFO is a true plist with header and footer unlike the old one.

  2. __PRELINK_TEXT is empty (struct section_64->size == 0) . kexts are elsewere.

  3. not marked as executable (filetype == 12).

Can you confirm this? 

Edited by vector sigma
  • Like 1
mhaeuser
mhaeuser
Posted
Posted
17 minutes ago, vector sigma said:

__PRELINK_INFO is a true plist with header and footer unlike the old one.

Yes

17 minutes ago, vector sigma said:

__PRELINK_TEXT is empty (struct section_64->size == 0) . kexts are elsewere.

Kexts are in own section pairs to allow W^X on ARM

18 minutes ago, vector sigma said:

not marked as executable (filetype == 12).

KC type

  • Like 1
Slice
Slice
Posted
Posted

KC consists of several mach bodies different by types. Type 2 - executable for example prelinkedkernel. Type 12 - KC, and type 11 == MH_KEXT_BUNDLE somehow related to kext. Each body begins with header followed by a chain of load commands. LC_SEGMENT_64 represents a some memory segment. For example _HIB is a starting point of kernel. Command LC_SYMTAB describes a symbols table which I used to find a symbol inside the kernel. This way I made symbolic patcher instead of find bytes patterns.

BigSur introduced new mach body type 12 and new SEGMENTs. I found __TEXT_EXEC points to kernel body after KC.  Segments __REGIONnnn with even numbers points to kext descriptions. The kext defined by UUID.

For older method with prelinkedkernel we found PrelinkedInfo with is an array of plists "-PrelinkedInfoDictionary" where is item contains _PrelinkExecutableSourceAddr which is the kext binary.

To inject our kext here we have to reallocate this array and add here our kext plist with real addresses.

All this description has a lack of address shifts. For example if kext binary has virtual address 0xFFFFFF8001180000 then we will find in in real memory at address 01180000. Why?

But I have mush more complex case with symbol tables which I found by binary search and the resulting address is not same as it should be.

 

 

 

  • Confused 1
 Share
Go to topic listing
×
×
  • Create New...