Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot
Date: Mon, 20 Dec 2021 00:48:58 UTC
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)? 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). > 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.) U-Boot versions? RPi* firmware version? And are the RPi3's the same model (B vs. B+)? >> >> 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? What of U-Boot versions? What of RPi* firmware versions? >> That things do not work well for USB2 port use is not surprising. >> >> The startup current requirement is nearly as large as the total >> current for USB on the RPi*'s. (The RPi*'s support less of a total >> than the sum of the individual ports maximums: only 1200mA total.) > > I'm _just_ under the limit at spinup, No, you are not. 1 (standard) USB2 port does not supply anywhere near 1000mA, only 500 mA or less. It takes using 2 (standard) USB2 ports to get 1000mA. Some adapters provide for making such double connections to get the extra power. This is true no matter how much total power for USB that there is: per-port is normally far less than that total. (The total is also commonly less than the sum of the per-port maximums, such as 1200 mA instead of 4*500mA [2000mA] for the RPi3*'s.) > but well under once running. > >> >> SSD's are a better match to RPi* power than spinning rust is, unless >> the spinning rust has its own power supply and is already powered >> before the RPi* is powered. There are types of cases that have such >> independent power instead of being bus-powered. Bus-powered spinning >> rust is a problem for single-port USB2 (and possibly even single-port >> USB3). >> > > I don't plan to run the disk without an auxiliary power supply > long term. In fact, since removing the powered hub doesn't > seem to help with the enumeration problem it could be put back. There are cases with external power allowed that avoid adding the USB Hub protocol to the activity. === Mark Millard marklmi at yahoo.com