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

On 2022-Sep-30, at 09:40, Klaus Küchemann <maciphone2@googlemail.com> wrote:


>> Am 30.09.2022 um 02:27 schrieb bob prohaska <fbsd@www.zefox.net>:
>> ……
>> .
>> I just captured an example now. Because of the file’s
>> size it's at 
>> http://nemesis.zefox.com/~fbsd/ 
>> in a file named 
> ……..
> 
> O.K., you now have extended logs..fine...
> comparing success/fail we see:
> 
> -fail---

This is for:

Manufacturer 
Product      U-Boot Root Hub
SerialNumber 
bind node usb1@1

> port 1 returns 0
> pgood_delay=2000ms

The 2000ms is from the U-Boot build setting usb_pgood_delay
explicitly: Bob is using the part of the patch that I use to
get my every different devices to boot.

> devnum=1 poweron: query_delay=2000 connect_timeout=3000
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> Port 1 Status 311 Change 1
> devnum=1 port=1: USB dev found
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> portstatus 311, change 1, 1.5 Mb/s
> ...
> STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0
> Cannot enable port 1 after 5 retries, disabling port.
> Maybe the USB cable is bad?
> cannot reset port 1!?
> 
> -success----
> port 1 returns 0
> pgood_delay=2000ms

Same point again.

> devnum=1 poweron: query_delay=2000 connect_timeout=3000
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> Port 1 Status 511 Change 1
> devnum=1 port=1: USB dev found
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> portstatus 511, change 1, 480 Mb/s
> --
> 
> So we now know that when it fails, the issue consists of an underpowered port1 of the USB-Hub
> ( what doesn't necessarily mean that the hub itself is the root cause)
> 
> We see the values of query_delay / connect_timeout / pgood_delay 
> and some informative (device specific)problem descriptions ( as comments)
> in the file : 
> common/usb_hub.c
> ...many possibilities to manipulate delays / max retries / force resets or whatever, even the log message: "Maybe the USB cable is bad?" is interesting ;-)...
> 
> I would consider to "force" the King of USB to read this file contents (usb_hub.c + usb.c):
> So consequently I quietly step out of the discussion again 
> and put HPS to CC :-) lol
> 


===
Mark Millard
marklmi at yahoo.com