FYI: upcoming 13.2-RELEASE vs. 8 GiByte RPi4B's based on U-Boot 2023.01 recently in use, given UEFI style booting

This is an FYI about 8 GiByte RPI4B coverage by 13.2-RELEASE.
(The existing snapshots and such show the issue now --but I'm
noting the 13.2-RELEASE consequences for as things are.)

When sysutils/u-boot-rpi-arm64 and sysutils/u-boot-rpi4 recently
changed to be based on U-Boot 2023.01, the U-Boot produced no
longer boots 8 GiByte RPi4B's for FreeBSD: U-Boot increased the
number of U-Boot "lmb" regions it uses for RPi4B's for UEFI
booting --without adjusting the bound imposed on the number that
can be in use. The 8 GiByte RPI4B's end up over the limit during
part of the activity and U-Boot aborts the UEFI-boot attempt.

The U-Boot message about this is misleading. The middle line
of:

Found EFI removable media binary efi/boot/bootaa64.efi
** Reading file would overwrite reserved memory **
Failed to load 'efi/boot/bootaa64.efi'

is actually caused by the rejection of adding another lmb
range, having nothing to do with potentially overwriting
reserved memory. (The message is generated far from the
code that did the rejection and no rejection reason is
propogated.)

A FreeBSD bugzilla for this issue is:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269181

I'd not be surprised if U-Boot 2023.04 has things working
by default again. But, until such, either an older U-Boot,
such as 2022.10, or a patched 2023.01 U-Boot, would be
needed for 8 GiByte RPi4B's to end up being directly
bootable by 13.2-RELEASE as-built.

I'm not aware of any other type of FreeBSD aarch64 context
broken via the use of 2023.01 U-Boot.

===
Mark Millard
marklmi at yahoo.com