Re: A FreeBSD port to build a RPI_EFI.fd matching https://github.com/pftf/RPi4 versioning?
Date: Sun, 17 Apr 2022 22:14:55 UTC
On 2022-Apr-17, at 10:28, Mark Millard <marklmi@yahoo.com> wrote: > 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 I've noticed that another difference vs. sysutils/edk2@rpi4 is that the equivalent of PLAT_ARGS is different for pftf/RPi4 than used in sysutils/edk2@rpi4 : sysutils/edk2@rpi4 : -D X64EMU_ENABLE=FALSE -D CAPSULE_ENABLE=FALSE pftf/RPi4 : -D SECURE_BOOT_ENABLE=TRUE -D INCLUDE_TFTP_COMMAND=TRUE \ -D NETWORK_ISCSI_ENABLE=TRUE -D SMC_PCI_SUPPORT=1 Nothing I did dealt with secure boot at all and I'm not so sure that a port should. (Example: secure boot's default keys.) So I might be more inclined to include something like: -D INCLUDE_TFTP_COMMAND=TRUE -D NETWORK_ISCSI_ENABLE=TRUE -D SMC_PCI_SUPPORT=1 but I'm unsure about the -D X64EMU_ENABLE=FALSE -D CAPSULE_ENABLE=FALSE . (Note: NETWORK_ISCSI_ENABLE is not something that pftf/RPi3 has.) >> 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. > Hmm. Looking at the details for that last it is not what I expected for how it is implemented. In essence, the RPi* firmware needs to be extracted from an already built pftf/RPi4 release in order to be reproducible . . . The pftf/RPi4 builds themselves normally just grab from https://github.com/raspberrypi/firmware/ 's master branch. So, if rerun after master has changed, would produce a different result. They do patch in a more specific reference to specific files when they release in order to revert one or more files. But the other RPi* files are left as grabbed from master. In such cases they are testing and releasing RPi* firmware materials from a mix of time frames. (Also not what I would have guessed.) Still, they do make such adjustments when problem occur and folks help them test. I know how to look up what version a start*.elf is from --and the fixup*.dat needs to be from the same version. But I do not know a reasonable way to identify how to find the .dtb or .dtbo files to grab from github in order to have a match to what is in a pftf/RPi4 release. === Mark Millard marklmi at yahoo.com