Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Sep 2022 18:34:24 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        bob prohaska <fbsd@www.zefox.net>, freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: U-boot on RPI3, sees disk but won't boot it
Message-ID:  <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com>
In-Reply-To: <ba7af015-613a-0530-9a79-628a55bebc42@selasky.org>
References:  <20220919221553.GA33878@www.zefox.net> <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> <20220921154240.GA37735@www.zefox.net> <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com> <20220921175026.GA45144@www.zefox.net> <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com> <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com> <20220922014500.GA46697@www.zefox.net> <280D9065-A158-4E52-AA18-CA2CB1C247AC@yahoo.com> <ba7af015-613a-0530-9a79-628a55bebc42@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-23, at 16:52, Hans Petter Selasky <hps@selasky.org> 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.
>=20
> FYI
>=20
> LibUSB defines :
>=20
>     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.
>=20
> 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=20
port_numbers		the array that should contain the port numbers=20=

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.=20

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=20
 |
 +-2  Hub (480 Mb/s, 2mA)
   |
   +-3  Vendor specific (12 Mb/s, 90mA)
   |    FTDI FT232R USB UART AM00KE3E
   | =20
   +-4  Vendor specific (480 Mb/s, 2mA)
   | =20
   +-5  Hub (480 Mb/s, 100mA)
     |  GenesysLogic USB2.1 Hub=20
     |
     +-6  Mass Storage (480 Mb/s, 500mA)
          JMicron =20

and:

USB device tree:
 1  Hub (480 Mb/s, 0mA)
 |   U-Boot Root Hub=20
 |
 +-2  Hub (480 Mb/s, 2mA)
   |
   +-3  Hub (480 Mb/s, 100mA)
   | |  GenesysLogic USB2.1 Hub=20
   | |
   | +-6  Mass Storage (480 Mb/s, 500mA)
   |      JMicron SABRENT 000000000000A
   |   =20
   +-4  Vendor specific (12 Mb/s, 90mA)
   |    FTDI FT232R USB UART AM00KE3E
   | =20
   +-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.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A773F91-BC73-49BA-BB7E-65EC00B954DB>