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

On Mar 22, 2023, at 10:16, void <void@f-m.fm> wrote:

> On Sat, Feb 18, 2023 at 04:44:09PM -0800, Mark Millard wrote:
>> 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.)
> 
> Thanks for the heads-up. I saw this only after encountering the proble;
> I should have looked here first ;)
> 
> Can the issue be sidestepped using materials working at the moment with
> 13.1R-p6 ? The VC_BUILD_ID_TIME for start4.elf is Feb 25 2021. I was
> thinking of taking eg:
> 
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230316-cee09bda03c8-261544.img
> 
> mounting the msdos partition with mdconfig, removing what's there and
> copying over the known-to-be-working contents of /boot/efi on the 13.1
> system?
> 
> additionally, how can I stop the msdos partition being clobbered on the
> working system in some future freebsd-update of the working 13.1-p6
> system?

As of at least:

http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RC3-arm64-aarch64-RPI.img.xz

# uname -apKU # Booted on a "C0T" 8GiBYte RPi4B
FreeBSD generic 13.2-RC3 FreeBSD 13.2-RC3 releng/13.2-n254599-d9bf9d73203f GENERIC arm64 aarch64 1302001 1302001

FreeBSD-13.2-RC3-arm64-aarch64-RPI.img boots 8 GiByte
RPi4B's just fine.

This is because:

# strings /boot/msdos/u-boot.bin | grep "U-Boot 20"
U-Boot 2022.10 (Mar 17 2023 - 05:44:18 +0000)

So it appears that the FreeBSD-13.2-RC3-arm64-aarch64-RPI.img
builds are using the previous U-Boot version that did not have
the problem that 2023.01 has.

For reference:

# strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

It is not the RPi* firmware vintage that drives the
8 GiByte related boot failure: it is just 2023.01 of
U-Boot.

So only the u-boot.bin needs to be replaced, nothing
else.

But there are RPi* firmware vintage issues around:
main [so: 14] and stable/13 have had the FreeBSD kernel
fixed to allow recent RPi* firmware to boot. But
releng/13.2 and before do not have that fix and so
can not have RPi* firmware much more recent than is now
FreeBBSD-standard ( sysutils/rpi-firmware ). This likely
means that sysutils/rpi-firmware will be frozen until
releng/13.3 (so: about another year).


Note: I do not use freebsd-update to upgrade systems. But
I've expect it to only do FreeBSD material, not RPi*
firmware or U-Boot, just like bsd-install does not deal
with any non-FreeBSD aspects of things.

===
Mark Millard
marklmi at yahoo.com