Re: U-boot on RPI3, sees disk but won't boot it [devnum/port paths vs. U-Boot address numbering]

On 2022-Sep-23, at 18:34, Mark Millard <[email protected]> wrote:

> On 2022-Sep-23, at 16:52, Hans Petter Selasky <[email protected]> wrote:
> 
>> On 9/23/22 04:11, Mark Millard wrote:
>>> 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.
>> 
>> FYI
>> 
>> LibUSB defines :
>> 
>>    int libusb_get_port_numbers(libusb_device *dev, uint8_t *buf, uint8_t
>>    bufsize) Stores, in the buffer buf of size bufsize, the list of all port
>>    numbers from root for the device dev.
>> 
>> Which gives you are more or less constant path.
> 
> You may not want to spend the effort educate me, as I've no
> detailed knowledge in the area to relay on. Also, I've no
> clue if U-Boot uses the routine (or related ones).
> 
> The original context here was a RPi3B, so USB2 ports on the
> RPi3B itself, not USB3+ (in case it matters). Ignoring that
> for the below . . .
> 
> Looking up the routine at:
> 
> https://libusb.sourceforge.io/api-1.0/group__libusb__dev.html#details
> 
> I see the description:
> 
> Get the list of all port numbers from root for the specified device.
> 
> where:
> 
> Parameters are:
> dev			a device 
> port_numbers		the array that should contain the port numbers 
> port_numbers_len	the maximum length of the array. As per the USB 3.0 specs,
> 			the current maximum limit for the depth is 7. 
> 
> Returns is:
> the number of elements filled
> LIBUSB_ERROR_OVERFLOW if the array is too small
> 
> But the original device trees reported showed:
> (unsure how well the text and its whitespace
> will go through in the trees)
> 
> 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)
> 
> without rearranging any connections, if I understand
> right.
> 
> Both "USB device tree"s have:
> 
> 1's device (a hub) contains 2 directly.
> 2's device contains 3, 4, and 5 directly.
> 
> But the correspondence with the devices
> associated with 3, 4, 5 is not the same.
> 
> I do not see anything in the libusb_get_port_numbers
> material that would imply they should be the same.
> Any permutation for the correspondence of the 3
> devices relative to the numbers 3, 4, and 5 appears
> to be valid, even if it varies from power up to
> power up (for example). Just the set of numbers in
> the array {3,4,5} is observed to be invariant as I
> understand.
> 
> May be something in the USB 3.0(?) specifications
> nails down such relationships. But if it does, then
> "2" is not behaving correctly if the numbers 3,4,5 are
> port numbers.
> 
> Another possibility is that the numbering in the two
> "USB device tree"s is not technically the port numbers
> but some other form of id-number, possibly U-Boot
> invented even.

I see from the debug output from the investigation
going on that that last is the case. Something
like:

devnum=2 port=4: USB dev found

ends up with something like a:

set address 3

and the "usb tree" is showing these assigned addresses.
The order of the devnum/port events varies and the
set address numbers increase as they happen, providing
a flat indexing instead of nested. But addresses need
not be stable from power-up to power-up, for example.
devnum/port paths are stable from what I can tell.

It does not appear that normal U-Boot usb commands
generally indicate the devnum/port nested path
numbering. Instead showing the flat addresses that have
been dynamically assigned.


===
Mark Millard
marklmi at yahoo.com