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

On 2022-Sep-29, at 00:18, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Sep-28, at 23:59, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On 2022-Sep-28, at 22:41, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> I've put the full output from a failed (no storage
>>> device found) attempt at
>>> http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-debug-log
>>> 
>>> The obvious error message is:
>>> Cannot enable port 1 after 5 retries, disabling port.
>>> Nothing about device 152d.
>> 
>> The RPi3B has 5 USB ports for devices, one being internal
>> that is tied to the EtherNet port if I remember correctly.
>> It also has a root hub,6 six overall.
>> 
>> Your failure log is about failing to get the root
>> hub working --which in turn blocks all the other
>> ports form being accessible.
>> 
>>> Tomorrow I'll try to capture a complete log of a 
>>> successful boot for comparison. The boot success
>>> rate is so far is 7 in 9 or 10, depending on how
>>> one counts. 
>> 
>> I'd also recommend recording a bunch of failures
>> and seeing what wort of variety exists in the
>> details of them.
>> 
>> FYI: My log shows a Root Hub Port 1 status
>> sequence: 511, 511, 503. Yours: 311, 311,
>> (5 times:) 301. So it looks like what the
>> status encoding is and what the implications
>> are.
> 
> Accidental send. Continuing. . .
> 
> The output uses %x (so: hexadecimal). For reference:
> 
> ./include/usb_defs.h:#define USB_PORT_STAT_CONNECTION    0x0001
> ./include/usb_defs.h:#define USB_PORT_STAT_ENABLE        0x0002
> ./include/usb_defs.h:#define USB_PORT_STAT_SUSPEND       0x0004
> ./include/usb_defs.h:#define USB_PORT_STAT_OVERCURRENT   0x0008
> ./include/usb_defs.h:#define USB_PORT_STAT_RESET         0x0010
> ./include/usb_defs.h:#define USB_PORT_STAT_POWER         0x0100
> ./include/usb_defs.h:#define USB_PORT_STAT_LOW_SPEED     0x0200
> ./include/usb_defs.h:#define USB_PORT_STAT_HIGH_SPEED    0x0400 /* support for EHCI */
> ./include/usb_defs.h:#define USB_PORT_STAT_SUPER_SPEED   0x0600 /* faking support to XHCI */
> ./include/usb_defs.h:#define USB_PORT_STAT_SPEED_MASK   \
> ./include/usb_defs.h:   (USB_PORT_STAT_LOW_SPEED | USB_PORT_STAT_HIGH_SPEED)
> ./include/usb_defs.h:#define USB_SS_PORT_STAT_MASK              (USB_PORT_STAT_CONNECTION | \
> ./include/usb_defs.h:                                    USB_PORT_STAT_ENABLE | \
> ./include/usb_defs.h:                                    USB_PORT_STAT_OVERCURRENT | \
> ./include/usb_defs.h:                                    USB_PORT_STAT_RESET)
> ./include/usb_defs.h:#define USB_PORT_STAT_C_CONNECTION  0x0001
> ./include/usb_defs.h:#define USB_PORT_STAT_C_ENABLE      0x0002
> ./include/usb_defs.h:#define USB_PORT_STAT_C_SUSPEND     0x0004
> ./include/usb_defs.h:#define USB_PORT_STAT_C_OVERCURRENT 0x0008
> ./include/usb_defs.h:#define USB_PORT_STAT_C_RESET       0x0010
> 
> Note: USB_PORT_STAT_C_* is for port status change information.
> 
> 0x311 and 0x301 indicate USB_PORT_STAT_LOW_SPEED instead of
> USB_PORT_STAT_HIGH_SPEED. They also indicate lack of
> USB_PORT_STAT_ENABLE.


As for what happens just before each of the 4 log
file's "0 Storage Device(s) found", all the
examples are the same. For:

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

it ends up with the portstatus sequence of values:

311, 311, (5 times, 4 from retries:) 301

instead of what it gets when it later gets "1
Storage Device(s) found":

511, 511, 503

So no other port or device is found when it ends
up with "0 Storage Device(s) found".

311:	 USB_PORT_STAT_LOW_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_RESET
	|USB_PORT_STAT_CONNECTION

301:	 USB_PORT_STAT_LOW_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_CONNECTION

511:	 USB_PORT_STAT_HIGH_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_RESET
	|USB_PORT_STAT_CONNECTION

503:	 USB_PORT_STAT_HIGH_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_ENABLE
	|USB_PORT_STAT_CONNECTION

I've no clue what makes the distinction happen
on/for "U-Boot Root Hub". Nor does it looks
likely that I'd figure such out.

===
Mark Millard
marklmi at yahoo.com