Date: Sat, 9 Apr 2022 15:26:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: RPI4 panic on boot with -current Message-ID: <63FAC16E-2C49-4A09-BDC8-ED6E74FAA3BB@yahoo.com> In-Reply-To: <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com> References: <20220409015321.GA52002@www.zefox.net> <D89DA316-FF83-4BB9-A1FD-DE8591B8B3D6@yahoo.com> <20220409154433.GB55458@www.zefox.net> <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Apr-9, at 13:59, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Apr-9, at 08:44, bob prohaska <fbsd@www.zefox.net> wrote: >=20 >> On Fri, Apr 08, 2022 at 07:46:57PM -0700, Mark Millard wrote: >>> On 2022-Apr-8, at 18:53, bob prohaska <fbsd@www.zefox.net> wrote: >>>=20 >>>> Might this be related to "RPi4B's got a PMIC replacement,..." = reported 4/3 ? >>>=20 >>> No: See the later note about the RPi4B Revision. >>>=20 >>>> A Pi4 (mechanical disk only, no microsd) trying to boot a fresh = build of=20 >>>> -current reports: >>>>=20 >>>> Resetting system ...=20 >>>>=20 >>>> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000) >>>=20 >>> This is an old U-Boot compared to sysutils/u-boot-* . >>> There may well be good reasons for using it, for all >>> I know. >>>=20 >>=20 >> Only the most universal reasons: Inertia and ignorance 8-) >>=20 >> There are many versions of u-boot for rpi boards, some of=20 >> which are rather ambiguously named; u-boot-rpi-arm64 versus >> u-boot-rp4 is a good example. >=20 > u-boot-rpi-arm64 handles various RPi4B's, RPi3*'s, and, if I > remember right, RPi2B v1.2's. This is what snapshots and > BETA and PRERELEASE and RELEASE builds use these days. >=20 > The older ports are more specific, as I understand: >=20 > u-boot-rpi4 does not handle RPi3*'s or RPi2B v1.2's. > u-boot-rpi3 does not handle RPi4B's. >=20 > So the usable-contexts do overlap. Technically. there is no > unique answer to which to use. >=20 >> It appears the pkg-descr files >> have been updated since I last looked, but the descriptions >> overlap and it's not obvious how to choose among them. Man >> pages seem passe, is there some other guidance?=20 >>=20 >> Even if one knows which to select and build from ports the >> make install command doesn't really install; the admin still >> has to know what files to copy where. >=20 > With good reason for where: the msdosfs file system is not part > of FreeBSD's file systems (UFS or ZFS) and there is no standard > mount point for the msdosfs in FreeBSD's file system. >=20 > The admin may well be able to set up scripts that match how they > have things configured. >=20 >> Your instructions for=20 >> the task have been noted and saved, but even then it's very >> easy to make mistakes that are hard to recover from. >=20 > I suspect that you are referring to more than u-boot.bin above, > i.e., not just U-Boot. >=20 > Keeping a copy around of the last known-usable msdosfs content > before updating it is appropriate. The copy should be someplace > that can be used to replace any problematic update to the > msdosfs content. >=20 >> Does pkg handle u-boot and firmware updates more automatically? >=20 > No, with good reason for where: the msdosfs file system is not part > of FreeBSD's file systems (UFS or ZFS) and there is no standard > mount point for the msdosfs in FreeBSD's file system. >=20 > The admin may well be able to set up scripts that match how they > have things configured. >=20 >> Alternatively, is it feasible to update u-boot and firmware with >> an "installboot" target, either from the port directory or /usr/src? >=20 > No, with good reason for where: the msdosfs file system is not part > of FreeBSD's file systems (UFS or ZFS) and there is no standard > mount point for the msdosfs in FreeBSD's file system. >=20 > The admin may well be able to set up scripts that match how they > have things configured. >=20 I should have noted more fully: The issue is Small Board Computers in general, not just RPi*'s. RPi*'s are unusual in that U-Boot goes in an msdosfs instead of being dd'd someplace. And the RPi*'s firmware placement and handling is also atypical. Nothing even says that a msdosfs has to be mounted in FreeBSD at all. In fact, for a microsd card msdosfs used for RPi* firmware and u-boot.bin , but the EFI msdosfs being on a USB drive, along with a UFS or ZFS file system, there are two msdosfs around and used during booting, neither of which has to ever be mounted in FreeBSD at all in order for the system to boot and operate. (I use this EFI on "only the same media as UFS or ZFS" all the time. It allows me to use a microsd card to override any RPi* firmware or the like on that media that has UFS/ZFS, a microsd card that does not have the EFI content but has the other stuff. This can be handy for some forms of recovery from rpi* firmware/U-Boot/FreeBSD combinations that do not work well together.) And what if the devices connected overall have more than one msdosfs around that has RPi* firmware and/or u-boot.bin ? Which ones should be updated? Nothing requires that the snapshot/PRERELEASE/BETA/RC/RELEASE build images be used or that things outside FreeBSD file systems be organized the same as on those images. pkg and such can not presume that they are. The admin may well be able to set up scripts that match how they have things configured for the system. =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?63FAC16E-2C49-4A09-BDC8-ED6E74FAA3BB>