From nobody Sun Sep 25 23:43:15 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 4MbMs93BL4z4dFj4 for ; Sun, 25 Sep 2022 23:43:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4MbMs84jxhz3vZq for ; Sun, 25 Sep 2022 23:43:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664149402; bh=i7StZLrhq4EveZdCe2JdXxii/wlebp0jcnh+u+Fcl6A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qhvF7HTFLNrwxs4aSkrpA8StHXMCrA07QpjFliCKZAxAinpgNh8DNct4AEOxnJHmljHb3+0zm3ixTssrnYHuvAh/fkClVufncXhF7Bba1exrT9+D7XVXNLbjajsOTVsQP7DIKSyOMU/UeM7UhT5+itEaWS4FXrvVzeOE8N75aXCo/Boj9LhQ9oAALIvsL2CXz/o3RvoYoMxxLxpFPg83Mup8OW4yjTTZLElR4ckFUU4oAu5W4ukmzzKOAC72v8RITx0TOH3m44OK95U7XEJQb6/twWcbPgtGeSzNHoqgK1KciIMJkzqAEpLxO5GV7UQ/Ayv6NzVthGORB1GtOQeRQg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664149402; bh=YxP3FLHoT1MKIVtL9+t1ueP5WlYwLHMbt4nCRtRNT+h=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YGIKP/lb431GaW/y11DYFqN0WPSD6DCHz+1e1vnCax3Zw9dZAY3alIX7uAeSKuPBTEfvBylu5ZyOnlAAW9qCah4J70ly0ZemggKG5SRC0oMIJaD90sGQSNmMeUn2BVnlEiaiFRtZTqwFOTg5MCZ06SS6iwrMoBW2Sl2RNZc50hRaQ5QBqtgHA75znMpTVTLLfXvlq0g4D7Vdl5dHDhxmLUiCLoaBX1OJhjk95BBG/uGMVszwtQfXYBpcyd7ht9RdCoFrsWabPuTeshCUGUbsCeGeS8ng5rW1LVfrYbfjmAPvTePLZ9eH872+yFdD634HfP6mC5Gaw4v4mWLVXOvPvQ== X-YMail-OSG: azvc8a0VM1nlUQBJV7oMrjX78Hg9XKSBs99NkMG9GYX_RXodppfyJUWmgrGamyi Ii3KgSJrP_Dk.0LOFNpgqgJqHA8mVeKGyLvm0f0fUlV5M5nb2Z.lbrlZhsBv7gHv5DtXarLYidYh ylMiwZTYSrHnpX6mEeVzCnTslQ1T2fKFOKrxVsn7F_UhxCVT5SoWZnHXaOvZdTxSNiJ.gfKgBvQ4 GgZRyeJSKEpvm23EWQyn1zJwKlVoaTzalJthFdjF8ngUTTd4972a3mkIvBAEDJuv0wVk6Tk9jOg_ NHhY9CvhuZ8omnOg44CF2c9K1.iqWKt_6OanJniGyxKKJZ3ODFVpgGFXjvnl9yLb.nym7j.ksNn2 9Yhu8BkfS_vTSielNm0oCBKdNBMuHBMrXoA_6qFAghI96VsxNdQ1SLFtbeMBGyQwWLxY6O.i5sRP xLZAkIw_RrXdMZjb8wEJeWtOWJwAMyjsCc5ZLsPw5BX9Q0Y4_XGwyxm0v6GjZe6WtfmEzjRM240P oPt7RpLxCv1OkGNVg86_CuLVvxu85uwqa04H2ikLJVYCywn35bBvqnJEipC7UgkKfW13k5hlcwkc Puiz41LzVC5VAs0B8.PZI3tqW18.4wuam47gG3C3MBSElxPSwzI1WiCGRcmvdyY9pyJW7.FJ0A5m C7pjYSl75Nq_J9UE.YJM9KeM_mvTD7RCEQLovN97CX3MXGEEa9CIlXTNnlPix9ldOfeMRKP7IyF_ kyOpd0Liox4CcLDlfbNkH2TYA6ch3l3IB9li6ttTFlVcLBoH2UuCA.FX4YtTyqqQqR7SI6lQRdUN YaiuKJYW0YlUbn4u1cr22nTsiwfpDqswBy7x9ijYQd7d3Aqt5V_PwbOtIzLmEZXLAtvdJIQctA0W y_JjvAdADoh8GZkZrwoTLNUOcC3RqmUXnUsCU3PC39sYqAwTHgKkunUgU8mrwq0clM8GAbHPM3u3 7oo_9eFPlW3THQeKE4BTXcYNL1B4mUayIzckLWWk0gSnvEO5VpfBcPC_4i_hM8Mw3tJty57q.E2Y I4_hAKgpMu1VDaju1bfR1TBruLFoRegeVxeLTZqAfc.6ZneeLZI7R4vjuMGgCGyWMiI0m7HjlC5K 7SWRAz9VQPqofqVLUu9n.8g6Dbplt1XFNVkpHDJRqCvQLrfuGIPmgR0AH0nWdwx.ovJyE0MAqed4 ZKk2gQka9FHspf8v1m..X9P9n1IWpYTcUMHCu_polyqYEK5kUWA1wReSNqrhiNYJwvbeOpepgW69 5hJjwKe8WMG.CTGMBZJW5kFcGGK1MeH270ieFCcGmQtQZb7oEjtE3XEmC2fkTrGtgy_FQuvbSuQW Cq6Y.ockNwCi9bpYLxj92pKDLruYPjvDdb6XjYNsl2tW3k_Fl2upVk683_kOxKy.MceqdH3EO9dp bMwuEN1hAUQIdlRWDQSz4tODwusUnxOhxfdenA5e2_H_EY_48uZGBO7vKTVUELmtTLoFmLdlekYp dwmYfdVHlTGaehc1QckQz41ea9RIAvtn5oVkIFIgNUW9CmWAC7W2FIP8zgR9UmOcLw7u9xVqTx4k HLswkChhw8NEF4wVSEhgP.A9TWIgRqNBCGashcpsRluo.12dH2bXfY57bSMfEKDH0b20mifLxmRB DXiPMV2F_hhk3.V9OP1T13MwRgaP5xWCQoY.TeiUMh4CpAqchZV.nSEHVHHCumqcCP9pAmp75fNO Q78hP93z0mMZkkJHevLwZP4SLVgKGskCTWvdzenBxl7IcJ549Bn3p2PUv7Q55KDlf1XaFp85EZYe GtO.W4Gz_fsXMgOiJhvLjVul9F7pcq0fEphxXaOKrxTk5IqoPHJh9L34pKRIOoqI9f97lRo5gZDy ZvxxWcsxErWjJry1GfaGNPvLsPkWSHFv5x1Hwlk6ib0_UNuyG8KfZYMSUcaS.uernYZMqOmMGx5K 8GDR1Rct7f7jDTSgt7D8Qrirb1ABO4tQ5aworJWbe7qA2Oqg5x5HF8yu6xGOfoEe9BmGBqDKCils K3i39lmAIlQ3FP9SWLJIzIoBsnea90D0ocwsQpjXcaZvMDC5GwAVXfZnTsFtM53qdgjHvS._Jk_G zI9.G_9UkCYcNgRl6Ry20edNp6g_7wevjMkn0JIp4VYqhObD914gQOZAAaaIwt84V8EF4v1X_wnv 1q8IPRdwE4Ss8o3wZxg2KHaUIgCXL07HoeyzBAHlaS96kD7_ZqChFBsYrCGPqIZXBVgcbl5iJvTB MwGGj2W1jvr3GNlYjdB9pMvbw3uGTye2NGSlqEY0dBBOT_ZjflRc024GceAaOlz_BPeGEIFydNYN dHUMj0A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Sep 2022 23:43:22 +0000 Received: by hermes--production-ne1-6dd4f99767-w779p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6139be1c5984a10cf159552092e5c29b; Sun, 25 Sep 2022 23:43:17 +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: <20220925193415.GA63733@www.zefox.net> Date: Sun, 25 Sep 2022 16:43:15 -0700 Cc: FreeBSD Mailing List , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@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> <20220925160531.GA63213@www.zefox.net> <20220925193415.GA63733@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MbMs84jxhz3vZq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qhvF7HTF; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 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.988]; 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.65.83: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 12:34, bob prohaska wrote: > On Sun, Sep 25, 2022 at 10:39:23AM -0700, Mark Millard wrote: >> On 2022-Sep-25, at 09:05, bob prohaska wrote: >>=20 >>> 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 >>=20 >> For: >>=20 >>> 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] >>=20 >> This could suggest power problems. Was this with powered-hub? >> Without? Powered enclosure? Without? >=20 > USB 3 powered hub driving USB 3 powered enclosure. I've checked > voltages on the Pi and found no evidence of power trouble. > There's no ready access to the hub and disk power leads. I'll note that if replacing a RPi3B with a RPi4B (without other changes to the configuration) leads to a working context, this again could suggest power problems. But a test here is if that "working" status applies both to when a USB3 port is used on the RPi4B and when a USB2 port is used on the RPi4B. The USB2 standard does not require as much current to be supplied. However, if I understand right, the RPi4B (not otherwise loaded) easily supplies more current on USB2 than a RPi3B can reliably supply --and more than the USB2 standard specifies. (Similarly for keeping the voltage up.) Still, there might be some distinction for USB2 on the RPi4B. (I doubt the RPi4B USB2 ports could supply as much as the USB3 standard says is required to be allowed. But I could be wrong.) Because USB3 introduces various differences, some testing via the RPi4B USB2 ports is appropriate. >> 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? >>=20 >=20 > I think the sequence was a full shutdown -r, u-boot didn't find the > disk but usb reset did find the disk. Then the usb part command > seemed to restart u-boot.=20 >=20 > Repeating the experiment just now the sequence was shutdown -r now, > no disk found, usb reset, disk found, usb part, u-boot restarted > and successfully booted to multi-user. >=20 >=20 >>> 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. >>=20 >> 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. >>=20 >> QUOTE >> The enclosure is simply marked SABRENT EC_UASP,=20 >> The usb-sata bridge is marked JMS576 >> 2026 QH8A3A A >> E76H20013 >> END QUOTE >>=20 >> Back then I warned that: >>=20 >> = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ >>=20 >> reported (and still does): >>=20 >> QUOTE >> Sabrent and Orico both have the worst track records for working = storage >> adapters for the Pi. I don???t recommend them at all but they can = sometimes >> be fixed. >>=20 >> The following Sabrent JMicron adapters can be updated with their = official >> tool: >>=20 >> ??? EC-SSHD* >> ??? EC-UASP* >> ??? EC-UK30* >> ??? EC-UM3W* >> ??? EC-DFLT* >> ??? EC-NVME* >> ??? EC-TFNE* >> ??? 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 >>=20 >> For Sabrent???s version of the JMicron firmware update tool: Sabrent >> JMicron Update Tool >> END QUOTE >>=20 >> 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. >>=20 >> 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): >>=20 >> A) Swap just the bridges between the RPi*'s: does the problem >> follow the bridge? The RPi*/disk combination ? >>=20 >=20 > Far as I recall the trouble followed the bridge. >=20 >=20 >> 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? >>=20 >> 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? >>=20 >> (Other context held constant, such as the powered hub status >> of the disk drive.) >>=20 >> 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. >>=20 >> As I remember, no results of such tests were reported. >=20 > I did a few experiments but didn't find a way to clearly > record/report the various combinations and behavior.=20 > Very roughly, the Sabrent enclosures work fine on Rpi4's, > both RasPiOS-32bit and FreeBSD-current. On RPi3 the Sabrent > enclosure isn't reliably discovered but works once found. >=20 > My setup makes swapping hardware around somewhat awkward, > as the Pi's are daisy-chained via serial console. The Sabrent > equipped Pi3 is the terminal server for the Startech-equipped > -current Pi3 that has been my reference. There are only two > Pi3's available for experimentation, plus one Pi4. I'll have > to think carefully before making much in the way of wiring > changes, lest the confusion grow worse. >=20 > IIRC I did try replacing the Sabrent enclosure with the Startech > enclosure, which worked and seemed to implicate the Sabrent as > the culprit. Thus my interest in u-boot debug information. =20 I've no clue what information to enable to learn about the type of failure in the Sabrent enclosure (if that is where the problem is). But, again, if RPi4B works via USB2 but RPi3B does not, the difference once U-Boot is started on the two is likely(?) mostly power quality/sufficiency as far as I can tell. Going the other way, if the RPi4B failed via USB2 use, that likely would point in a different direction than power quality/sufficiency and might suggest USB3 handling is required for some reason. =3D=3D=3D Mark Millard marklmi at yahoo.com