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

On 2021-Dec-18, at 20:34, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Dec 18, 2021 at 05:19:49PM -0800, Mark Millard wrote:
>> 
>> 
>> On 2021-Dec-18, at 14:35, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> I even tried putting usb_pgood_delay=20000 in config.txt,
>> 
>> Wrong place: usb_pgood_delay is only for U-Boot, not the RPi*
>> firwmare. It does nothing useful in config.txt on an RPi* .
>> 
> 
> I was hopeful that maybe u-boot might pick up the environment
> from the earlier-running firmware. Evidently not.
> 
>> As stands the only ways I know to supply usb_pgood_delay
>> to U-Boot are:
>> 
>> A) Type its assignment into the U-Boot prompt.
>> B) Build the *u-boot*.bin in question with the value assigned
>>   at build time.
>> 
>> To my knowledge (B) has yet to be tried. Any test of
>> usb_pgood_delay that did not involve (A) was a
>> wrong-context test and does not apply.
>> 
>> That includes any testing about seconds vs. milliseconds. I
>> expect that usb_pgood_delay is in milliseconds in U-Boot.
>> 
>>> Usb reset finds the disk after one to about six tries, seemingly 
>>> at random, regardless of 
>>> usb_pgood_delay
>>> bootcode.bin_delay
>> 
>> ".bin"? Wrong name. use: bootcode_delay=
>> 
> 
> Sorry, misreported. The actual line in config.txt on microSD is
> bootcode_delay=10
> 
>> 
>> It will probably be a while before I look at
>> 
>> http://www.zefox.net/~fbsd/slow_usb_notes

I got around to looking there. Note are later below.

>> but it may be that some experiments need to be replaced/re-run
>> based on usb_pgood_delay being provided in the wrong place
>> and the bootcode.bin_delay wrong name being used.
> 
> Experiments using
> editenv usb_pgood_delay from 0 to 20 s while in u-boot were tried. 
> I could not detect any _consistent_ improvement. Sometimes the disk 
> enumerated on the next usb reset, but often enough it made no 
> difference. More confusingly, simply repeating usb reset without doing 
> anything else has always enumerated the disk within (so far) six tries. 
> I'll keep playing with it, especially now that the hub has been removed, 
> but if the timing is fussy a persistent loop seems more dependable. 
> 

http://www.zefox.net/~fbsd/slow_usb_notes shows:

umass0 on uhub1
umass0: <JMicron SABRENT, class 0/0, rev 2.10/12.14, addr 4> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:0:0: Attached to scbus0
. . .
a0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <SABRENT  1214> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 000000000000A
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/

has material about SABRENT adapters:

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

(Not that all models are bad.)

I've not found anything to identify the specific product
that you are using. He lists some specific ones as
problematical but possibly fixable:

	• EC-SSHD*
	• EC-UASP*
	• EC-UK30*
	• EC-UM3W*
	• EC-DFLT*
	• EC-NVME*
	• EC-TFNE*
	• EC-TFNB*

(The above are JMicro based.) Can you identify your adapter
type?

 EC-SNVE*
(unsure)

It is also not clear what drive is being used with the
adapter. That could contribute its own issues.

Looking at old messages:

QUOTE
1 TB Seagate Barracuda with a JMicron USB-SATA bridge
END QUOTE

but, even if that is right, the above is not explicit
about models and such. Hmm, more history that might be
the same hardware:

QUOTE
The hub is 
Bus /dev/usb Device /dev/ugen1.4: ID 05e3:0610 Genesys Logic, Inc. 4-port hub

The disk adapter is 
Bus /dev/usb Device /dev/ugen1.5: ID 152d:1561 JMicron Technology Corp. / JMicron USA Technology Corp. JMS561U two ports SATA 6Gb/s bridge
END QUOTE

Looking around I found evidence suggesting that EC-SSHD has
such a part in use. So I'm guessing that EC-SSHD is what you
have.


===
Mark Millard
marklmi at yahoo.com