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

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?

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

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.


===
Mark Millard
marklmi at yahoo.com