Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot

Reply: bob prohaska : "Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot"
In reply to: bob prohaska : "Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org>
Date: Mon, 20 Dec 2021 06:08:29 UTC
On 2021-Dec-19, at 20:39, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sun, Dec 19, 2021 at 04:48:58PM -0800, Mark Millard wrote:
>> On 2021-Dec-19, at 15:54, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> On Sun, Dec 19, 2021 at 01:13:12PM -0800, Mark Millard wrote:
>>>> On 2021-Dec-19, at 11:28, bob prohaska <fbsd at www.zefox.net> wrote:
>>>> 
>>>>> On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote:
>>> ....
>>>>>> (The above are JMicro based.) Can you identify your adapter
>>>>>> type?
>>>>>> 
>>>>> 
>>>>> The enclosure is simply marked SABRENT EC_UASP, 
>>>>> The usb-sata bridge is marked   JMS576
>>>>>                              2026 QH8A3A A
>>>>>                              E76H20013
>>>> 
>>>> THat is one of the ones listed on
>>>> 
>>>> https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/
>>>> 
>>>> as potentially fixable (with quirks possibly involved). See:
>>>> 
>>>> https://www.sabrent.com/download/jmicron-sabrent-update-tool/
>>>> 
>>>> for SABRENT's Firmware-Update Tool. Looks like Windows7+ is
>>>> a required context for doing the firmware update.
>>>> 
>>> Yes, I'm searching for  a Windows machine to give it a try.
>>> I wonder how new the update is; running strings on the .exe finds
>>> Borland C++ - Copyright 2002 Borland Corporation
>>> 
>>>> I've not checked if FreeBSD has any quirks in place.
>>>> 
>>> My troublesome Pi3 and trouble-free Pi4 with JMicron bridge report
>>> umass0:  SCSI over Bulk-Only; quirks = 0x8100
>>> da0: quirks=0x2<NO_6_BYTE>
>> 
>> FreeBSD version(s)? (The quirks lists can be distinct.)
>> U-Boot versions(s)?
>> RPi* firmware version(s)?
> 
> For the Pi4 that works I find
> FreeBSD 14.0-CURRENT (GENERIC) #18 main-aee99ab4fe: Wed Dec 15 23:45:26 PST 2021
> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)

I pay attention to the "2020.10" part. The build time makes no
obvious distinction on its own about the content.

> The start* files are all from March 4 or March 7, 2021

The file system dates need not track the RPi* firmware build dates:
they could be any later time. More appropriate to report is the
likes of:

# strings start4.elf | grep "VC_BUILD_ID_"
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

> The files haven't been altered manually, but possibly by installworld/kernel.
> 
> The Pi3 with problems runs
> FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #2 stable/13-n248556-0848451a2ee: Wed Dec 15 19:54:57 PST 2021     bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64

I'll note that the stable/* use sys/*/config/GENERIC files that
build non-debug kernels but main uses sys/*/config/GENERIC files
that build debug kernels.

> The start* files are dated March 3, 2021, 

Again: something like the following is better to report:

# strings start4.elf | grep "VC_BUILD_ID_"
. . .

> u-boot.bin on the microSD card seems to be 
> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000)
> and all are from the original -release image.

Then, for example, start4.elf would likely have
the:

VC_BUILD_ID_TIME: Feb 25 2021

type of VC_BUILD_ID_ material as shown above (if I
remember correctly).

>> The RPi4 could well have distinct results on USB3 vs.
>> USB2 ports: The USB2 ports are likely limited to 500mA
>> but the USB3 ports support 900mA (so: near the spin-up
>> requirement).
> 
> I probably shouldn't compare the Pi4 with the Pi3, they're
> very different in the USB department. 

But using the USB2 ports on the RPi4B's could be more
analogous to the RPi3*'s in some respects. Using USB3
ports is definitely not analogous to the RPi3*'s in
various ways that need not be different.

>>> A second  Pi3 that uses the same Seagate drive through 
>>> an ASMT bridge reports
>>> umass0:  SCSI over Bulk-Only; quirks = 0x0100
>>> da0: quirks=0x2<NO_6_BYTE>
>>> It has no trouble finding the disk in repeated attempts.
>> 
>> FreeBSD version? (The quirks lists can be distinct.)
> FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n249322-ae87a08c410: Mon Sep 13 14:44:29 PDT 2021     bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64
> 
>> U-Boot versions?
> On the microSD:
> U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700) 

Definitely older, so different in various ways.

>> RPi* firmware version?
> Quite old also. 2018 and 2019, but I'm not sure the dates are right.

Again: something like the following is better to report:

# strings start4.elf | grep "VC_BUILD_ID_"
. . .

> There's a file named uboot.env that is dated Dec. 30 1979, that
> can't be right.

Probably just established when the RPi*'s time was not
set correctly. It is a script file that predates the
UEFI style of U-Boot builds being used.

>> 
>> And are the RPi3's the same model (B vs. B+)?
>> 
> 
> Probably not, they were bought some time apart. I'd be hard pressed 
> to say which is which without disconnecting them.

The debug boot output reports what is necessary for
identifciation ( from http://www.zefox.net/~fbsd/slow_usb_notes ):

MESS:00:00:21.547594:0: dtb_file 'bcm2710-rpi-3-b.dtb'
MESS:00:00:21.554836:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
MESS:00:00:21.559497:0: Loading 'bcm2710-rpi-3-b.dtb' to 0x4000 size 0x6ee8

Example .dtb names are (grabbed from a RaspiOS64 context):

-rwxr-xr-x 1 root root 27441 Nov 30 13:14 /boot/bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root 29558 Nov 30 13:14 /boot/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 28939 Nov 30 13:14 /boot/bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 27429 Nov 30 13:14 /boot/bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 49833 Nov 30 13:14 /boot/bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 49877 Nov 30 13:14 /boot/bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root root 50555 Nov 30 13:14 /boot/bcm2711-rpi-cm4.dtb

The correct bcm*.dtb will show up in the debug output.

So, the http://www.zefox.net/~fbsd/slow_usb_notes file shows the
debug output for a RPi3B (not a RPi3B+).



Looks like you have a context where substitution tests might
be possible, at least if machines can be down for a time.

For example, swap just the 2 adapters and see if the problem
follows the adapter vs. stays with the drive/RPi3* combination.

A separate test: swapping just drives to see if the problem follows
the drive vs. stays with the adapter/RPi3* combination.

And: swapping just RPi3*'s to see if the problem follows the
RPi3* vs. stays with the adapter/drive combination.

Doing all 3 checks for some interaction effects. Hopefully only
one of the 3 gets a "follows" result.

>>>> The power (current) requirements to get this drive spinning is double
>>>> what a USB2 port has for a maximum in the USB2 standard: The drive is
>>>> problematical unless power is being drawn from 2 USB2 ports for
>>>> the one drive. EC-UASP does not seem to support such
>>>> dual-USB2-port use. (The RPi*'s are not designed to provide extra
>>>> power on a USB2 port as far as I know.)
>>>> 
>>> 
>>> It's clear that I'm pushing limits quite hard at startup. Still, by
>>> the time of disk discovery the initial surge is over.
>> 
>> Being mismatched for power could have non-time-local
>> consequences to either the drive or the adapter or
>> the RPi*.
>> 
>> (Avoiding USB Hub protocol activity is a separate/additional
>> distinction.)
>> 
>>> There's no
>>> mouse or keyboard on either Pi3. The Pi3 that finds the disk is 
>>> running -current, the Pi3 that can't find the disk is stable/13.
>> 
>> What specific current and stable/13 commits?
> No custom changes.

Your text like "main-aee99ab4fe", "stable/13-n248556-0848451a2ee",
and "main-n249322-ae87a08c410" answered what commits are in use
for each.

(The one missing "-n??????" text is odd by the text being missing.
But the aee99ab4fe part should fully identify the commit in main.)

>> What of U-Boot versions?
>> What of RPi* firmware versions?
>> 
> The best summary I can come up with is: 
> Not able to find the USB disk, all dated 2021.
> Able to find the USB disk, dated 2020 and older.

Your earlier material above answered the U-Boot version
question.

The RPi* firmware one needs the outputs from the likes
of doing:

# strings start4.elf | grep "VC_BUILD_ID_"
. . .


>> There are cases with external power allowed that avoid
>> adding the USB Hub protocol to the activity.
>> 
> 
> I've got a powered usb-sata adapter on my shopping list.



===
Mark Millard
marklmi at yahoo.com