Looks like U-Boot 2022.04 may be fairly useful

I did the following primarily as a learning exploration
but I figured I'd report some on it.

I have the following devices booting based on U-Boot
2022.04 built via poudriere-devel. I used testport and
bulk and used portlint. I did not update RPi* firmware:
this was just substituting the new U-Boot version into a
working environment to see if it still works.


Xunlong Orange Pi Plus 2E:

U-Boot SPL 2022.04 (Apr 23 2022 - 03:19:10 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1

U-Boot 2022.04 (Apr 23 2022 - 03:19:10 +0000) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E


Pine64 Rock64:

U-Boot TPL 2022.04 (Apr 23 2022 - 03:14:35)
LPDDR3, 800MHz
BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2022.04 (Apr 23 2022 - 03:14:35 +0000)
Trying to boot from MMC1
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Trying to boot from MMC2
NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 05:34:22, Dec  8 2021
NOTICE:  BL31:Rockchip release version: v1.2


U-Boot 2022.04 (Apr 23 2022 - 03:15:10 +0000)

Model: Pine64 Rock64


RPI 4 Model B (0xd03114):

U-Boot 2022.04 (Apr 23 2022 - 03:14:35 +0000)

DRAM:  7.9 GiB
RPI 4 Model B (0xd03114)

Most of that is based on various FreeBSD main [so: 14]
vintages, some from late March and others going back into
even late last year. (I've not synchronized the systems
in a long time.) But RPi4B was also booted via 13.1-RC4
with the u-boot updated as well.

A simplified sequencing of the exploration is . . .

I started by updating:

 	modified:   devel/aarch64-none-elf-gcc/Makefile
	modified:   devel/aarch64-none-elf-gcc/distinfo
	deleted:    devel/aarch64-none-elf-gcc/files/patch-libcpp_lex.c
	modified:   devel/aarch64-none-elf-gcc/pkg-plist
	modified:   devel/arm-none-eabi-gcc/Makefile
	modified:   devel/arm-none-eabi-gcc/distinfo
	modified:   devel/arm-none-eabi-gcc/pkg-plist

to be based on gcc 11.3.0 (the first non -devel gcc
port to have a bug fix for how it interacts with modern
binutils). Without the fix U-Boot 2022.04 would not
build.

I then updated:

	modified:   sysutils/u-boot-tools/Makefile
	modified:   sysutils/u-boot-tools/distinfo

to be based on 2022.04 . (Turns out that this does
not run into the toolchain bug that u-boot builds
run into. So gcc 11.3.0 is more optional here.
Originally I used 11.2.0 --which still has the
toolchain bug, as I discovered later.)

I then updated:

	modified:   sysutils/u-boot-master/Makefile
	modified:   sysutils/u-boot-master/distinfo
	deleted:    sysutils/u-boot-master/files/patch-common__bootm.c

as well. ( Actually, that last is now in a
sysutils/u-boot-master/files/patch-boot_bootm.c .)
This did run into the toolchain bug and, for now,
11.3.0 is the fix, at least until gcc9 or gcc10
gets an update that has the fix. The fix was
produced after gcc8 went out of support so gcc8
will not be updated by the gcc folks to work
correctly with modern binutils for the issue in
the bug.

For:

	modified:   sysutils/u-boot-rpi-0-w/Makefile
	modified:   sysutils/u-boot-rpi-arm64/Makefile
	modified:   sysutils/u-boot-rpi/Makefile
	modified:   sysutils/u-boot-rpi2/Makefile
	modified:   sysutils/u-boot-rpi3/Makefile
	modified:   sysutils/u-boot-rpi4/Makefile

I removed U_BOOT_SLAVE_PORTREVISION_2021.07 and the
1547145/raw patchfile item that does not apply. (I
have other RPi* patches that I've had for a long time.)
I do not actually have access to a rpi-0-w but it fit
the editing pattern. For rpi-0-w, the build is untested.

The other u-boot slave ports ( u-boot-orangepi-plus-2e ,
u-boot-rock64 , u-boot-pine64 , u-boot-sinovoip-bpi-m3 )
did not need changes to build. I've not had access
to a working pine64 or u-boot-sinovoip-bpi-m3 in years
at this point. So: those builds are untested.

Exploring adjusting things for portlint and how it handled
various things means that I moved around more text than
strictly necessary. I noticed an oddity here or there
that I took a guess about the appropriate fix, not that
I actually know.

As for pkg-plist files, I mostly assumed that what was put
in the staging area was correct and listed it. I do not have
independent knowledge of what should be there. There are
both files that no longer exist and files that are added.
testport reported a type of example of something that I
removed from what I originally generated.

If I end up with access to a 8 GiByte RPi4B Rev 1.5 with
the C0T stepping (no 3 Gibyte limitation, for example),
I'll probably use these builds to explore booting it.
That might have to involve RPi* firmware updates. My
understanding is that there were dtb changes at some
point that FreeBSD is not set up to handle --even for
RPi4B's that now work with the firmware from the port.
But I could be wrong about such.

===
Mark Millard
marklmi at yahoo.com