Jump to content

Zenith432

Developers
  • Content count

    850
  • Joined

  • Last visited

  • Days Won

    15

Zenith432 last won the day on November 18 2017

Zenith432 had the most liked content!

1 Follower

About Zenith432

  • Rank
    InsanelyMac Legend

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Zenith432

    Clover Problems and Solutions

    No. It's just a limited set used by VoodooHDA. The full files are in Xcode.app somewhere. use find to find xmmintrin.h or emmintrin.h.
  2. Zenith432

    Clover Problems and Solutions

    @Slice These are not compiler intrinsics - they're macros or inline functions defined in xmmintrin.h or emmintrin.h. So you need to find these include files in the toolchain. Compiler instrinsics are different between gcc/clang and visual c.
  3. Either version is good 27425 or 27429. I sync from edk2 git, which is ahead of svn by around 16 commits. So I wrote r27429 which is the future svn version of the git commit I synced to. However the sync is only spaces and comments because they cleaned up their code. So you can safely use the patch_for_r27429 with r27425. In a few days 27429 will show up and all will be ok.
  4. Zenith432

    Clover Problems and Solutions

    It's ok. The patch has a history.... EDK2 originally added #if defined(__GNUC__) && defined(__pic__) #pragma GCC visibility push(hidden) #endif in order to serve their GCC5 toolchain that moved to using -fpie/--pie settings instead of the large model. Clover was using Xcode with LTO at the time and this broke the Xcode build, so slice added #if defined(__GNUC__) && defined(__pic__) && !defined(__clang__) to the condition. Later EDK2 moved to using LTO with GCC5 and it broke their build, so they started using a macro USING_LTO and made the condition #if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO) And Clover continued to have the !defined(__clang__) condition, but stopped using LTO with Xcode. Then I found that for Xcode non-LTO, enabling this pragma reduces code size for XCODE8 by about 9K. So I reenabled it for clang. But in clover-genconfig, the pragma needs to be turned off - either completely or after the #include of "Platform.h" because otherwise it makes the macOS functions hidden too (which they shouldn't be because they're in shared libraries). So USING_LTO suppresses the pragma, but if EDK2 decide to eliminate this macro in the future, then visibility should be returned to default in clover-genconfig.c after #include of Platform.h by using either #pragma GCC visibility pop or #pragma GCC visibility push(default)
  5. Zenith432

    Clover Problems and Solutions

    @vector sigma: If you got "no matching pragma" with 4569 then you're using an obsolete patch to MdePkg/Include/X64/ProcessorBind.h in your edk2/udk2018 tree that should be reverted. I will leave it as is and change to the previous workaround that uses -DUSING_LTO, but please update your patches because this preprocessor symbol may be deprecated by EDK2 in the future.
  6. Zenith432

    Clover Problems and Solutions

    Update on XhciDxe: I loaded XhciDxe into native UEFI bios that has builtin xhci driver. It didn't connect to the xhci controller and didn't interfere with existing functionality. So it can be safely put in drivers64UEFI to cover cases of native UEFI bios without a native xhci driver. I tested XhciDxe with boot7 - and USB keyboard immediately stopped working because it's connect thru xhci. I will look over XhciDxe this weekend to find a way to make it not interfere with boot7 such that it can still be put in driver64 to work with boot6.
  7. Zenith432

    Clover Problems and Solutions

    driver64/driver64UEFI are for commonly used setups drivers-Off is for special setups I haven't tried what happens when loading XhciDxe with a native UEFI xhci driver present, but as I remember, there is no protection mechanism for preventing mutliple Dxe from trying to manage the xhci PCI configuration space and registers - so it can cause a crash. I don't see the point of compiling boot7 with '-mc --no-usb', only to have Clover GUI turn around and load XhciDxe. I remember trying years ago with explict load XhciDxe.efi from the shell, and it hung. And remembering some more: it hung on the bios semaphore, after which I added code to break the bios semaphore - and I found that now loads only to make xhci unusable. Because legacy bios loses control, and XhciDxe doesn't have the USB stack to support it.
  8. Zenith432

    Clover Problems and Solutions

    The sensible way to handle XhciDxe is to either embed it into boot6 with -D ENABLE_USB_XHCI or not use it at all. It doesn't belong in drivers64 or drivers64UEFI.
  9. Zenith432

    Clover Problems and Solutions

    They're binaries - there's nothing to compile. The efifs sources only build on linux with gnuefi, but EFI products run on all EFI firmware :) The source in Clover was prepared by AndyV from efifs version 0.9. Current source is 1.3. Also grub is updated. I have not tried to upgrade the source in Clover. It's complicated because of grub.
  10. Zenith432

    Clover Problems and Solutions

    Systems with a xhci controller and UEFI bios have a builtin XHCI driver, so XhciDxe does not belong in drivers64UEFI When using boot7, USB controller drivers should not be used because they either don't work or wrest the controller away from legacy bios that should own it. When using boot6 on a system that only has a XHCI controller (like mine) - XhciDxe needs to be included in boot6 with -D ENABLE_USB_XHCI or it can't boot form USB sticks. So XhciDxe should only be in drivers64 when using boot6, the system has additional older type USB controllers and you never plan to boot Clover from the XHCI controller. It would be nice in ebuild.sh to have a feature like target.txt - where to put personal defaults so they don't have listed again and again. Today I put my personal defaults by adding them to the call to MainBuildScript. Maybe it's useful to take them from an environment variable or a text file. If such a feature is added, there needs to be an option to disable the defaults. Presonally I'd prefer if anything involving downloading is in separate script and not part of ebuild.sh - but I'm not complaining because I just mod ebuild.sh locally. Since you mention the Grub drivers with that -D - I think maybe invert the Grub logic so they need a -D to be included instead of excluded - because I don't think they're used much. Also, there are recent binaries of efifs drivers here instead of building them from outdated source code.
  11. @KGP-iMacPro: If buildmtoc.sh still doesn't work, try the one from r4557.
  12. Zenith432

    Clover Problems and Solutions

    It works for me. mtoc should be built with xcode build tools. It looks from your errors that it's trying to use some old version of gcc 4.9.3 instead. I don't know how this happens. It's something about your PATH and the development tools you have in your PATH.
  13. buildnasm is fixed in 4547. Update it Delete anything with the name nasm in it in ~/src/tools/download. (This is important because there can be a corrupt version there.) rerun buildnasm.sh
  14. Zenith432

    Clover Problems and Solutions

    It's only in LLVM and XCLANG toolchains in Clover tools_def.txt. These toolchains don't exist in tools_def.template anymore - they have CLANG38 which has this. CLANG38 is for use with Linux/ELF LLVM.
×