Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 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.

Link to comment
Share on other sites
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
Link to comment
Share on other sites
  • 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

Link to comment
Share on other sites
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.

Link to comment
Share on other sites
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.

Link to comment
Share on other sites
  • 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
Link to comment
Share on other sites
  • 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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
  • 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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Disassembling BigSur Beta4 kernel I found that old Clover's method to inject kexts should work. 

There are just new offsets and conditions preventing success.

  • Like 6
Link to comment
Share on other sites
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
Link to comment
Share on other sites
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
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...