From nobody Fri Sep 30 21:35:29 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MfNnR6XLTz4cx6C for ; Fri, 30 Sep 2022 21:35:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MfNnQ43Z6z3fDP for ; Fri, 30 Sep 2022 21:35:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664573736; bh=NAhoEO0z3p5VlRS5EImrxiLwEc7WLFEBjqN2PrBEijw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RFZLxElXX6RhxueZ51dRK1rnswymQGsc5nphpLa+NeORyUf4PS8xREkXzFOrmQGPTXDEm3CbxGvQgfzpUt+LEAN005Pm8/Nv0poh+97yIRjtBygyH6txV1G6eNES+TpQBLV2KptYQTg9iECi60OdYzJbyWDNa9E0//TADGlBoe7BlIgvxekDolyM/T0hA5yyfsyTU0CceMt9wePxH+UZOHBP0fZHJD+7k0pORSE9KJz4Cps8qlSNLkS/ce0aDpgsY+bqMR3YiLYYz7JRZigNv2S3b/8H9ayBjxdudsEH0AGhmN6NmeQKwoQnpOQxr4BmzIitoNVhYWwiP0nb6uAfzQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664573736; bh=UW7OhpqPT5LVd7cuQfrRZ7hx9bC8ymQgg/RRfy8SIu4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ohl8Ck37PzFBSbiVACF6EQfyhcde0ZJKa0gMJuONEFffWF55osaK3+MdL/oUeG+B9RlVhIXDra2ig2qanR9XnU0H1bhMJyF8BSc/RMlKU+t4/nOdasfPL+KHKNGCMzcG/OFh6Xm0YbD1VGdrmUAEeotMzmE7J9j8NimzyLKD9EOKkZuWQY8F4w7YYngjXNeRMw6GaILYPV5LbDK9EQ3S3a4CyZA8x5wasNPP7Y+77fMhVtcr60Ib/69PIv3kIVWchtjyqL6HjIgwludCWx0kIB+a5ZGyO4j6aB7gd56NzU1SaslHQ+ydQMngO5uUdpDFPxp3yMWTCoQrSA8jE/MpFA== X-YMail-OSG: qZ3bwgYVM1mSItRRSGcPl9lG_4IV2Hf0URcUKEDHNIQ7tuRuyUBZa7FyMGvZOSA 3mo8scQ2FPhMN8YJBg8NSzmdz1b49a5cRYxFMacOXLN0.waxrTzsr260lYgsoqvJ0qkeKkWrLKVQ rfZgq_8hJQ4YLG9lY2U3_PDppkovfW_C92lL.h9sfeOXenPHsOjJAfqwd7MorsBuIO_gVIF0.jCy AEYnMWXhUsXn4nHJIDoq4EDnHKW1Yjwk2glSe.w9.6fR7kDcwlSjYFKE0x3SD_NmYEIYw2ilAcQn MWmyZjoSqPVQgYksMmrWRAeYX6tm5gylbAalIPnw.1bdPkcqYxFmCjwJal_A_tZmZ.eiJSFrx59K cgz.OVuEcuY8JKuXqAqPOwOF2uXoTGhkhw0w_Smy6aMpY9WoxhdRGFtjs8iqp.ZhhiniNDoBD8OO W0kPFqNzPFhq4gqBrjOk8MfTy2S_pRxYFY4Ns9_ytcAp2mbcwbnKGBlbgPuvsQL3uRKi1ekTvwRk Q6Rzg7KTtuH0LdEc4vXgOIwkWKObfb1amdpTwZK40Qq220SLEKj.sDHkmbMbc7pFajc04x1YQ5yr 23bU9gSF3BDVWb8.1yTdcBgz1.65BjHLBNJC7Q60UGTtx03q6cNFEYpSOCGeybUnoM1W2PRGaNwe I1Hg_fqi5OPJZfa7EXAOO5pnYmP8WGaNNdrd8VtpMRunx_S_C_W58Q__UWdn3WEEetqZ2cPT4buh xPCf6le5ThsKvle2OrFQttxNmGKJhEcE3kfERX6j9vHy91500_868n3vp7JEMi4zWweQb3zup6Wd HvU5RNe3T4nkOVmbIL7aoCumi5o1ip1iOTlTAM_iZmpCmGuWu1aEiBseAHSvZuG.Ch0kxcl71DKA SaxizoZRx7j8nly5XOdDYDqwqol5oYpXgsBAjT7kpijdZ_JWinNvWuY5u.fHaDQuZPvwlFRgP6sx oVRjJaDoUhQugAxHG4nAAnY2q.ClAzrstOtlEr_3nUXLSBjQZSF68FH44kmsR5fIrNKloE4ai9sp MRjYIs.dyQCLuXa9g5fObfw9J9aAg2YDmFGWVlkBh0iswFndvx7.GgGkEWMsR2lU5afmNM3KlQrS v37xY9N79hccjNvuF5O9zpRvTdGlxesJBHehDWs0CSMuLf_n1XQRrGcHa0V.1z.oSb8yfcPPs2Ic OSkMG72GRMo_8kfOcy7YktxF99Zpewyg_gIpgbcHkHSxCEPDVAF_QvDD4gQhl9xZbUICypg1rgof a44UAhNi31PxNJX7tt5KOBxY0qd2FiQ5e6.z2eH7cRhJr4sn7T3a0Ddxq2NwXtILMEI3JL5i9yQJ HPYZkXFdv.JOscUHyhGlGjIBV_5_1ckoUMxfF34Z2AtPHMicbvMiBl01KWMLw41d4vjBanj0ZF5J Iyj9ydlVSkGlW6cWPyZDpgW6fWrMQRFkSge24fOKijHuzqXNY4CFzhx9f8g5Bq.V3NeSBnL8skT1 cwgRKkCcKBO.FkF_MUCGSi5MsfrtTZiNn3IYzIvUseMK86l9jm8Q2DR8jAOr6al.ItcZsb0FeMtG krzq9nvLeZ4thjs0eGjE4id1C4YU7k30it9_vtZ5TCzXpNA2QaTnw7KUEXf.vlQXn3fCmZEeARyJ APqBf8jf4AASqPUWhJz8s1Nw7q9EJOhdUcbCiTvm75U_Zi4pwMWoL6lozNAYD1it_.3EpYmGEUfj 36kDjZWdp9J8Q3NxsGX4DuKb.38yJ4KqbCFVJPCAmF6adxhaVN8c_QR4p4O8__yhCTGYJ5wnDM74 L_4dAboLYUe44_Bvt_kh3UDdRc_dKTtx6MXoFsMQjPz8W1BsOxMXbS6FhPrag1rTF7HSrvqvGEZ0 8l71ICWM02zo.Eptp115X8R0Hh0mcKBSmy.yfsBCFVQGKBUv8lIay4WEpVPBoLWSnqkLs9zmuhkF o_sy9_WwZp.aD.sQvSdcDYoDBpD56dXgoS2IWVRCh0QA9mH9UdnAYwYfBwB_1Rd9iQGZC5BeyjFC wS8REAWDC5Pp3xFPMJYNOBP3T3n5TD2yX7._VA3OgcFQnt7dPrHmKtC3Ccce65WgOUA7SV91YUh8 HKePBhMbF0Ujz7A9MK82XorV.HXmRPT_VhYM6xl5LKT0oZBpG5hZD9dnP0P7zHNqTdKMavartXWB fBZb.3bMuUaOaaBrYoZune4u65nCyTVjbQMdLL7IQ7eiVVT.UtyBaFjJAyEH_s.qy4IzglA_Pk2V rzoy6XwApcK5331ZS6qZPxfpxN8w1LpM0NtmPW1UhEJtU6BrNHThCsqosNUmy2_xQFgilH6g_RwO kpKys8Hzt X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 21:35:36 +0000 Received: by hermes--production-ne1-6944b4579f-wdnx4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3491391e26980908b6a7927f6315c531; Fri, 30 Sep 2022 21:35:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: U-boot on RPI3, sees disk but won't boot it [devnum/port paths vs. U-Boot address numbering] From: Mark Millard In-Reply-To: <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com> Date: Fri, 30 Sep 2022 14:35:29 -0700 Cc: bob prohaska , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <06FAA67B-D2A2-4899-8341-A019DE7F5EBC@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> <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MfNnQ43Z6z3fDP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=RFZLxElX; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.46 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.959]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Sep-23, at 18:34, Mark Millard wrote: > On 2022-Sep-23, at 16:52, Hans Petter Selasky 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