Re: Saving environment variables in u-boot

On 2021-Dec-16, at 17:36, bob prohaska <fbsd@www.zefox.net> wrote:

> On Thu, Dec 16, 2021 at 11:12:01AM -0800, Mark Millard via freebsd-arm wrote:
>> 
>> 
>> On 2021-Dec-16, at 10:07, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> U-Boot> saveenv
>>> Saving Environment to FAT... Failed (1)
>> 
>> I expect that is based on there being a microsd card with
>> a FAT file system on it, possibly containing the u-boot that
>> is in use. I doubt that it supports saving to a FAT on USB
>> media. Do you have an appropriate microsd card in place?
>> 
> 
> Yes, the microSD contains a dd of 
> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img
> The DOS partition is writeable, AFAIK.

Hmm. That means there is also a UFS root with
a kernel and world on the microsd card. Both
the microsd card and the USB drive contain
contain such, as well as each having an
/etc/fstab (and so on).

Having multiple such makes for a mess for
controlling which is used (and knowing which
is used). What is the first stage that you
made sure the USB drive was in use and how
did you make sure?

You also have 2 U-Boot's and 2 sets of RPi*
firmware: similar issues for those. What are
you doing to control which is used vs. which
is not? avoiding extra copies is the
simplest way to be sure which started for a
stage (once you get a stage to start).

The order of activity is:

MSDOSFS: (all on one of: microsd card vs. usb drive)
RPi* firmware (I do not report the file-level sequencing)
U-Boot
FreeBSD loader (which uses information from U-Boot)

UFS: (both: together on one of: microsd card vs. usb drive)
FreeBSD kernel
FreeBSD world

(I do not specify which MSDOSFS is used when
there are multiple viable ones in separate places.
Similarly for UFS.)

I word the below deliberately avoiding getting
into how to control which is used when multiple
copies of some things are present in various
usable forms/places.

(It is technically possible to have kernel vs.
world in separate UFS partitions, possibly on
separate media. I've an example context that I
deal with that way to avoid a U-boot limitation
for the device: the kernel can find the world
where the U-Boot/FreeBSD-Loader can not. (The
FreeBSD loader depends on what USB can find: it
does not look elsewhere.) I only mention this
in case I need to reference it in the future,
avoiding a surprise in such a case. Otherwise
ignore the complication.)

You might move (not copy) the MSDOSFS material
between the microsd card and the usb drive during
experiments, avoiding having duplications. There
is the possibility of instead renaming things so
files are not found on a partition, for example.
A similar point goes for UFS materials: avoid
having multiple viable-for-booting UFS file
systems present.

As stands, things seem too hard to track for me
to be of much help. Please make things obvious for
what was in use by making the material uniquely
placed (for the form that can be used).

Separate issues/questions:

Do you have the file "timeout" in the MSDOSFS, in
addition to config.txt and the like? If not, I
recommend including it.

What other RPi* firmware controls for having
various deliberate RPi* firmware delays do you
have set up?

It is not so much that these would be sufficient,
but they do establish some context before U-Boot
is even active. It could be important to
understand that context. (Unsure at this point.)


>> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports.
>> (They also later mentioned using "usb_pgood_delay=2000\0"
>> instead, a figure they found in a bunch of configrations.)
>> 
> The Pi3 in question is capable of booting from solid-state USB
> storage without any microSD card, but fails to detect a mechanical
> disk. Which is the appropriate u-boot-rpi3 port to tamper with? I 
> tried sysutils/u-boot-rpi3 as an upgrade but that simply froze. 
> The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds
> the USB mechanical disk,  but erratically. 

FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img uses u-boot-rpi-arm64
as I remember: it is set up for both the RPI3 and RPI4. Given that
it works some, that would be the U-Boot port I would experiment
with if I was doing the experiments.

>> So something somewhat analogous might help if you are willing
>> to build and use your own u-boot port variant.
> 
> Obviously, that's a fraught enterprise at my skill level....
> I'm still somewhat hazy on the actual boot sequence when
> chaining from microSD to USB. 

Having the extra text in the U-Boot build does not really
depend on the chaining order question.

But, to repeat (sticking to the simpler context),
the order is:

MSDOSFS: (all on one of: microsd card vs. usb drive)
RPi* firmware (I do not report the file-level sequencing)
U-Boot
FreeBSD loader (which uses information from U-Boot)

UFS: (both: together on one of: microsd card vs. usb drive)
FreeBSD kernel
FreeBSD world


> Indeed, it's unclear how or if u-boot plays a role in starting 
> RasPiOS. The term u-boot isn't found on the Raspberry Pi doc 
> website, and the Pi isn't mentioned in the Denx manuals. Those
> discoveries surprised me.

RaspiOS and RaspiOS64 do not use U-boot. The RPi*'s can boot some
forms of a linux kernel directly and that is what RaspiOS and
RaspiOS64 are doing. That is why the config.txt type of content
makes no mention of u-boot or of any kernel= assignment in RaspiOS
and RaspiOS64. By contrast, config.txt for FreeBSD lists kernel=
and an explicit *u-boot*.bin as the value.

By contrast to RaspiOS and RaspiOS64, Fedora chooses to use U-Boot
and lists kernel= assignment(s), each listing a *u-boot*.bin .


===
Mark Millard
marklmi at yahoo.com