Re: Strange u-boot behavior

Reply: Mark Millard via freebsd-arm : "Re: Strange u-boot behavior"
Reply: Mark Millard via freebsd-arm : "Re: Strange u-boot behavior"
In reply to: Mark Millard via freebsd-arm : "Re: Strange u-boot behavior"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: bob prohaska <fbsd_at_www.zefox.net>
Date: Sun, 06 Jun 2021 16:00:40 UTC
On Sun, Jun 06, 2021 at 12:11:20AM -0700, Mark Millard wrote:
> 
> 
> 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?

It's a dual-boot system, with a complete FreeBSD-current  install
on both USB and microSD storage. 

> 
> 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.
>
Purely inertia. U-boot doesn't update via the normal make install
cycle, requiring a careful reading of notes for manual upgrade. 
It was usable two months ago, though not without hiccups. 
  
> What RPi3B+ firmware version? This can be found via:
> 
> # strings start.elf | grep "VC_BUILD_ID_"
>
# strings start.elf | grep "VC_BUILD_ID_"
VC_BUILD_ID_USER: dc4
VC_BUILD_ID_TIME: 15:31:38
VC_BUILD_ID_BRANCH: master
VC_BUILD_ID_TIME: Jun  7 2018
VC_BUILD_ID_HOSTNAME: dc4-XPS13-9333
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 4800f08a139d6ca1c5ecbee345ea6682e2160881 (clean)

That's old, but it used to work with this USB train.  


> 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
> 

Just tried it, usb scan still fails to find the mass storage device while 
usb tree sees it.

>    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.
> 

The "boot from USB" OTP was set during initial experiments
some time ago.
 

> @) 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).
>

I'm seeing lots of 
MESS:00:00:01.300591:0: hdmi: HDMI:EDID error reading EDID block 0 attempt... 
 errors from u-boot. Up to now they didn't seem to matter. 
 
> 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'm using that method on a Pi2, but haven't tried it on the
Pi3B since it's a dual-boot. 
 
>    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.

Indeed, if the disk is moved to the hub it's overlooked by
usb tree in addition to being missed by usb scan. 

> 


>    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.)

It looks to me like upgrading u-boot on the microSD should
be the first priority. There remains a lingering suspicion
that the USB-SATA adapter (a Startech) might be part of the
problem, but why it might stop working now is unclear. 

Thanks for writing!

bob prohaska