A FreeBSD port to build a RPI_EFI.fd matching https://github.com/pftf/RPi4 versioning?

One of the things about the sysutils/edk2@rpi4 port flavor is that
it does not build the same tested/in-use releases as the project
that develops the EDK2 support for the RPi4: different commits
are used.

I wonder if it would be worthwhile to have a port that has
the purpose of building what matches some https://github.com/pftf/RPi4
release. So I tried to make a variant of sysutils/edk2 that
does build such. (I'm new to creating a port, even as a
textually minor variation of another one.)

Part of the prompt for this is OpenBSD has taken the route of:

QUOTE of https://www.openbsd.org/arm64.html :
Some Raspberry Pi models that do not work with the included
U-Boot (e.g. Raspberry Pi 400) can instead be booted using
EDK2-based UEFI firmware.
END QUOTE

(Where the link in that text is to: https://github.com/pftf/RPi4 .)

I suspect such may well be true of the RPi4B C0T parts
that do not have the odd size limitations, such as a
3 GiBytes limitation.

As for https://github.com/pftf/RPi4 vs. tianocore . . .

All https://github.com/pftf/RPi4 really does is hold a git
repository that has the https://github.com/tianocore/edk2*
and such needed as submodules --plus having a patch or two.
(I ignore .github/workflows material here.)

I made a variant of sysutils/edk2 that only targets
allowing tracking of what https://github.com/pftf/RPi4
uses from tianocore (and what that in turn uses). For now,
I used the example of matching v1.33 for
https://github.com/pftf/RPi4 (the most recent release).

The core of it is:

PORTNAME=       edk2-pftf-rpi4
DISTVERSIONPREFIX=      v
DISTVERSION=    1.33
CATEGORIES=     sysutils
. . .
COMMENT=        EDK2 Firmware matching a github.com/pftf/RPi4 version

# Tags for tianocore submodules needed. (Note: pftf/RPi3 does not
# match pftf/RPi4 .) Same tags as git submodule status reports for
# manually following the pftf/RPi4 steps.
# Also later true of GH_TAGNAME for edk2.
PLATFORM_TAG=   958fc02b15
NONOSI_TAG=     0320db9

# Tags for non-tianocore submodules used by tianocore for the
# pftf/RPi4 build. BROTLI_TAG has a 2nd use, handled via the
# post-extract make target. (Some submodules are not listed
# because they are unused for pftf/RPi4 .) Note: pftf/RPi3
# does not match pftf/RPI4 .
OPENSSL_TAG=    OpenSSL_1_1_1j
SOFTFLOAT_TAG=  b64af41
ONIGURUMA_TAG=  v6.9.4_mark1
BROTLI_TAG=     v1.0.9-36-gf4153a0
# Note: git submodule status showed v1.0.9-35-gf4153a0 but that
# failed here and when I counted I got 36. So I tried 36 --and it
# worked.

One oddity that I ran into is a known problem for FreeBSD's
/lib/libgcc_s.so.1 vs. aarch64 g++ code generation. I documented
that with:

USE_GCC=        11:build
# Note:
# I needed to use a -Wl,-rpath=/usr/local/lib/gcc* to work around
# FreeBSD's /lib/libgcc_s.so.1 having incomplete/inaccurate
# coverage for aarch64 g++ code generation's use of libgcc_s.so.1 .
# Otherwise tools built, such as VfrCompile, get the following
# when run: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
# required by /usr/local/lib/gcc11/libstdc++.so.6 not found".
# I did not see a supported way to have an automatically
# adjusting -Wl,-rpath=/usr/local/lib/gcc* .
. . .
# Avoid: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
#         required by /usr/local/lib/gcc11/libstdc++.so.6 not found"
# (that is from /lib/libgcc_s.so.1 having incomplete/inaccurate
# coverage for aarch64 g++ code generation's use of libgcc_s.so.1 ):
EXTRA_LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc11
. . .
# Emulate source edk2/edksetup.sh
MAKE_ENV+=      WORKSPACE=${WRKDIR} \
                PACKAGES_PATH=${WRKDIR}/edk2-${GH_TAGNAME}:${WRKDIR}/edk2-platforms-${PLATFORM_TAG}:${WRKDIR}/edk2-non-osi-${NONOSI_TAG} \
                CONF_PATH=${WRKDIR}/edk2-${GH_TAGNAME}/Conf \
                EDK_TOOLS_PATH=${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools \
                PATH=${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools/BinWrappers/PosixLike:${PATH} \
                PYTHON_COMMAND=python3 \
                PYTHONHASHSEED=1 \
                EXTRA_LDFLAGS=${EXTRA_LDFLAGS}

I kept the original patch file names. One I could list in
EXTRA_PATCHES and the other was used via post-patch:

# Using same patch file names as pftf/RPi4 :
EXTRA_PATCHES=  ${FILESDIR}/0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch:-p1
. . .
# Using same patch file names as pftf/RPi4 :
post-patch:
        ${PATCH} -d ${WRKDIR}/edk2-platforms-${PLATFORM_TAG} -p1 -s < ${FILESDIR}/0002-Check-for-Boot-Discovery-Policy-change.patch

pkg-descr and distinfo were updated as well.

poudriere testport seemed to be happy with things.
portlint only complains about the limitation to
exactly gcc11 (or whatever is listed there).

But I've not actually tested the image built (yet?).
Note that, unlike sysutils/edk2@rpi4 , the port
does build to completion. (sysutils/edk2@FLAVOR builds
have been failing for a very long time for versions
of gcc that handle C's newer VLA notation correctly
(Variable Length Array). This is because brotli
violated the C language definition but gcc10 and
before ignored the issue. (Otherwise the other things
likely would have also been broken.) But, even when it
built, I avoided the mix of versions that no development
team was testing for the platform(s) of interest to me.)

So I got far enough along to ask: does a port for this
purpose seem worthwhile?

I'll note that FreeBSD still has no ACPI drivers
supporting the use of the RPi4B's:

A) built-in microsd card slot
B) built-in EtherNet port

I use USB devices for such when using
https://github.com/pftf/RPi4 .

It is possible that I'll get access to a RPi4B with
a C0T part (no odd size limitations) that is also
Rev 1.5 (new PMIC) instead of Rev 1.4 . So I may end
up able to test booting and operation of an example
of such.

===
Mark Millard
marklmi at yahoo.com