Date: Sun, 10 Apr 2022 11:35:09 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with -current Message-ID: <D3C3F791-94F8-4D19-AF7F-C13956EF63D8@yahoo.com> In-Reply-To: <A9BF2793-F50F-45B0-8505-59EA56739AEA@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> <20220409221742.GB56550@www.zefox.net> <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com> <FFBEF36E-E8F5-4DF6-9598-9417C18DC324@yahoo.com> <20220410033906.GA57250@www.zefox.net> <A9BF2793-F50F-45B0-8505-59EA56739AEA@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Just fixing a really bad typing mistake.] On 2022-Apr-10, at 01:02, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Apr-9, at 20:39, bob prohaska <fbsd@www.zefox.net> wrote: >=20 >> On Sat, Apr 09, 2022 at 05:22:49PM -0700, Mark Millard wrote: >>>=20 >>>> So how are pkg or other such to deal with updating such generally >>>> bootable media? >>=20 >> I don't think they can be expected to update alien media. >=20 > What alien media? Depending on how you have things set up for > /etc/fstab use, likely your no-microsd-card-required USB3 > RPi4B media would boot the same list of machines that I > indicated. ( I use labels to avoid numbering variations > and reference the labels in /etc/fstab .) >=20 >> There are lots of platform-specific ports for u-boot. Why not match >> the install target to the named platform? >=20 > And how does one do that? >=20 >> If folks go to the trouble >> of creating a port for a platform it's little extra work to add the >> pathnames. >=20 > Most Small Board Computers do not have file path names for > U-Boot materials: They are put outside the file systems > on the media. There is a "seek" position on the media. > RPi*'s are fairly rare for putting such in a file system at > all. >=20 > For example, for the Rock64 the instructions for its U-Boot > and related material are: >=20 > QUOTE > To install this bootloader on an sdcard just do: > dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img = of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync > dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb = of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync > END QUOTE >=20 > The dd commands are very dangerous when done inappropriately. >=20 > "sdcarddevice" is only suggestive, since other types of > devices are possible. In fact, the Rock64 I use boots via > an e.MMC device that the board supports, not the microsd card > slot. That is true even if a microsd card is in the slot at > boot. As I remember, there is a jumper on the board for > controlling which of the two is used by default. >=20 > Lots of Small Board Computers have multiple devices that can > hold the U-Boot involved, with some means of control over > which is used. >=20 >> What you're talking about seems far more ambitious. >=20 > Seems you are viewing what you want to happen as > trivially easy to make happen. >=20 >>> I should have explicitly noted: How likely is that that I'd happen >>> to always do FreeBSD updates on a aarch64 RPi* instead of one of >>> the other systems, especially the faster ones? Is pkg to notice and >>> update RPi* boot materials because the updated system could also >>> boot an aarch64 RPi*? >>>=20 >>=20 >> Presumably you'd cross compile a package for the intended target and >> then install the package on the running target. >=20 > All the machines I listed were aarch64: What cross compile? >=20 > Your wording presumes that the target boots fine already. What > about setting up the first boot ever for the target --or > recovering from boot failures? >=20 >> The platform details=20 >> would be part of the package. >=20 > Which boot media is in use for the RPi* firmware and U-Boot stage > is not a fixed property of RPi* platform: it can be used various > ways via configuring it differently. >=20 >> If the target is RPi3 and you're compiling=20 >> on Cavium, the RPi3 paths would be part of the package. The Cavium >> won't be running the pkg install, >=20 > As stands "pkg install" means putting the directory tree with the > instructions and files under the likes of /usr/local/share/u-boot/ . > You are creating a distinct operation and reuse of the terminology > makes things are to talk about/follow. "makes things hard to talk about/follow" > But if a Cavium has USB ports or microsd card ports supported by > FreeBSD, it certainly could be used to create the matching type of > media for a RPi4B, including getting RPi* firmware and U-Boot in > place, as well as EFI and UFS/ZFS material (same or different > media). >=20 > For the machines I listed in an earlier part of the exchange, they > all can produce USB drives usable in booting all of the others --and > I take great advantage of that. The two machines with PCIe slots > can produce PCIe media used in booting that work in both. The Rock64 > can produce microsd card boot-media for any of the machines. And > so it goes. >=20 >> but I don't think that's possible >> in any case. Both pkg and make install work on the host they're = running=20 >> on, no? =20 >=20 > The assumption that things need to be run on the target system > would be false. That is only one way of working when multiple > systems are available for use. >=20 >>> This better illustrates what I'm referring to when I reference pkg >>> and the like identifying contexts and handling a variety of them. >>> Should it be checking if it happens to be running on a RPi* and >>> behave differently than it would on other types of systems (same >>> boot media)? >>>=20 >> That's the admin's discretion. He knows what the target architecture >> is and the media being written. >=20 > So it can not be automatic and the admin must do the work to > set up something that matches the context --at least that sounds > like what you are saying. >=20 >>>> Or: Say that the RPi* has a msdosfs on its USB device that is >>>> able to be used for booting. But that, at the time, there is >>>> also a microsd card present that capable of being used for >>>> booting, at least for the RPi* firmware and u-boot.bin stages. >>>> What sort of activity is pkg supposed to do to identify the >>>> context? How would pkg even identify, say, which way FreeBSD >>>> had been booted? >>>>=20 >>=20 >> I'd suggest this is an unrealistic scenario. Pkg can know what >> files it's supposed to update, the admin has to make those files >> accessible. If the wrong paths are mounted, that's a wetware problem. >=20 > So, here the admin must know/remember where things need to be > and set up the mounts, it is not automatic. >=20 >>>> The early stages of RPi* booting are outside FreeBSD's direct >>>> control and there are a lot of possibilities. >>>>=20 >>=20 >> Yes, too many. The admin has to constrain them. >=20 > Admin? FreeBSD? If the procedures are part of FreeBSD instead > of being created by the Admin, it is not the Admin that is > placing the constraints. >=20 >>>> Nothing in FreeBSD says that /boot/msdos should exist or be the >>>> mount point used as far as I know. It is just something that the >>>> snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently, >>>> do by the free choice of the author(s) involved. >>>>=20 >>=20 >> But it does exist and is useful. Why not use it? >=20 > Most Small Board Computers do not have U-Boot in any file > system: no way to mount anything to /boot/msdos that would > help with the typical dd commands for U-Boot (and related > material). It only works for the files that go in a msdosfs. > (RPi*'s are unusual for this.) >=20 > So any such convention is of limited utility across the > range of Small Board Computers. >=20 >>>> In fact, if you tried to use bsdinstall to set up a RPi* >>>> context, it would not set up something like the >>>> snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I >>>> know. >>>>=20 >>=20 >> Can it work at all? >=20 > As I remember, it can set up a EFI file system with FreeBSD's > loader in it. The other files would have to be copied over > (presuming the same media was the desired target for them). >=20 >> I always prefered the installer whose man >> page said it was "greaty in need of death".=20 >>=20 >>>> Nothing says that RPi*'s have to be set up the same as the >>>> snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential >>>> differences in question are not part of FreeBSD. >>>>=20 >>=20 >> But in practice they are, and it's useful for most folks. >>=20 >>>> Another common convention is /boot/efi (especially when the >>>> msdosfs invovled has the FreeBSD efi boot loader as well). >>>> FreeBSD does now have some predefined behavior for this >>>> convention. >>>>=20 >>=20 >> Curiously, my Pi4 has an empty /boot/efi, but I've never >> tampered with it. >>=20 >>>> What if nothing is mounted to /boot/msdos or to /boot/efi >>>> at the time (say, disabled in /etc/fstab)? How much analysis >>>> of the context is pkg or such to do and adjust for? >>>>=20 >>=20 >> Just report "path not found" and list what was expected. >>=20 >>>> The FreeBSD loader.efi has the same sort of "there is no >>>> fixed place for it" issue. Other than the /boot/efi use, >>>> there is no automatic update of loader.efi either. This is >>>> largely because the copy used to boot is not in a FreeBSD >>>> UFS/ZFS file system at all --but in some msdosfs file >>>> system, possibly with a special partition type. >>>=20 >>=20 >> My plea is not for adaptability, but acceptance of convention.=20 >=20 > The convention does not work for most types of Small Board > Computer U-Boot (and related) placements: Most use dd to > someplace outside all file systems. RPi*'s are unusual in > that they have u-boot.bin as a file in a file system. For > example, /boot/msdosfs as a mount point does no good for > U-Boot (or its related file) for a Rock64. >=20 > Basically, you are asking for special handling of RPi*'s, > at least relative to U-Boot. >=20 >> Identify a platform and a location >=20 > Normally: not a file system location at all for U-Boot. >=20 >> then put that info in the >> port install target. Let convention be set by the image.=20 >>=20 >=20 > Again: It is rare that a type of Small Board Computer has its > U-Boot in any file system location. >=20 > The assumption that most things are like RPi*'s is false based > on what I've seen. For example (from README's of 4 u-boot ports > for devices I use or have used): >=20 > dd = if=3D$LOCALBASE/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl= .bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync >=20 > dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img = of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync > dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb = of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync >=20 > dd = if=3D$LOCALBASE/share/u-boot/u-boot-sinovoip-bpi-m3/u-boot-sunxi-with-spl.= bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync >=20 > dd if=3D/usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin = of=3D/path/to/sdcarddevice bs=3D128k seek=3D1 conv=3Dsync >=20 > /boot/msdosfs mount point conventions do no good for any of those > specific commands. >=20 =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?D3C3F791-94F8-4D19-AF7F-C13956EF63D8>