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

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.

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