From nobody Sat Sep 24 01:34:24 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 4MZBQM6yg4z4dRl7 for ; Sat, 24 Sep 2022 01:34:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4MZBQL5mYzz46c9 for ; Sat, 24 Sep 2022 01:34:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663983272; bh=glCJUlNK463lx3azTE7cXOdH1+Jtf5r0ePFJD78Avb8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XqH83W4QD90iFxlFcNangqtvyTJ9KZsk96hV4kSid+8WiHNhS1dUJ3Bf4iJ3V7cwPp4r3Cn59mkzNcpmg7xGvFTtTyM8/Fb+e/Bv3uMwW1gflX/oYUsc9WjAu2Lh1/YGncnKb2pNHJA1OSNwOOHHjHcGt70XVG66mBGW/zMX7i5BL2BohrRNQqtskRqwM01bPrbEVHW5ebxp1i0wlvBbabrdn3zHzRZywOUM3/7KNc74TPAalR7tm6/nbUjDWaFlBahuW0zY9oW8OK8yLYJjVTDBPaqWBs/vSbMasVbAfh0cXFBkAstXmlALtSIxLeJsJRLHRp9jdW9SpMtYHCC5XA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663983272; bh=NUY4F9AJRBvZECCUatV0DK5xNmM8VPJEXYrkz8SDF4W=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mv88Z1CskuKBqhtrkeiONvV85Orb/sE1vmMrcC7YGi98rQZarX0I1fbaEC4LeAJxsivM00AaVhkr2FCuQt8NUno/w4l/ThETwqN0WOUaf867o0qR3scSE9jePU9YFYV7NgCqrTsj++2x4HkgxTQWOz+YDNLTcB4XiXFcYAK2vKm4gCY5Z6IXhKkjY7PBAVhM52zOLYOGiMc8jtQZq8CGEwq/Ou0tYtZ+6BANlZwk/Q7mKshRSCLuHgH0vSw+cxqSym3D/cWuQ3F7xlLHrO6o0L3YVta81PZUAtzXdcXKYXoaRv2JVAqLo3/xopbyC/oOGvkWuPPcFeVNQX4pCHskbA== X-YMail-OSG: DIWpnnkVM1mx2wVu545aBgQJRTlZez5VU_pzyHb.S4LVbzS6LTY__uKsVeyHsJ5 mXkbU55h3poHjs9PzXUvEnBxETE7ekI7PtqE3EpEcl..eefxnEmaGIvfpAxrjZfd20lMqBzj1iZ9 5ZpPoJGXqtXhm_u16yCRCQWktrCCazIZa5w8YxvyodVrBAnRzGDzUDW8rSgXPD0oc0CbFBZNkEKg ypj6sRPJFTRukcjFGlHUGi1f3_NoIiOcYXXn.Z0yEIMrbklRTFCOzi4SaUQ91CZdLIWBShqqAxnP Yu5C4IfPHTSHV_lMCYoPbuQwZmNoO_douH8pDNIM.E1L0t3KLY14FrgvQ68BfEfDhSSwqccur0fw MKLheO_fUqDDQkvx1kV.IxFVxNGiR5idHcMJDMIn6McSrNu_qc8IgvEo1du40P9_LHcDZ.jzAV5w oV.8Va837OllaPEqlyAzuIQhGl3DTUh8kRSXwN3h2JBWoE01uaBOPT1E.EPMggNieAyEMe1.y74w csHw5ZeDTODhO1UhlbYe_tnnb.gG9xUTvESYNAYkfNjkz0NjVeBGmK.wkXnu4JaG1uRKQxx_scui Hvn_WNsTuA1Mo3_KPd.yYvToB22x5yeJOWe.s3cfxH3l.zlmK_Lkm9MGwVsM7IYXDpHIEaXKteA9 Euc2bFE.Ufmb_2JsRqsFIku6jdJVIBJ2FowXiFavvYEgl916GNa0cUusy1hUt33QNG7S3XTJZemE 9o3s_mC9PSKq_C0jkyoP0PIzjcgul4Y6HAbudAdJDepnW9B07TJzMMhJnXaOOt4I7w5OO9IyeA21 LbOMy8cRxvL0clAHL0LRwF3tbPck2EX0HrELoBLnwpXv9kwkDlJtyfBaaUMAlAxTzgf95_nz2kcn tJ9umZC3Y8yldLSURSyO2xExwLpmCSeG_TG.C0yit3JNJjH.zTNK33Zntw39p.dd0k8z7Q8BYTKF QK6Ffinms7x782Yy7e9G0h_p_XaHohS58ZjSKFyhVDtvdUxOFzzbBgCLNKhJ4UF6IQRcBxH9rG2I oCuUTQL7asiiSTSzEL4qCQxx7JS6dPmpyf.L_NFxsNLzDhPDXd8tjsO_hiI2m2j38z1fXUQj.olO GlmkruCFQ.0neRSARIZdf_gnvaePyt3CKYxXTqO_wHkDqiJQtonr749goRkBbKPMEIqLPtxiOZLb AuM96t0tDLNbvy81Ci4kaF_SbitlTiAiq1VOYab.67LatUmF_XDm9mTTpzZPmHez4XLdN7xZQSYD t.oTClja4KJiWLb7g4o2_rsRSuTxVbyiP5Lpvyp3u0Hc_6QvWQ9TcsBkagcp.PcymvrJ2ne_N7dz y7twAZTWSk_fg9steu9QIKtuaxAal_1xzcm5.GMLn6cCqIE9IPRWyry6ViD1Oju7Spi6RJQGAjAp sJmVEuSsm58vBSQhV9bQ3IJB54IHdwF4WuP4PeeGAu4QggxZ18hHJPJBKJPCq37EVLWI2CrC4nW8 LUDP5oMQnabFyABsaIzdbZveGQq3friSzoxQtfeTIe9FrDvtcmsQuauxI.RilYNaIUuBOpMQ8Dvt H5tVxM5SbhkPiuKFv.lCyO71gjwrLElr_mQfZCwvpZgurHvneT.2OYtYo0cQ9nyLMPxq_EWsgB0i vwawoGukrhyr2e2kx1CV1xPWsqhgr1pnyIHtWUt2RoFAUGHqhoRXVgTptb28Y9m7Ktdq2d169phl 0I7L5W4peZE2HrSatiM8Ark4iKvmrlfnHdcpL7mKpmG6iz3PVLOdnUF4mA6__p5QoE3ZYVvo.g_y 8x_0GBXwWG7kbRdZ_Y9mG_ykEZcBMAQmpW1razVuohyHXd.ZDnlIi2TWiF7lblv7OWpksEte4ZhR 8t6QlkTemgA5BFYfUMsfSwpWX.LWfRO3mtViDQAm4Y1ZwHFlPtt8LBHzSzOHn55o7qWh1TR3ROhU 4nTqibLGPbr1nof80QWPGs8q7tdMEdthVsi46.B3176hbvlc3d8lLWMRph4up5SK1O85WSJS_c7B 1pLHK_Veko5BYVBjQNBNMQtel3.QCvclyiB8RsU8mmAmk.bAToHOcVoAQEoiHeQ4emBaXSJ8JZFR NXfmSYkHafQ9uhVGSOQKDchisCNpZCnKdidyReJlbstuS6T06l_0LZUAIXVjeOVJ6ZFc3rLisvJB xRg2Al13DXhVdz3QyyizucLjd59v3O2fXJn7XuXRwcAJnsX.vB4VgQhKz6BMYdrQKEEMVkLE7RI1 lvrCNdsZXogHBOXy7teaIS7QOkZvhOyM8jkoBNJwfocSzTCXXvVredURzu2RZgC.anzHtyfRnCFR 1 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 24 Sep 2022 01:34:32 +0000 Received: by hermes--production-bf1-759bcdd488-njfbl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b89db906b0bee40741ca8c37502ce5f3; Sat, 24 Sep 2022 01:34:27 +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 From: Mark Millard In-Reply-To: Date: Fri, 23 Sep 2022 18:34:24 -0700 Cc: bob prohaska , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MZBQL5mYzz46c9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=XqH83W4Q; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; 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.84: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 16:52, Hans Petter Selasky 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