Date: Fri, 30 Sep 2022 14:35:29 -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 [devnum/port paths vs. U-Boot address numbering] Message-ID: <06FAA67B-D2A2-4899-8341-A019DE7F5EBC@yahoo.com> In-Reply-To: <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com> 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> <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-23, at 18:34, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Sep-23, at 16:52, Hans Petter Selasky <hps@selasky.org> wrote: >=20 >> 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. >=20 > 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). >=20 > 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 . . . >=20 > Looking up the routine at: >=20 > https://libusb.sourceforge.io/api-1.0/group__libusb__dev.html#details >=20 > I see the description: >=20 > Get the list of all port numbers from root for the specified device. >=20 > where: >=20 > 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 >=20 > Returns is: > the number of elements filled > LIBUSB_ERROR_OVERFLOW if the array is too small >=20 > But the original device trees reported showed: > (unsure how well the text and its whitespace > will go through in the trees) >=20 > 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 >=20 > and: >=20 > 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) >=20 > without rearranging any connections, if I understand > right. >=20 > Both "USB device tree"s have: >=20 > 1's device (a hub) contains 2 directly. > 2's device contains 3, 4, and 5 directly. >=20 > But the correspondence with the devices > associated with 3, 4, 5 is not the same. >=20 > 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. >=20 > 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. >=20 > 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=3D2 port=3D4: 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. =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?06FAA67B-D2A2-4899-8341-A019DE7F5EBC>