Date: Sun, 25 Sep 2022 16:43:15 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com> In-Reply-To: <20220925193415.GA63733@www.zefox.net> 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> <DBD238AA-8C65-46D2-87CC-A9875C6959BF@yahoo.com> <20220925193415.GA63733@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-25, at 12:34, bob prohaska <fbsd@www.zefox.net> wrote: > On Sun, Sep 25, 2022 at 10:39:23AM -0700, Mark Millard wrote: >> On 2022-Sep-25, at 09:05, bob prohaska <fbsd@www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D6CF13E-261D-41D2-AC5B-923C0BF54087>