Compiling EDK2 UEFI on FreeBSD

Phishfry

Phishfry

I am trying to compile an "Out Of Tree" EDK2 UEFI Github from JMcNeil on FreeBSD 13.4-RELEASE.

We have in ports tree /sysutils/edk2 with flavors. I use rpi3 for testing.

When testing I mean I capture the output from it compiling and save to a file to massage.

When I say massage I mean convert something I can compile the quart64_uefi repository with.
Its instructions are barebone and says run build.sh and that fails.
That is assuming you already have the toolchain installed and working. Also shortcuts to GCC5 and all kinds of prep.

If this were u-boot I would be creating a slave port for my build but edk2 port uses flavors and I dont want to try and add my own flavor.

So please help me line by line as I try and understand what happens at compile time.

My first example is this path-adapted command:
cd /quartz64_uefi/edk2/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli && tar cf - * | tar xf - -C ../../../../BaseTools/Source/C/BrotliCompress/brotli

So It tars a directories files and pipes it to another directory? Is that what I am seeing? What is brotli ?
 
Then it moves build files to the Conf directory.

cp /quartz64_uefi/edk2/BaseTools/Conf/build_rule.template /quartz64_uefi/edk2/Conf/build_rule.txt

cp /quartz64_uefi/edk2/BaseTools/Conf/tools_def.template /quartz64_uefi/edk2/Conf/tools_def.txt

cp /quartz64_uefi/edk2/BaseTools/Conf/target.template /quartz64_uefi/edk2/Conf/target.txt

Then moves to build edk2 directory.
cd /quartz64_uefi/edk2
 
The next part is the actual compile flags. There are a bunch. I adapted to my target paths.
The base edk2 instructions mention setup toolchain with make -C /edk2/BaseTools but that didn't work.
With the rpi3 edk2 port I see I wanted gmake instead.

So this part is untested and I hope to get this compiling on command line.

/usr/bin/env WORKSPACE=/quartz64_uefi/edk2
PACKAGES_PATH=/quartz64_uefi/edk2:/quartz64_uefi/edk2-platforms:/quartz64_uefi/edk2-non-osi
CONF_PATH=/quartz64_uefi/edk2/Conf
EDK_TOOLS_PATH=/quartz64_uefi/edk2/BaseTools
PATH=/quartz64_uefi/edk2/BaseTools/BinWrappers/PosixLike:/quartz64_uefi/edk2/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
PYTHON_COMMAND=python3
PYTHONHASHSEED=1
EXTRA_LDFLAGS=-Wl,-rpath=/usr/local/lib/gcc13
GCC5_AARCH64_PREFIX=aarch64-none-elf-
XDG_DATA_HOME=/quartz64_uefi
XDG_CONFIG_HOME=/quartz64_uefi
DG_CACHE_HOME=/quartz64_uefi/.cache
HOME=/usr/ports/sysutils/edk2/work-rpi4
PKG_CONFIG_LIBDIR=/usr/ports/sysutils/edk2/work-rpi4/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig
MK_DEBUG_FILES=no
MK_KERNEL_SYMBOLS=no
SHELL=/bin/sh
NO_LINT=YES
ADDR2LINE="/usr/local/bin/addr2line"
AR="/usr/local/bin/ar"
AS="/usr/local/bin/as"
CPPFILT="/usr/local/bin/c++filt"
GPROF="/usr/local/bin/gprof"
LD="/usr/local/bin/ld"
NM="/usr/local/bin/nm"
OBJCOPY="/usr/local/bin/objcopy"
OBJDUMP="/usr/local/bin/objdump"
RANLIB="/usr/local/bin/ranlib"
READELF="/usr/local/bin/readelf"
SIZE="/usr/local/bin/size"
STRINGS="/usr/local/bin/strings"
PREFIX=/usr/local
LOCALBASE=/usr/local
CC="gcc13"
CFLAGS="-O2 -pipe -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -fno-strict-aliasing "
CPP="cpp13"
CPPFLAGS=""
LDFLAGS=" -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -L/usr/local/lib/gcc13 "
LIBS=""
CXX="g++13"
CXXFLAGS="-O2 -pipe -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -Wl,-rpath=/usr/local/lib/gcc13"
BSD_INSTALL_PROGRAM="install -s -m 555"
BSD_INSTALL_LIB="install -s -m 0644"
BSD_INSTALL_SCRIPT="install -m 555"
BSD_INSTALL_DATA="install -m 0644"
BSD_INSTALL_MAN="install -m 444"

gmake -C edk2/BaseTools -j4)
gmake[1]: Entering directory '/usr/ports/sysutils/edk2/work-rpi4/edk2-edk2-stable202308/BaseTools'

gmake -C Source/C

gmake -C Source/Python

mkdir -p .
mkdir ./libs
mkdir ./bin
gmake -C VfrCompile VfrLexer.h
gmake -C Common

BIN_DIR='.' gmake -C Pccts/dlg
BIN_DIR='.' gmake -C Pccts/antlr
 
The ports Makefile helped me with the first question:

Code: 
# We can't have two submodule with the same origin in GH_TUPLE
post-extract:
    (cd ${WRKDIR}/edk2-${GH_TAGNAME}/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli && tar cf - * | tar xf - -C ../../../../BaseTools/Source/C/BrotliCompress/brotli)
 
I went another route and tried to build BaseTools from command prompt as per this:
github.com

Common instructions

Tianocore website. Contribute to tianocore/tianocore.github.io development by creating an account on GitHub.
github.com github.com

gmake -C ./BaseTools "PYTHON_COMMAND=python3" "PYTHONHASHSEED=1"

Next up .edksetup and figuring out its needed option flags.
 
Hello Phishfry , did you have any progress meanwhile?

I tried to build gnuefi based program, gnuefi latest release builds normally using gmake, but the building of host program doesn't go smoothly. The linker will warn about not having fPIC on the compiled unit (it shouldn't be used), and will give a relocation error about .dynamic section unless norelro keyword is supplied. With those added, compile/link are done but then object conversion from .so to EFI binary via objcopy fails because there are no source sections found in the binary.

With EDK2 I hit the wall with internal build system (build.py) failing to execute "tbuild" target via gmake. Using clang, because it looks like internally EDK2 build system only works with very old gcc (version 5)?

I also tried building EDK2 port maybe to 'steal' the working tree from the port, but I'm on quaterly and it looks like it wants to update basically everything from pkg, glibc, iconv, on...as I have to pkgbasify the system and update to 15 this is possibly a problem and I'll first have to do the update.

In any case, the 'problem' here is development environment for UEFI on FreeBSD. If anyone has any hints on how to achieve it, it is very appreciated :)
 
Yeah it's clear that Linux is their primary platform but we should be also able to use UEFI developer toolkits.
Last resort is to do something in a jail or using Linuxlator but why go there if FreeBSD should be supported?
 
While I never did get this to compile I feel the supported platforms in the mainline branch would work. Look at the flavors we support in ports tree. They build fine.

RK356x UEFI I tried to compile was a forked version of upstream and it fell out of date.

Building this reminds me alot of learning to compile u-boot manually. Building the toolchain can be just as tedious as building the source.
 
You must log in or register to reply here.
Back
Top