Re: U-boot on RPI3, sees disk but won't boot it

On 2022-Sep-21, at 18:45, bob prohaska <[email protected]> wrote:

> On Wed, Sep 21, 2022 at 01:27:45PM -0700, Mark Millard wrote:
>> I used:
>> 
>> tar -xf /usr/ports/distfiles/u-boot/u-boot-2022.04.tar.bz2 u-boot-2022.04/include/configs/rpi.h
>> 
>> to create a local u-boot-2022.04/include/configs/rpi.h
>> in order to look at the modern file. The
>> ENV_DEVICE_SETTINGS line from:
>> 
>> #define CONFIG_EXTRA_ENV_SETTINGS \
>> 	"dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
>> 	ENV_DEVICE_SETTINGS \
>> 	ENV_DFU_SETTINGS \
>> 	ENV_MEM_LAYOUT_SETTINGS \
>> 	BOOTENV
>> 
>> appears to be at line 173.
>> 
>> A correct patch file finds the matching lines despite the
>> difference in line numbers, a difference that is not too
>> large by its matching criteria (given correct text matches).
>> 
>> The modern FreeBSD lists might allow text attachments so
>> I'll try that publicly. (It still has the 210 line number.)
>> 
> The patch emailed as an attachment applied without a problem.
> Better still, it seemed to help with mass storage device discovery
> for the first five or so tries. Around try six, the system lost
> the ability to recognize the USB mass storage device and then
> seemed to get stuck in a loop, with repeated attempts failing. 
> 
> After setting initial_turbo=60 in config.txt the first reboot
> found the disk, the second did not. Running usb reset then
> found the disk, but run bootcmd_usb0 seemingly caused a reset
> that  _then_ found the disk. 
> 
> The display of usb tree output isn't always the same. On a failed try it 
> looked like
> 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 AM00KE3E
>    |  
>    +-4  Vendor specific (480 Mb/s, 2mA)
>    |  
>    +-5  Hub (480 Mb/s, 100mA)
>      |  GenesysLogic USB2.1 Hub 
>      |
>      +-6  Mass Storage (480 Mb/s, 500mA)
>           JMicron  
> 
> On a successful try it looked like 
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0 
> U-Boot> usb tree
> USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |   U-Boot Root Hub 
>  |
>  +-2  Hub (480 Mb/s, 2mA)
>    |
>    +-3  Hub (480 Mb/s, 100mA)
>    | |  GenesysLogic USB2.1 Hub 
>    | |
>    | +-6  Mass Storage (480 Mb/s, 500mA)
>    |      JMicron SABRENT 000000000000A
>    |    
>    +-4  Vendor specific (12 Mb/s, 90mA)
>    |    FTDI FT232R USB UART AM00KE3E
>    |  
>    +-5  Vendor specific (480 Mb/s, 2mA)
> 
> Not sure if this is even relevant, but it does seem odd.
> 

(Response delayed by an OS upgrade mess [not FreeBSD].)

As I understand it USB* standards do not define a stable
order for devices to enumerate. So even if all the boots
worked, if you had a record of the "USB device tree" for
each you would likely find that the trees varied in what
the numbering (and, so ordering) was.

More significant might be the distinction:

Mass Storage (480 Mb/s, 500mA)
          JMicron

vs.

Mass Storage (480 Mb/s, 500mA)
JMicron SABRENT 000000000000A

where the one that does not say "SABRENT 000000000000A"
(less information) is the one that failed. Seems like
it could not complete its SABRENT related activity
successfully/completely even though the rest of the
tree looks normal (ignoring numbering/ordering).

Overall your description seems to be "still varies
based on a seemingly random basis" and the problem
was not fixed by the patch / initial_turbo
combination. It does not even seem obvious that a
long run failure rate would be noticeably improved.

The "SABRENT" aspect might be the only part that is
varying in a manor that matters. But I do not know
what to do to investigate that aspect.

===
Mark Millard
marklmi at yahoo.com