Date: Wed, 22 Mar 2023 10:48:59 -0700 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm> Cc: freebsd-arm@freebsd.org Subject: Re: FYI: upcoming 13.2-RELEASE vs. 8 GiByte RPi4B's based on U-Boot 2023.01 recently in use, given UEFI style booting Message-ID: <FDE62A7E-11CC-4F25-99B7-AC72460267EA@yahoo.com> In-Reply-To: <ZBs38XQr/MPVGNeC@int21h> References: <2B3378B0-A506-4A90-80D4-734AAA5EE774.ref@yahoo.com> <2B3378B0-A506-4A90-80D4-734AAA5EE774@yahoo.com> <ZBs38XQr/MPVGNeC@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) >=20 > Thanks for the heads-up. I saw this only after encountering the = proble; > I should have looked here first ;) >=20 > 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: >=20 > = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230316-cee09bda03c8-261544.img >=20 > 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? >=20 > 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. =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?FDE62A7E-11CC-4F25-99B7-AC72460267EA>