Re: Strange u-boot behavior

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.

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.


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

Thank you!

bob prohaska