Date: Sun, 17 Apr 2022 04:41:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: Free BSD <freebsd-arm@freebsd.org> Subject: A FreeBSD port to build a RPI_EFI.fd matching https://github.com/pftf/RPi4 versioning? Message-ID: <F8E6E174-34AC-4870-876D-F6ED7C6D6928@yahoo.com> References: <F8E6E174-34AC-4870-876D-F6ED7C6D6928.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D edk2-pftf-rpi4 DISTVERSIONPREFIX=3D v DISTVERSION=3D 1.33 CATEGORIES=3D sysutils . . . COMMENT=3D 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=3D 958fc02b15 NONOSI_TAG=3D 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=3D OpenSSL_1_1_1j SOFTFLOAT_TAG=3D b64af41 ONIGURUMA_TAG=3D v6.9.4_mark1 BROTLI_TAG=3D 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=3D 11:build # Note: # I needed to use a -Wl,-rpath=3D/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=3D/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+=3D -Wl,-rpath=3D${LOCALBASE}/lib/gcc11 . . . # Emulate source edk2/edksetup.sh MAKE_ENV+=3D WORKSPACE=3D${WRKDIR} \ = PACKAGES_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}:${WRKDIR}/edk2-platforms-${PL= ATFORM_TAG}:${WRKDIR}/edk2-non-osi-${NONOSI_TAG} \ CONF_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/Conf \ EDK_TOOLS_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools = \ = PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools/BinWrappers/PosixLike:${PATH= } \ PYTHON_COMMAND=3Dpython3 \ PYTHONHASHSEED=3D1 \ EXTRA_LDFLAGS=3D${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=3D = ${FILESDIR}/0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patc= h:-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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8E6E174-34AC-4870-876D-F6ED7C6D6928>