Re: Strange u-boot behavior

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

> On Mon, Jun 07, 2021 at 01:09:52PM -0700, Mark Millard wrote:
>> 
>> 
>> 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:
>> 
>> 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
>> 
> Presto! using editenv usb_pgood_delay prompted for input, typing 10000
> and hitting return set the value and the disk was found.

Cool.

> It looks like the setting can only be saved to microSD. With
> no card saveenv reports
> Saving Environment to FAT... Card did not respond to voltage select!
> Failed (1)
> 
> 
> 
>> 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.
>> 
> 
> I didn't appreciate how independent u-boot's usb commands are.
> Info and tree could see the disk but dev, storage and reset didn't.

Looking in some actual U-Boots for other reasons, I
found no "usb scan" command. usb start (the first time)
and usb reset both did a scan automatically and the
help description indicated that scanning explicitly.

The behavior that you got, however, suggests that
internally the scan is still separate (and such
can be observed via some types of failures having
tree information left behind but not storage or
partition 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.
>> 
> 
> [regarding earlier, intermittent failures]
>> But did the problem cases show:
>> 
>>  Request Sense returned 02 04 01
>> 
>> or:
>> 
>> Device NOT ready
>> 
>> ? Or were such details different?
>> 
> 
> Not sure. When I saw that the disk wasn't detected, I waited a
> few seconds and re-ran usb reset. Within a few tries the disk
> was found. 
>> 
> 
> It's unclear to me what changed, probably something I did, but
> setting u-boot environment variable usb_pgood_delay=10000 seems
> to have put matters right again.


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