From nobody Fri Sep 30 04:51:31 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 4MdyVz74FCz4V1JP for ; Fri, 30 Sep 2022 04:51:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 4MdyVz0WTdz3sjX for ; Fri, 30 Sep 2022 04:51:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664513496; bh=m50Uis0CW1IlML3uSmDiWJaQ3gIQRiOYvIO3CAmmqts=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bFcRbbQ1ou2OZVGKOMgAfgOBcwIaLR2UXcMflv/E9eTX1zZCiRom8nPY86jCsUuinDk38eHe/jcLNl0xWYBMHyheH5xFQ8r92OnT6pQXyNqstj2BBEcv4enh8eV1CcYiEXFWhmm4bsxahtbiVC5V/jyn1pd3N1YsPRBHdVF/XrFP1pSe727j5T1fPxLEY9YWkFyOlVa23tZ2ltvgZxnZ2VuwfO701g9u2LxqC9iaJBQL0+18LhmHMjb1Y5Sf07Yfq76/QsbTkUDrTBQMkvvJBLauUtlnNhDvjrpG3hM7PteKt0JOqNGIvFFARYNVqv4wNPq2UrL0eUe5fsI18+pLRw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664513496; bh=QZtPhdQ2iOykevIqQGyiK86unJWFG7iKBOxY1DbWtcL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OAi1KKlwzZVCPXU/g3KUbXzWHW6fLQuuWS3TGNP66r2ls1YUnKLVW+eA9Bio9wtz9piTakglizf9LHuHCMedrwFCeW+2Y3nWSBsJOgp63mSCsg22l6LkQntJH8SXAk7fwwcxvvUvQbdJFmL+bywVTK2Ujf20EvYCovO3/KJBCmBPBbY2FLEubLz+qaFBw4Nb/xijizhd62aN+2CM0Se5DHr+UEJzJjzKV2DLhi/usnK5NzoWbKWRe7sJsFz42QCs4CBo8ABwG9QbswAyKMyG/vOuP55FU+uwpAnVlFZgVq3boUpW2ccMqqaWtfB+ZQKGBs/bjap74s2J3zPPa3FHJw== X-YMail-OSG: NruW3qcVM1k5rvXDiEDxtWEgKejHOYnY3lk1uSbZ3FFOqCcRb11Frtjfbi3jhMe ejCmA5PUJRW3zKqvxA1GoWKt536tSDClyM47Ae_JTHR5jbCNFh.PDYE2t50z9T6946JWIKriBSMV .TmHMljsM4_ssxbyUo_GbNW2eUVQJhoNgwq4WQsoy0PsR8KqwEuY31eRevXgeVj9PVWklB1P07Uw 1fN_XKeoOMvcOzFW4.BcaIAeomjlJ59zi.wDDf4mAxg7WFmLO3yxZA_jO4ssIbthgOGhCtJGKdOM Sv33m8jsqRT.FFcyl6lnvpIPuhVKfXBsS2tg8deGmWTGJKTlI__6uXUTAQ4lCi1DNXZiLOZ_Pa6T cPunSj3o0xxS2kBBKhL4A1YTnDJ0Q.VZKBVGVj_6xjKE.b1p5LcZEt9ITCkTWO7X_Bw2NcTIoi.0 6f4qlm7F25g4CsQb8NCjyZjqms.UVLSAkkOOB7jmi2.WtgirHOGuBY074f.WZoWbR2i7pwlJEV.N cRUjO7BTeQDNkCuaMW2l2CuSDlr9PsDd.zCYfTmKXVj_wAbw9xURAS9QNRabKuVyJagO2qzlU4.Y 2LfaSgGpEWq0k2kQ57EqcaXkdnT526ArutkvIEjXVIkqlahdDRFF6AEl5CT9ZGGiJnBBACn.Hyvm JF0wS6YTLApTkQwBRiuJ3Zvxuitw2TSiD9elE4dOci4Y6EJDtccqx11NrXXq8ul.RZ3f3BGF0pg8 n.kn51S3gd8bC8qOV2SX5Pf7WzbwoFmcRptoWDWYXojtRKAZESVk66LFgeagFXeBOeYHWyeK5cat 02AnlpNHF9EY20TkxaXXPNwlUZwMiOjd0hviQhNvddqwazZp0e7GVft4HMD0Z7c9amxXEFQmB973 i08Pn5mSnBbzNN6N.DwExYFahYWAIqb0rDNBnN9WlPbmrASJsdPXDoVEbm9i8Wi.JLGGo3a528ZX 9QzgEStOdrRM2f7WjzNH3azQuYrZk_iSzA7FwCB2_wwaoK7SgJ7GSY0vFkMKgXediZEWVXN4GUCR uTVw9X3tJX1Ih0nSUUsKT5AgfKhuZ8To9a.sQa.Z3MgYqMCRDwrdR6WraonOTDokeKE_4Vnv76UV 6EAXJSNu7j_KgI4zh3lzemGD3g02rEFuw.q_JhWQIcneVXDoJo.12f8ykoF3n1HmEFkuObScvps6 Fbytr3EOcAYYOa6iAo3kHWwmVRiMob4ElwNOiVyEIzbwzJNp6cGF0Wm5USP.B4g5DBpusmvL1JEG qWbTuEdGrKnrV_VgomZnV.uXPTsdur8MTODRXCB.tnXpVecjIpO7JpjaN08fu_abTNNHQzChiFk7 0Fa0dOnCCKV_jU0he1lBUy4HDJp.ujfEj8ikY3jF.CO6HEAw9BmlVjrvaTk.WG3Ww6YgmSaa6MsL IhQLPIePL46uPPdnjyBiquJfx2Cl2VF5wm8DbUhDmoDQdNFADLNmVpS_ZBEZtGyWS681CUdLwFPu ImWjNFCLHXOiiIFjcEmpDkVJnHMZEExzbNAo0Dr3BvbPuhCLhOuxDlYIoyisBn8l0ri70YdN.6oq HkTntBBTmann53mWRvSpUNqar2B95rIVnx67rC7_ZuQ6ZpAkuuE9WWooIT2sy45Wj3vyYxT4xJ.k VSs3Ykt1NQHBFR37kpeHaHO_2nFvm5_SWpQ8fedn4DnHdezx10mURmVWx4rQwImiyzjRdF8aUDwu 3GBtlPRLPEzc7wVUHESaq7pj.VyAqqzOJQWUX0f4rfFEydl70ip_mGtfhTRCK7j44npFx7_M4hNn TFHC9ATIwhE7HKnv_FQAib6b0c2Sb1KtqpLEPVLyPtbxrpLBbnIRz1Alas36ZsSqmAH2xB.lVQFl qxSGhs63JHPyyLXaMQAZpknYqq6zodUmjN.IYDSubdzxa2HFjZsOYYno3pxtQKEFARg.fKJrUczN siAl5wFVfrAWidijnIlNXxhvzTESEDPle5A4vxjp7P9Lz6ad9LoOCt7_Pgx8TBAsmEUHDj9O6nPp 2ZKxOuc0KQoFHInUm.8O5qiL5sxuBVnUGcZ8pc33Bg2pK6cSj195AZ44zX.J11mDqWSM6fWrJFc6 2O9Cphdp3scL0mYYFY5I0luIuNyZB9LzOSp4sQ8866Nl_94WxDe465c_1DQ2kO1.GjRE3ePLuJtk pPlF2DD_rf1.zLpxn5z4N9dE5ZgC9Egr5JMuURydg4MLbvHjUzE9NV.izM1lUPSG55wCY.IbeEkK V1QkSmgPN8UNR5ISL9BTdwsxgXH6XpztTpAdnaF6cSNLU2V1TgMbCTOwHB4HMZrIyVDDCN.nZ5w- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 04:51:36 +0000 Received: by hermes--production-gq1-94b89944-plgtx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 72372fd14dd8f3db89e734b4b4641490; Fri, 30 Sep 2022 04:51:32 +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 debug, was: Re: U-boot on RPI3, sees disk but won't boot it From: Mark Millard In-Reply-To: Date: Thu, 29 Sep 2022 21:51:31 -0700 Cc: freebsd-arm , freebsd-uboot@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <748A5596-9F39-4036-8D07-5AF098AF0289@yahoo.com> References: <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com> <20220929054120.GA77803@www.zefox.net> <20220929151926.GA80020@www.zefox.net> <20220929170927.GB80020@www.zefox.net> <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com> <20220930002742.GA81169@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MdyVz0WTdz3sjX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bFcRbbQ1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.77)[-0.774]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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.65.32:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; 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-29, at 21:11, Mark Millard wrote: > On 2022-Sep-29, at 19:14, Mark Millard wrote: >=20 >> On 2022-Sep-29, at 17:27, bob prohaska wrote: >>=20 >>> . . . >> U-Boot> run bootcmd_usb0 >>=20 >> Device 0:=20 >> usb_read: udev 0 >>=20 >> usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00 >> read10: start 0 blocks 1 >> COMMAND phase >> DATA phase >> usb_bulk_msg error status 0 >=20 > Looks like the above is from: >=20 > result =3D usb_bulk_msg(us->pusb_dev, pipe, srb->pdata, = srb->datalen, > &data_actlen, USB_CNTL_TIMEOUT * 5); > /* special handling of STALL in DATA phase */ > if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) { > . . . > } > if (result < 0) { > debug("usb_bulk_msg error status %ld\n", > us->pusb_dev->status); > usb_stor_BBB_reset(us); > return USB_STOR_TRANSPORT_FAILED; > } >=20 > (result's value seems to not be reported.) >=20 > The above code's usb_stor_BBB_reset use initiated the below: >=20 >> BBB_reset >> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index = 0x0 length 0x0 >> BBB_reset result -110: status 0 reset >> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 = length 0x0 >> BBB_reset result -22: status 0 clearing IN endpoint >> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 = length 0x0 >> BBB_reset result -22: status 0 clearing OUT endpoint >> BBB_reset done >=20 > Looks like -110 is from a: return -ETIMEDOUT; >=20 > Looks like each -22 is from a: return -EINVAL; >=20 > The -EINVAL results seem to be from usb_clear_halt > doing: >=20 > int endp =3D usb_pipeendpoint(pipe)|(usb_pipein(pipe)<<7); >=20 > result =3D usb_control_msg(dev, usb_sndctrlpipe(dev, 0), > USB_REQ_CLEAR_FEATURE, = USB_RECIP_ENDPOINT, 0, > endp, NULL, 0, USB_CNTL_TIMEOUT * 3); >=20 > /* don't clear if failed */ > if (result < 0) =20 > return result; >=20 > usb_clear_halt is used twice, via usb_stor_BBB_reset : >=20 > pipe =3D usb_rcvbulkpipe(us->pusb_dev, us->ep_in); > result =3D usb_clear_halt(us->pusb_dev, pipe); >=20 > pipe =3D usb_sndbulkpipe(us->pusb_dev, us->ep_out); > result =3D usb_clear_halt(us->pusb_dev, pipe); >=20 >> Read ERROR >=20 > This is from: >=20 > retry_it: =20 > if (smallblks =3D=3D ss->max_xfer_blk) > usb_show_progress(); > srb->datalen =3D block_dev->blksz * smallblks; > srb->pdata =3D (unsigned char *)buf_addr; > if (usb_read_10(srb, ss, start, smallblks)) { > debug("Read ERROR\n"); > ss->flags &=3D ~USB_READY; > usb_request_sense(srb, ss); > if (retry--) =20 > goto retry_it; > blkcnt -=3D blks; > break; > } =20 >=20 > The retry_it getting to usb_read_10 again lead to: >=20 >> COMMAND phase >> DATA phase >=20 > So it is the retry using usb_read_10 that ends up with > the RPi3B reboot happening instead of completing. >=20 >=20 > I'm not likely to manage to give this further interpretation. >=20 You generated 2 more error logs. They have (among other things) . . . pelorus_console.txt2_boot_loop ends with: scanning usb for storage devices... 1 Storage Device(s) found U-Boot> run bootcmd_usb0 Device 0:=20 usb_read: udev 0 usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00 read10: start 0 blocks 1 COMMAND phase DATA phase usb_bulk_msg error status 0 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 = length 0x0 BBB_reset result -110: status 0 reset usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 = length 0x0 BBB_reset result -110: status 0 clearing IN endpoint usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 = length 0x0 BBB_reset result -110: status 0 clearing OUT endpoint BBB_reset done Read ERROR COMMAND phase usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status 0 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 = length 0x0 BBB_reset result -110: status 0 reset usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 = length 0x0 BBB_reset result -110: status 0 clearing IN endpoint usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 = length 0x0 BBB_reset result -110: status 0 clearing OUT endpoint BBB_reset done Request Sense returned 00 00 00 (Then it repeats, starting with read10 again, over and over.) pelorus_console_txt3_bootcmd_0_failure ends with: scanning usb for storage devices... 1 Storage Device(s) found U-Boot> run bootcmd_usb0 Device 0:=20 usb_read: udev 0 usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00 read10: start 0 blocks 1 COMMAND phase DATA phase usb_bulk_msg error status 0 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 = length 0x0 BBB_reset result -22: status 0 reset usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 = length 0x0 BBB_reset result -22: status 0 clearing IN endpoint usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 = length 0x0 BBB_reset result -22: status 0 clearing OUT endpoint BBB_reset done Read ERROR COMMAND phase DATA phase (Apparently it hung up instead of rebooting or repeating?) So, at leasts 3 different patterns of -ETIMEDOUT and -EINVAL results in the BBB_reset activity, each of the 3 having a somewhat different overall behavior. I've no clue why the mixes of -ETIMEDOUT and -EINVAL happen. =3D=3D=3D Mark Millard marklmi at yahoo.com