Re: Strange u-boot behavior

On 2021-Jun-7, at 11:40, bob prohaska <fbsd at www.zefox.net> wrote:

> On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via freebsd-arm wrote:
>> 
>> 
>> On 2021-Jun-6, at 09:00, bob prohaska <fbsd at www.zefox.net> wrote:
>> 
>>> 
>>> It's a dual-boot system, with a complete FreeBSD-current  install
>>> on both USB and microSD storage. 
>> 
>> How do you control which device provides kernel+world
>> if both have a kernel_world?
>> 
> 
> If the machine is powered up and not touched, it boots from the
> microSD card. If boot is interrupted at the u-boot prompt it's
> (was) possible to issue a 
> usb reset
> command, at which point the external USB hard drive was discovered.
> At that point issuing a 
> run bootcmd_usb0
> command would boot kernel and mount world from the USB device. 

I see I force to to tell me what you had already reported.
Sorry for that.

As for your manual usb commands . . .

Looking around on the web I see reports of the:

  Request Sense returned 02 04 01

(and the matching Device NOT ready) mean that the
problem will occur and that repeating usb start
or usb reset again until it does not report that
leads to things working.

But I've also seen other, more complete information
indicating that there is a environment setting
(showing an example value):

usb_ready_retry=5

to set up before the usb restart (or usb start)
command. It deals with the issue more explicitly
for slow devices.

Another one is (units: msec):

usb_pgood_delay=10000

There are also device that have problems with
large transfers and require extra protocol to
deal with transfer problems before they will
work again, U-Boot not doing that.

usb_max_blk=20

sets a old historical value that generally
just works for such devices form what I read.

I see no indication that other usb commands are
worthwhile until one has avoided that "Request
Sense returned 02 04 01" message for usb reset
(a.k.a. usb start).

The reports of this sort of thing are not limited
to RPi's and go back to at least 2014.

If I understand correctly, usb_ready_retry and
usb_pgood_delay and usb_max_blk are part of
normal U-Boot builds these days. But I'm not
certain of that.


I will note:

QUOTE
Common USB Commands:
- usb start:
- usb reset:	    (re)starts the USB. All USB devices will be
		    initialized and a device tree is build for them
- usb tree:	    shows all USB devices in a tree like display
. . .

Storage USB Commands:
- usb scan:	    scans the USB for storage devices.The USB must be
		    running for this command (usb start)
. . .
END QUOTE

Note that the wording indicates that having the tree is not
the same as having classified the storage devices: storage
classification is an seprate step.

"usb reset" seems to automatically do a scan. But, still,
the tree listing things that "usb storage" or "usb part"
would not is apparently normal util after a successful
"usb scan" has occured (possibly automatically executed).


>> I suggest trying the same vintage that is on 13.0-RELEASE's
> 
> I've written the 13.0-release image to a microSD card and tried
> that. It reports a version of
> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000)
> 
> Stopped at the u-boot prompt and given the 
> usb reset command, zero storage devices are found. However,
> usb tree still 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 mismatch between what usb reset and usb tree report strikes me
> as extremely puzzling.

See my earlier notes about tree vs. storage and part information.

> As an experiment, I tried booting with no microSD card installed at
> all. This got confusing; u-boot still came up, apparently from the
> USB hard drive.

The RPi internal code is handling the USB drive
initially and loading the RPifirmware from the
USB drive. That firmware is in turn loading
U-Boot in this case.

It is when U-Boot tries to take over and set up
the USB drive for its own use that things are
having the problem.

> The USB disk is still not found by usb scan, but it 
> is recognized by  usb tree. 

See the earlier notes about tree vs. storage and
part information.

> As a final test I tried connecting a monitor that had been used with 
> this Pi previously. The monitor's presence made no difference, the
> display looked normal.  
> 
> A hands-off boot to single user is successful from the microSD card. 
> It's possible to see and access the USB hard drive. 

This sequence by-passes U-Boot having to have usb
storage operational. The FreeBSD kernel is better
behaved for handling the properties of your devices
involved.

> At this point I'm beginning to suspect some obscure mischief with the
> USB-SATA adapter, based only on earlier intermittent problems detecting
> the USB hard drive. In those cases a few repeats of usb scan found
> the disk and allowed booting from it.   

But did the problem cases show:

  Request Sense returned 02 04 01

or:

Device NOT ready

? Or were such details different?


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