Re: Updating RPi boot materials, was Re: RPI4 panic on boot with -current

[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:
> 
>> On Sat, Apr 09, 2022 at 05:22:49PM -0700, Mark Millard wrote:
>>> 
>>>> So how are pkg or other such to deal with updating such generally
>>>> bootable media?
>> 
>> 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=/usr/local/share/u-boot/u-boot-rock64/idbloader.img of=/path/to/sdcarddevice seek=64 bs=512 conv=sync
> dd if=/usr/local/share/u-boot/u-boot-rock64/u-boot.itb of=/path/to/sdcarddevice seek=16384 bs=512 conv=sync
> 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*?
>>> 
>> 
>> 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 
>> 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 
>> 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.

"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).
> 
> 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 
>> on, no?  
> 
> 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)?
>>> 
>> 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?
>>>> 
>> 
>> 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.
>>>> 
>> 
>> 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.
>>>> 
>> 
>> 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.
>>>> 
>> 
>> 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". 
>> 
>>>> 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.
>>>> 
>> 
>> But in practice they are, and it's useful for most folks.
>> 
>>>> 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.
>>>> 
>> 
>> Curiously, my Pi4 has an empty /boot/efi, but I've never
>> tampered with it.
>> 
>>>> 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?
>>>> 
>> 
>> Just report "path not found" and list what was expected.
>> 
>>>> 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.
>>> 
>> 
>> My plea is not for adaptability, but acceptance of convention. 
> 
> 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. 
>> 
> 
> 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=$LOCALBASE/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin of=/path/to/sdcarddevice bs=1k seek=8 conv=sync
> 
> dd if=/usr/local/share/u-boot/u-boot-rock64/idbloader.img of=/path/to/sdcarddevice seek=64 bs=512 conv=sync
> dd if=/usr/local/share/u-boot/u-boot-rock64/u-boot.itb of=/path/to/sdcarddevice seek=16384 bs=512 conv=sync
> 
> dd if=$LOCALBASE/share/u-boot/u-boot-sinovoip-bpi-m3/u-boot-sunxi-with-spl.bin of=/path/to/sdcarddevice bs=1k seek=8 conv=sync
> 
> dd if=/usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin of=/path/to/sdcarddevice bs=128k seek=1 conv=sync
> 
> /boot/msdosfs mount point conventions do no good for any of those
> specific commands.
> 



===
Mark Millard
marklmi at yahoo.com