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

On 2022-Sep-30, at 12:02, Klaus Küchemann <[email protected]> wrote:

> Am 30.09.2022 um 20:36 schrieb Mark Millard <[email protected]>:
>> 
>> Which "the"? The Hub in question is internal to the
>> RPi3B. It also shows up on my RPi3B with no external
>> hubs involved. (But I've never had the failure mode
>> occur.)
>> 
>> Manufacturer 
>> Product      U-Boot Root Hub
>> SerialNumber 
>> bind node usb1@1
>> 
>> It is a hub with 5 ports, one associated with the
>> EtherNet port and 4 for plugging things in. Or,
>> that is my understanding.

That description is a little abbreviated, skipping
a stage of hub. From the RPi3B that I have access
to, with only a couple of USB ports with devices
plugged in (so some ports not showing):

U-Boot> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub 
  |
  +-2  Hub (480 Mb/s, 2mA)
    |
    +-3  Vendor specific (480 Mb/s, 2mA)
    |  
    +-4  Mass Storage (480 Mb/s, 500mA)
         Samsung PSSD T7 Touch ***REPLACED***

Bob had reported seeing:

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  

and:

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)

that are the same up to permuting which device
goes with which of 3,4,5. (The 3,4,5 being the
numbers directly under 2 is stable.)

> :-), I started reading the discussion from the beginning because I missed the Hub-manufacturer in the logs,
> Now I know it’s the internal, thanks for Info .
> I  was absolutely sure from the beginning that this is a 3b-power-issue (regulator or whatever)…
> I guess you also wrote that.

I treat it as a possibility. I'm not aware of a
good way to get solid evidence indicating one
way vs. the other.

> Since my lowest model is 3b+, I never turned on any RPI during this discussion.
> 
>> 
>> I've little clue what would interfere with its
>> operation in this specific way.
> 
> From reading the logs  we end up in line 377 of common/usb_hub.c :
> 'cannot reset port‘
> The comment beginning in line 305 indicates that perhaps more attempts of a reset 
> could work around mysterious power or disconnect issues( although for nVidia not rpi).
> So by guessing I would say, a code injection of reset retries could perhaps help,

FYI: Bob is using my rpi.h patch that enables my
devices. It has a usb_ready_retry in addition to
the usb_pgood_delay:

# more /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h 
--- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
  	ENV_DEVICE_SETTINGS \
  	ENV_DFU_SETTINGS \
  	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
  	BOOTENV
  
  

I've never checked if my booting would by just as
reliable without the usb_ready_retry . Both usb_*'s
are from one suggestion I found on the web and I did
not explore further once booting worked well.

> I would ask a long year known USB-expert if it’s worth to try hacking usb_hub.c 
> but it’s better not to call his name so loud again :-) …

HPS is aware of this issue and of the exchange, and
has commented earlier on --about how port numbering
works (at least in one particular library).

I'm also not sure that Bob would want to maintain
his own patching for sysutils/u-boot-rpi-arm64 as
it progresses U-Boot versions over time. If all
potential changes were not up-streamable, I do not
know what Bob would choose to do.


===
Mark Millard
marklmi at yahoo.com