Date: Sun, 10 Apr 2022 01:02:15 -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: <A9BF2793-F50F-45B0-8505-59EA56739AEA@yahoo.com> In-Reply-To: <20220410033906.GA57250@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Apr-9, at 20:39, bob prohaska <fbsd@www.zefox.net> wrote: > 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. 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 .) > There are lots of platform-specific ports for u-boot. Why not match > the install target to the named platform? And how does one do that? > If folks go to the trouble > of creating a port for a platform it's little extra work to add the > pathnames. 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. For example, for the Rock64 the instructions for its U-Boot and related material are: 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 The dd commands are very dangerous when done inappropriately. "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. Lots of Small Board Computers have multiple devices that can hold the U-Boot involved, with some means of control over which is used. > What you're talking about seems far more ambitious. Seems you are viewing what you want to happen as trivially easy to make happen. >> 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. All the machines I listed were aarch64: What cross compile? 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? > The platform details=20 > would be part of the package. 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. > 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, 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. 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). 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. > 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 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. >> 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. 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. >>> 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. So, here the admin must know/remember where things need to be and set up the mounts, it is not automatic. >>> 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. 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. >>> 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? 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.) So any such convention is of limited utility across the range of Small Board Computers. >>> 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? 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). > 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 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. Basically, you are asking for special handling of RPi*'s, at least relative to U-Boot. > Identify a platform and a location Normally: not a file system location at all for U-Boot. > then put that info in the > port install target. Let convention be set by the image.=20 >=20 Again: It is rare that a type of Small Board Computer has its U-Boot in any file system location. 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): 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 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 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 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 /boot/msdosfs mount point conventions do no good for any of those specific commands. =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?A9BF2793-F50F-45B0-8505-59EA56739AEA>