Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

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:
> 
> > On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote:
> >> 
> >> After setting initial_turbo=60 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. 
> > 
> > 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.
> > 
> > Here's an example session following a failed boot attempt:
> > 
> > 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
> > 
> > [I think some information about the disk should have been displayed]
> > 
> > U-Boot 2022.04 (Sep 23 2022 - 17:28:32 -0700)
> > 
> > DRAM:  948 MiB
> > 
> > [...usual startup output]
> 
> This could suggest power problems. Was this with powered-hub?
> Without? Powered enclosure? Without?

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.

> 
> 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?
> 

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. 

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.


> > 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.
> > 
> > It does seem clear that the presence of a timeout file makes no
> > meaningful difference. Boot succeeds rate is less than 50%
> > 
> > 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). 
> > 
> > If setting up a microSD to start u-boot alone would simplify 
> > matters that seems worth a try. Hints much appreciated! 
> > 
> > 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, 
> 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-firmware-updates/
> 
> reported (and still does):
> 
> 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.
> 
> The following Sabrent JMicron adapters can be updated with their official
> tool:
> 
> 	??? 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). 
> 
> For Sabrent???s 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 ?
> 

Far as I recall the trouble followed the bridge.


> 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.

I did a few experiments but didn't find a way to clearly
record/report the various combinations and behavior. 
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.

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.

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.  

Thanks for writing!

bob prohaska