Re: Strange u-boot behavior

On 2021-Jun-5, at 21:31, bob prohaska <fbsd at www.zefox.net> wrote:

> For some time now I've been booting an Rpi3B+ using a microSD
> card configured with 
> U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700)

I'm unclear. Do you have the whole msdos file system
content on the microsd card and only the FreeBSD UFS
kernel+world on the USB drive? No msdos file system
on the USB drive?

Some of the confusion may become clearer about why I
might care in my later notes.

Another question: why still U-Boot 2019.10 instead of
updating to match, say, what is on modern RELEASE or
snapshot builds for the version of FreeBSD that you
are using on the RPi3B+ ? You seem to be using a
generally not-used combination by sticking to an older
U-Boot but updating other things.

What RPi3B+ firmware version? This can be found via:

# strings start.elf | grep "VC_BUILD_ID_"

Depending on what is reported: this might have
questions about the vintage used.

> by stopping it at the u-boot prompt and issuing
> usb reset
> followed by 
> run bootcmd_usb0
> after which the usb hard disk boots and all is well.
> 
> Lately, usb reset has taken to reporting
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... Device NOT ready
>   Request Sense returned 02 04 01
> 5 USB Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> 
> However, usb tree reports
> USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |   U-Boot Root Hub 
>  |
>  +-2  Hub (480 Mb/s, 2mA)
>    |
>    +-3  Vendor specific (12 Mb/s, 90mA)
>    |    FTDI FT232R USB UART AM00FGTR
>    |  
>    +-4  Vendor specific (480 Mb/s, 2mA)
>    |  
>    +-5  Mass Storage (480 Mb/s, 0mA)
>         ASMT ASM105x 12345678D558
> 
> The problem isn't wholly new; the usb reset command sometimes had
> to be repeated once or twice before the disk was found. Now it seems 
> a persistent failure. 
> 
> Once FreeBSD has booted, the disk is seen and accessed as usual. 

What alternatives have you tried?

*) Have you tried starting a boot sequence once with
   program_usb_boot_timeout=1 in config.txt , per notes in:

   https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow.md

   This programs a One Time Programmable bit to cause
   extra some time to be allowed. The
   program_usb_boot_timeout=1 does not need to be kept
   in place. After another reboot (to a RaspiOS
   in order to have the command available):

   vcgencmd otp_dump | grep 66

   should have bit 24 set in what it reports.

   This might only be useful for option (B) below. I've
   never found wording specifying the range of modes
   that this adds time to. But it might apply to all
   or most modes.

@) Have you tried any mixes of bootcode_delay=???,
   boot_delay=???, boot_delay_ms=??? in config.txt ?
   These are documented in:

   https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md

   bootcode_delay can add time before any start*.elf
   is read from whatever media --but it is not clear if
   the config.txt containing the bootcode_delay=???
   and start*.elf can be from different media.

   boot_delay and boot_delay_ms control waiting some
   amount of time in start*.elf before loading the
   next stage (U-Boot for FreeBSD's normal sequence).

A) Using a microsd card with only a modern bootcode.bin
   should be able to have the rest of the material on the
   USB device, including U-Boot. This way tends to have
   more fixes/improvements than depending on the internal
   support for direct USB booting: It supposedly works for
   more USB devices.

   I do this on a RPi2B v1.1 that does not have support
   (B) below. I have done this in temporary contexts
   on a RPi3B where (B) below seemed to have a
   problem for some reason. Dealing with booting from
   (some?) powered hubs can be a type of context where
   this proves useful.

   See:

   https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md

   and "Special bootcode.bin-only boot mode" in:

   https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

   If the msdos file system that contains bootcode.bin also
   contains an empty file named "timeout" it will wait
   longer for a USB device to be ready. See "Known issues"
   in:

   https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

B) "The Raspberry Pi 3B+ supports USB mass storage boot out
   of the box". So, unless some of those improvements
   metioned in (A) turn out to be necessary, no microsd card
   should be needed, presuming that all the required
   material (including U-Boot) is on the USB drive.

   I do this on a RPi3B and RPi2B v1.2 (after enabling them:
   not "out of the box") and all the RPi4B's. (Some RPi4B's
   required eeprom updates to enable this.)

   This does not give any control over getting extra time
   for the USB device to be ready: it would first have to
   have already read something from the device. But the
   details of this might be better than the details of
   some specific microsd card based RPi3B+ firmware boots.
   I.e., it might be worth a try.

C) I will note that it is possible to have the FreeBSD
   kernel also on the microsd card in a UFS partition and
   to have "world" on the USB drive. This leads to only
   FreeBSD's kernel and later using the USB drive. But
   keeping the copy of the kernel and such on the
   separate media is messier and atypical.

   (Note: I do this sort if thing for the ROCK64 where
   the dd'd U-Boot does not support USB for the FreeBSD
   loader to put to use. I defer USB first-use to the
   kernel.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)