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

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On 2022-Sep-30, at 09:40, Klaus Küchemann <[email protected]> wrote:


>> Am 30.09.2022 um 02:27 schrieb bob prohaska <[email protected]>:
>> ……
>> .
>> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.