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

Reply: Mark Millard : "Re: A FreeBSD port to build a RPI_EFI.fd matching https://github.com/pftf/RPi4 versioning?"
In reply to: Mark Millard : "A FreeBSD port to build a RPI_EFI.fd matching https://github.com/pftf/RPi4 versioning?"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 17 Apr 2022 17:28:42 UTC
On 2022-Apr-17, at 04:41, Mark Millard <marklmi@yahoo.com> wrote:

> 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.
> 

I should have noted that I've not done anything (yet?)
about getting a copy of the RPi* firmware that
https://github.com/pftf/RPi4 bundles in a release
(v1.33 here). As stands, it is only the EDK2's RPI_EFI.fd
that is provided.

Part of what https://github.com/pftf/RPi4 provides is that
they develop a working combination and update when
problems are discovered, such a reverting to older RPi*
firmware.

===
Mark Millard
marklmi at yahoo.com