Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Apr 2022 15:14:55 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Free BSD <freebsd-arm@freebsd.org>
Subject:   Re: A FreeBSD port to build a RPI_EFI.fd matching https://github.com/pftf/RPi4 versioning?
Message-ID:  <AF5DB108-FD09-45A0-9BFB-91EAFAD47E94@yahoo.com>
In-Reply-To: <4B03F462-5C34-4B36-9075-586CFE59037C@yahoo.com>
References:  <F8E6E174-34AC-4870-876D-F6ED7C6D6928@yahoo.com> <4B03F462-5C34-4B36-9075-586CFE59037C@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> 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.
>>=20
>> 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.)
>>=20
>> Part of the prompt for this is OpenBSD has taken the route of:
>>=20
>> 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
>>=20
>> (Where the link in that text is to: https://github.com/pftf/RPi4 .)
>>=20
>> 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.
>>=20
>> As for https://github.com/pftf/RPi4 vs. tianocore . . .
>>=20
>> 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.)
>>=20
>> 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).
>>=20
>> The core of it is:
>>=20
>> 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
>>=20
>> # 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
>>=20
>> # 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.
>>=20
>> 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:
>>=20
>> 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}
>>=20
>> I kept the original patch file names. One I could list in
>> EXTRA_PATCHES and the other was used via post-patch:
>>=20
>> # 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

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=3DFALSE -D CAPSULE_ENABLE=3DFALSE

pftf/RPi4          : -D SECURE_BOOT_ENABLE=3DTRUE -D =
INCLUDE_TFTP_COMMAND=3DTRUE \
                      -D NETWORK_ISCSI_ENABLE=3DTRUE -D =
SMC_PCI_SUPPORT=3D1

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=3DTRUE -D NETWORK_ISCSI_ENABLE=3DTRUE -D =
SMC_PCI_SUPPORT=3D1

but I'm unsure about the -D X64EMU_ENABLE=3DFALSE -D =
CAPSULE_ENABLE=3DFALSE .

(Note: NETWORK_ISCSI_ENABLE is not something that pftf/RPi3
has.)

>> pkg-descr and distinfo were updated as well.
>>=20
>> poudriere testport seemed to be happy with things.
>> portlint only complains about the limitation to
>> exactly gcc11 (or whatever is listed there).
>>=20
>> 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.)
>>=20
>> So I got far enough along to ask: does a port for this
>> purpose seem worthwhile?
>>=20
>> I'll note that FreeBSD still has no ACPI drivers
>> supporting the use of the RPi4B's:
>>=20
>> A) built-in microsd card slot
>> B) built-in EtherNet port
>>=20
>> I use USB devices for such when using
>> https://github.com/pftf/RPi4 .
>>=20
>> 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.
>>=20
>=20
> 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.
>=20
> 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.
>=20

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.

=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?AF5DB108-FD09-45A0-9BFB-91EAFAD47E94>