From nobody Tue Jun 8 02:06:14 2021 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 8C24E57B887 for ; Tue, 8 Jun 2021 02:06:20 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzYWJ20LBz4vYf for ; Tue, 8 Jun 2021 02:06:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623117978; bh=Cr00l+wyQ1tqt3GxLACA5hcM3mnvOpziAW7F4DasHBo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YGKW8EEzVPzo+y6u9F8K8tNwJX2VBOVmdWKcUmTusAO57hUncXwhnWtba0/+HKQlY+nECYr2zs7E7J6Mmhbo3aS5iEVFJ/bBOrTP5xzj83FHSXzBdkRGhr66z52NItoj7jEC+oIjADESGppRun+mS1+iLHy3MMpRmiw/53HCeIAh1m8QvxrEu5QkmU0boCXQiwbxgKs2RXn8j/jvBRwWkitnshHwG+tY9TxWgGWCiAQ5kU6t4Lt9dM66bCTwG48IsnQ2YyuLLT1ZFeR5BKhoXE7NwwvM3WVlmdUwtK7Wgc+ibLNIc6hvkS4HWm8vs5g53DzIwnp0xCBhY0kkCNE2hQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623117978; bh=tsNn3GK41ZGH7Zcw1pvHoOPkHtkvE3p/logn9lnpCu5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qbsGs3ZMWU02Oln7HQJ4bmzJDLqUgD4eWdzrFALuSBbd/b0mETBKlufCsPpMPueMNzuuxergQBj1sXnNNiWqa0/HdK2cBRax8RdAJWl2EOUR0Yog+nLAy/RP0xyuzswRayIqiPiU9b0yrlAXBb2R7C88WT94jP1BS2Iy1UyZP4rqV8L5hqwHSCtBn3SoL4Xr73gw77nn+Y24VVArux40RyeI/AWDo2G3BsKOnwOgmLYRNGLW5x4ElBHR06017b0RtayuK1YA3nVz77bNYSyqA6geiQJ24EMk2wE8jNv8XHiwzKaQA5J3ybbmBll07wGVa5L3OpxIquvO0GLm1+KHhQ== X-YMail-OSG: nZMxIfEVM1mG4N6u2plAozL3OegrD08AThLXTLggTWr0QWlTg8dOTDJ8N_CeYGP EOErXs96F3xLrXhX7.ojpwAqoiZNy79TUDeUoAFECdorGYH38P42NBMGH_GQ7AOz2xqS95x6zt7c HIzWhOHv9LcdTw5FPw6X7PbgZFILE.UTtjuDl460HZBuUXsMV3RzfiU2sNh0qdwyBlQgdmpQZEOH NEt17heqWsSxMGWckie4nETRWdEok6eWc1OfhMCUERWEWBHGIJC_Y5Yg8v8hIAIIpYc3BcSgpAzl MWdTZg0xQV0whSqr3l_5oVZKgG8gYfcHGwp7z5se3JKxl7LEqi9prYA3mS93Jk83fa.cWBixwem0 ssSBXMIEGqtCfxdDbxfNznkZuCnkPpa6n4rl4yNwt4epYeNlsGDh5vq66mRSjJ7RFqpqeaCoEfdv YNIa7eTBoRMyK1HTWF7_7_7u2W4_m8HUsHkrfjBzM7AX7ulwJKzbYbUuxYUrbdZrzKUCkvvounfl irTGOge9NaOAV8dNcPbFpnun2pdasJkeUvzu94o54ZkDTSF0B72T9LX3TE6x6s_Q0Q4iQdgsnTKy d7FbfOnMPkXhD3pbbqD1XPkK7Bh.aXN0VDAgDmMMX6d4NpBFi1Qh3cM7RC8O8vy46._ZL54agW7d f743ET4S5EgoTeKQbr5lrGDkG91Rqc7QFcir.4uhSCqwFfXxD4rsJi2AUsa1S7SkVJAtY.AAPsnb M0F8alAYcJQPEW90L8sb4CW4.aT9zZeJYaY8JItRnC55_cRrmLxsIzywWS1HHc4uCNE26Pf9gQMl qHGxCr9T1Zs8kxM7XVHd36o6ySNWlxOjRLRl8s9zgHk6mmPYfREEieNpHOEFZhFgLW9M8bXlO6qI v8rWpysPZh5tA5NN9fNjLBmxsK50RxRRPV49iAL73T2SKXW2ZStBWAjijm6q8W3Ap77E_x2Bsw.i hR5MnSezO_ZOBajpURZDJiQnwE7uAw6Mf5Cq4eCgXQBid2wBs.VCc_gCcxSctGFPUZH4R6v.sGrp rVGOmlFvMuOGk4qEF_zUNcVGy75gpBAO8FYlH724I05a5wOR9aQaS1fEX23e7jmA7ZkYThWkal.D KdWSxhv2ZjIn92Y5ckUAZB7pD3LfRpkHkngJzZPaIbj3awbXDqRdcuh.94RDgWZ0JCUvWPr5U5AM xMeZqb9cCctG6qyFhZ61e6g4vzXxBWfIvvcyui5QdZXDB6Ph5ffma8rMM5n26gpzdXoVLN3gKOfp 83GocIy350SuRob4JYh8COvMD507JOUWWhzz6DQnn4q0eUpL1qkQkp1jgJ9CUYPHWipS2javMw2r YajMMtNnNrYphzG10BPpw.Y7ee.PH9m_NG9Uo5cj7YC0T7FlnvZAwprgBw5OZIcuCSRaMJER122w YCi4leA1iWMKHJilGRCRxiBajgvOKrtsWNm12Hj3Qb5Pr7ZX2erCBFZIe.ZgnN_wg95y5fmrkjI2 7CdcZt1ZNNbRX2V7JbbWE35EeYjw7Rrhz3Kss_Kz7VPECSH50lcExc9fC1aQC06gQGLlNInqZP.x 9ZFrwT3oq3U_XzDx7ciO9NdW1_.9yPWCfboEcIpXygUkSgzD.QQJ1F1yeTrg80CUhMp5d31ncyYT .5m8i4EsbC1fRI3y49HpL8KLAr2qLH5mGajtEyMJffdLF5VC2Mvf4flF.B9vIAOgxRJZZXPKYHDm 7apMHdC91Cg.aYd0VAspD4SgLOuUPxkDzL0y24NXJVScGu.FlFYibkFpI3_Lcv0Y6f99Z_F4jvQQ xUChR3dTAvz66aJK.LXNivs0QtdrO8W4NjPhVihg61q8mmOs6wl_t7eNRWb8qvnOs9e_HGyLo7_C VlsQkR6G2M8a1bwMaCMjYh.ZBa0LMO_CN01_WGvDnemHbcF7iz1FNXmYTNNOrkpDsjXfrxKGj5Lo 4Oox1pXfEOP3R.EDRfG4WPbbF.KH2ybFGOnVF1djIUnDdiPWikS3QZmXEQFoiCTKXhAy7lTWVbml gUzpmcN6osaa81lPqMbkeWK6nT617OvTRU6x3PTz9Sw.kZ66Tpl2hoNgHx4TCr4lBesSG0ICLLbP .ON3FRTHIdgr_DtdS30uiI5ja7wMPR.vcPhh6qgz1PfMkrOvEzf.ae2K37.9CdKMqtImITEr8Gwt m28MyfyF8jaFp6enoKWqNYuysNYmkHk6m1zs4cjAW8Vg_k4JViHq7EYKFPhalSnQN8Ks5I5NudqR 4n9uTQW6F1XtCb3eZlQ.dOI_V7CZ_WdH7gY.AzImFtTobL_O_r9ycphbc1asdRI1pM1LIGKHvXwC Tese0vRW6q6fkaVrLqbPeZPyqYryxYwyTLHiR7XcvLL7wsTBm8xDYnxFYmCXmQMx9MHcNvAOPoP3 ZbhUvAVLlUR.nmkDN0LKmCrRnmFdOaVz0mbzjgG4tQ85Va_1p5xC_lhT1lWhnotESgR.6Bdhjdy8 Or23bOQKDEY2yLwGucf3F96ZD4CeRQcCUXv8h_zmizYQYZVPTZLR2iEufSMZ3xgM3TZjm28qd X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Jun 2021 02:06:18 +0000 Received: by kubenode575.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 806012e8be4e6159e62a33ef03c69741; Tue, 08 Jun 2021 02:06:15 +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 14.0 \(3654.100.0.2.22\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210607235248.GB11184@www.zefox.net> Date: Mon, 7 Jun 2021 19:06:14 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> <20210607184016.GA11184@www.zefox.net> <20210607235248.GB11184@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4FzYWJ20LBz4vYf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-7, at 16:52, bob prohaska wrote: > On Mon, Jun 07, 2021 at 01:09:52PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2021-Jun-7, at 11:40, bob prohaska wrote: >>=20 >>> On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via = freebsd-arm wrote: >>=20 >> Looking around on the web I see reports of the: >>=20 >> Request Sense returned 02 04 01 >>=20 >> (and the matching Device NOT ready) mean that the >> problem will occur and that repeating usb start >> or usb reset again until it does not report that >> leads to things working. >>=20 >> But I've also seen other, more complete information >> indicating that there is a environment setting >> (showing an example value): >>=20 >> usb_ready_retry=3D5 >>=20 >> to set up before the usb restart (or usb start) >> command. It deals with the issue more explicitly >> for slow devices. >>=20 >> Another one is (units: msec): >>=20 >> usb_pgood_delay=3D10000 >>=20 > Presto! using editenv usb_pgood_delay prompted for input, typing 10000 > and hitting return set the value and the disk was found. Cool. > It looks like the setting can only be saved to microSD. With > no card saveenv reports > Saving Environment to FAT... Card did not respond to voltage select! > Failed (1) >=20 >=20 >=20 >> There are also device that have problems with >> large transfers and require extra protocol to >> deal with transfer problems before they will >> work again, U-Boot not doing that. >>=20 >> usb_max_blk=3D20 >>=20 >> sets a old historical value that generally >> just works for such devices form what I read. >>=20 >> I see no indication that other usb commands are >> worthwhile until one has avoided that "Request >> Sense returned 02 04 01" message for usb reset >> (a.k.a. usb start). >>=20 >> The reports of this sort of thing are not limited >> to RPi's and go back to at least 2014. >>=20 >> If I understand correctly, usb_ready_retry and >> usb_pgood_delay and usb_max_blk are part of >> normal U-Boot builds these days. But I'm not >> certain of that. >>=20 >>=20 >> I will note: >>=20 >> QUOTE >> Common USB Commands: >> - usb start: >> - usb reset: (re)starts the USB. All USB devices will be >> initialized and a device tree is build for them >> - usb tree: shows all USB devices in a tree like display >> . . . >>=20 >> Storage USB Commands: >> - usb scan: scans the USB for storage devices.The USB must be >> running for this command (usb start) >> . . . >> END QUOTE >>=20 >> Note that the wording indicates that having the tree is not >> the same as having classified the storage devices: storage >> classification is an seprate step. >>=20 >=20 > I didn't appreciate how independent u-boot's usb commands are. > Info and tree could see the disk but dev, storage and reset didn't. Looking in some actual U-Boots for other reasons, I found no "usb scan" command. usb start (the first time) and usb reset both did a scan automatically and the help description indicated that scanning explicitly. The behavior that you got, however, suggests that internally the scan is still separate (and such can be observed via some types of failures having tree information left behind but not storage or partition information). >>=20 >>> As an experiment, I tried booting with no microSD card installed at >>> all. This got confusing; u-boot still came up, apparently from the >>> USB hard drive. >>=20 >> The RPi internal code is handling the USB drive >> initially and loading the RPifirmware from the >> USB drive. That firmware is in turn loading >> U-Boot in this case. >>=20 >> It is when U-Boot tries to take over and set up >> the USB drive for its own use that things are >> having the problem. >>=20 >=20 > [regarding earlier, intermittent failures] >> But did the problem cases show: >>=20 >> Request Sense returned 02 04 01 >>=20 >> or: >>=20 >> Device NOT ready >>=20 >> ? Or were such details different? >>=20 >=20 > Not sure. When I saw that the disk wasn't detected, I waited a > few seconds and re-ran usb reset. Within a few tries the disk > was found.=20 >>=20 >=20 > It's unclear to me what changed, probably something I did, but > setting u-boot environment variable usb_pgood_delay=3D10000 seems > to have put matters right again. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)