From nobody Sun Sep 25 17:39:23 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 4MbCnG6vG2z4cWdC for ; Sun, 25 Sep 2022 17:39:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4MbCnF68P8z3FH9 for ; Sun, 25 Sep 2022 17:39:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664127567; bh=OF3x2Sz1DSm1y9JkBTy6doXqcbvGke1YfnudzIk6kPU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Zg6R0iFvFvAzuGpbGoSq1n6aqmgB7eNC9KcjKz+/1s4Fyk6Q5AAS7O9v4j8JudHtgexsLAIO/bn/2HZHNBYHWX0pWgtv0x3/YEAtsA7FfuYODSDmHvoIc5qkrc2Gv5gsDTdw/m9M3F41yvDe7MK9aLsodnT5ArAF4WWHY2vCQC5Qr3k+O/7I1xEzN67/PUdkVKgoWMucjNHyCrpsPGLwbv3zrtvXkqPryvF/zhupD1iwOj68jVzLABnA0dcjrwLXl07mPU2T9TiSpHTTgKngXffRnCA4Dfg5Pvlcj7XXV0QXzEx4HzXydPggutim75JBpnHjQpdxaf+T8TfcLTR14w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664127567; bh=wJ6ShCBq7kYu6fTt9/QeYu0YRUkIFaoATaW9noqcnCb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EloCBH7aEkmK/WsNiqE7gaJnCvmwaI8NW0VA7HNY0lkYuSluKXQAXAWsc5lTzRffSAIKBEYcx85U8TSE47CZmNXd73m9nEP2ooYgBh98K8r0GGlz7gQ7Rja5zZa/woUQCpaiE1fc4PXeUH1nlK/o1hOtgwzAGhHHYlmVeuHP9gwiMLoi5QnfbQPOIH0DEEZsC0KGyBf0eUVWAYzCpqEWeVThmfabMloINl2YdXQQgh4VRm7RJQHSNCiXkjGgauuE4E07GAnLUVe7nxyl39XF/z5DYiyu0GWEaHbYJ+4XvfkqZ7xJK+h9w1YdgOjeTV8PjspHGRP8u5m/YxwJth1VTw== X-YMail-OSG: trbxIJYVM1mpKX1JU3D6j0HbID4CVlOSyUxr4X7Um4WKDZNiFFyQItjkYyac6e5 MbnqhpvZKCZOV7VqKfWt1vSYz6jp6BYU6rd.O2DeG4o0yeM_1206Ixs0Eu7q9WBsYY4SrINKg6IX y15GcJOtRk4BFKKtePhcyxIo5U4bt1j2FFeEpsNd1PXmDLO_4EezFVOZxbJK08pdLcP.i0n7BCg4 bb37m8HmIZtjVWeaBDkT8J8ofbCNVhy8XzoP4E90jPPcHnLqMRqEfPlPXBTPqFWCgrV3qf71KnY1 F.IWDHb4_L7FAwhZDeDtRB2QdXf1_O3VICUOno9BzKjJ_Z09kYgf.GKjYjlo2WZgco.6SlF8FOxD 3iaXEK4Th6iqSP69Lndq82dhazrGBViA6q1DIi_rg7GDrgfQ37B0rP37o3We.qvtKWPJPMLolfsm 6M.CpNp5Nl3TEc6TZjv40L7_XC7UvPyOsSy9STSZ1EapmZ2ZyDRzqaDOg7urQ3JLVIeMLKifHDMQ EWvSkRYOsEYCpW9AWSsxH0zrCKqZi_23yLv1rnwbonsBOljG3HxV.f8fGenRbjZ8Iok5j3mBV01r EnMrfdSi4J36cEPkG.oGRz2NlfujEA.sxL4iqK31AiYAqp6s_8cQjkTTD59e_vw.bwy5PijrJzuS 8ZLJvOES3LJdmmglTf3_5wY6WABqinMDa4Clw8gYIC.Tf51wKdAsyxk0Rt3ISzzyJYEHTnG.ovPz F1yNEUoeVfpOFfF9z_GWW9L2IVVleWKybrMRIF5tNMhR_MikiDSMLI3FhdeIbUskhNqmM8lgwxw9 c9QwvNJ7gaiyqApgEuXhNg5Mlc51w.dPtkQJJMMdGc5BzrRidVpxSdzaIciH8weKbLGkM1Ut0F43 Ff3Z47JcexEWFbUR8vK02yt2EhWucWmE4o_kYR_7N9s.pHhkKqfbGIkQIs8.B30tgAL7s2kypaly nY0NZStvMSc3FrC1zowH5kCOp6BVRvUlvXUo3ppbI7DnKz4i_Rg3N0bdVEZCImcGsUdf76WoawN6 Tb7d8Hpfv10SwvUou0ZmJO4XV115MevMbNtASUaRRdmZw_tds_17dc1nsu8mSyHCOwhLHXQSzxum 2Iuw4ImJFNDJnX4bk04u93aNUg8LZqrnu_VoEE_Ds2joyYgwSQX4Yax6yI1A6g7mwX_mOxjrKSMh Begvod_4TROe7KpeIfKp_d5G_fgeo1pqbZcKFTAQTq1brHOsTgSKN1FIr2NKJQUxIT3BP5yBIyRr u62011cCjIbWFlBHIbhVmVof3IINNAg80BF7hqGSVVm1zEnFrQdKv1rHUt.9NZtGS8QTLoPGAXeo l0wldBGVKe_jahBjIHtx9X6zq8166swcPbYlWGZBkcwrIXgQ6gb2m8NrzTRAheSobImnrgHUDZmI Qct8N6vjCc4veKHAEjG2xvwaM19TuNBh_IfZUN5k1WPh8EghrDpfgy2UPFtyelfcCR6VmL0BNh2C KfHRa2ljiaCg2Tawiv4h4OsY988xLakn0NWz9yz9Glfs9ZxaRP8uLlroUUWPkCkp_6eoDMM8jnhY n8aSM0V_jRuzoNBKqraoAnjYHPGYyISsMeVlUUyBICpWzfQ05lAHrOsHKLRGh3_n6Y.6L7Dh6.tY Fue1SiDRMUpYjdXrMMp3V06PXXVCiBknl5La0Au4o7qtCZ0Zzz4H.ASyJvpP70PyN0qmZjFs1cLZ CVOdvObgZFIW18wvJxf0.2vfUb4a1MhCYjlq.TdMnAHNwODm1dE3JG4jyKWudjYBfwS_Bhm87L7R f6jQOtcxE_raiwlAICZ31GKSOWcDSpEET4boGfkwqZ6lrZqVuI3Bi_4x1Leywqj_AX0Qgmr7LHC2 oqf9se6esv3oHmoZereJvT6r_O4nx5Hy5AsTBg86AMwbIbcGqsvNmY1XCBlVc9SH0iffpFF2nPJo Ul61GfQxBVpfOz1hlkBYXffzgE9bRKRhfM99wu0Mqs8rdeoIuW8pxknuvzB5Sqzn9Zujy1LkwCWM BFfXquO7aK0XX7WNnXPFvPMmLxWWmItP.52swUFbkOzxP3uJeUmYq25EImnnwgEabtoUCBqi5cCx JfU_XglmPCESDNaJJ4wYa2kETSNjpicwmShLArIyZ9eSHoLBEGjl7w.pTDXnqW4fShTkGlMFA.4N Pb5.zMKl_VcMB_9KGVxmr39n5kKl0KhpAvCfijOGLZ5M7Sdq3.ymu4cMhH3DCRYnJmlg.5GjlYAQ KFuKZcDRMtmDDjUyuyLgZTRyWesFhCNJaRrOaajVVK1lJWpYZlCjd0eqpm0OFIqfh4630NPNhj7E OrTkY X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Sep 2022 17:39:27 +0000 Received: by hermes--production-gq1-7dfd88c84d-bw26r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4dd339a09048b32709e5be7bf5c7c9a3; Sun, 25 Sep 2022 17:39:24 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: <20220925160531.GA63213@www.zefox.net> Date: Sun, 25 Sep 2022 10:39:23 -0700 Cc: FreeBSD Mailing List , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20220925160531.GA63213@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MbCnF68P8z3FH9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Zg6R0iFv; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 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_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-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.69.147: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-25, at 09:05, bob prohaska wrote: > On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote: >>=20 >> After setting initial_turbo=3D60 in config.txt the first reboot >> found the disk, the second did not. Running usb reset then >> found the disk, but run bootcmd_usb0 seemingly caused a reset >> that _then_ found the disk.=20 >=20 > It looks as if u-boot is somehow restarting itself unexpectedly. > This is an RPi3B running stable-13, system and ports up to date > as of yesterday. >=20 > Here's an example session following a failed boot attempt: >=20 > U-Boot> usb reset > resetting USB... > Bus usb@7e980000: USB DWC2 > scanning bus usb@7e980000 for devices... 6 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found For: > U-Boot> usb part >=20 > [I think some information about the disk should have been displayed] >=20 > U-Boot 2022.04 (Sep 23 2022 - 17:28:32 -0700) >=20 > DRAM: 948 MiB >=20 > [...usual startup output] This could suggest power problems. Was this with powered-hub? Without? Powered enclosure? Without? Was this a full RPi* reboot, going back through the RPi* firmware stages before U-Boot started again? Or did the RPi3B avoid starting the firmware sequence again? > Are there any debug switches for u-boot? I've looked a bit and > what I find is either stale or not implemented. There's a reference > to a "log" command, but it does not seem to be recognized. >=20 > It does seem clear that the presence of a timeout file makes no > meaningful difference. Boot succeeds rate is less than 50% >=20 > This is using an unmodified u-boot-rpi-arm64 built locally. The > system has no microSD installed, u-boot is started from the USB > disk (which is found by firmware without trouble).=20 >=20 > If setting up a microSD to start u-boot alone would simplify=20 > matters that seems worth a try. Hints much appreciated!=20 >=20 > Once the machine boots into freebsd it seems to work just fine. > The problem appears to be with u-boot only. If I understand right this is the same JMICRON context we had an exchange about back in late 2022-Jan (and before). Back then there were two RPi*'s to potentially involve in testing. QUOTE The enclosure is simply marked SABRENT EC_UASP,=20 The usb-sata bridge is marked JMS576 2026 QH8A3A A E76H20013 END QUOTE Back then I warned that: = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ reported (and still does): QUOTE Sabrent and Orico both have the worst track records for working storage adapters for the Pi. I don=E2=80=99t recommend them at all but they can = sometimes be fixed. The following Sabrent JMicron adapters can be updated with their = official tool: =E2=80=A2 EC-SSHD* =E2=80=A2 EC-UASP* =E2=80=A2 EC-UK30* =E2=80=A2 EC-UM3W* =E2=80=A2 EC-DFLT* =E2=80=A2 EC-NVME* =E2=80=A2 EC-TFNE* =E2=80=A2 EC-TFNB* Important Note: After the update the Sabrent adapters often work but usually only with quirks mode enabled (see bottom Quirks section of article).=20 For Sabrent=E2=80=99s version of the JMicron firmware update tool: = Sabrent JMicron Update Tool END QUOTE As I remember, there was some discussion of possibly getting and trying alternate equipment not based on the EC-UASP, for example. Possibly a powered enclosure, avoiding a need for a powered hub. Back then I had requested various device swapping tests to see what the problem followed vs. what it did not. The types of tests could be (all are worded in comparison to your existing configuration, not relative to each other): A) Swap just the bridges between the RPi*'s: does the problem follow the bridge? The RPi*/disk combination ? B) Swap just the RPi* 's leaving the disks and bridges paired as they = are: does the problem follow the RPi* ? The bridge/disk combination? C) Swap just the disks, leaving the bridges and RPi* 's paired as they = are: does the problem follow the disk? The RPi*/bridge combination? (Other context held constant, such as the powered hub status of the disk drive.) With 3 devices involved, it takes multiple tests to try to see if, overall, just 1 device is always involved across the failing configurations or if it is always a combination of, say, 2 specific devices. As I remember, no results of such tests were reported. =3D=3D=3D Mark Millard marklmi at yahoo.com