Date: Sun, 19 Dec 2021 22:08:29 -0800 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> In-Reply-To: <20211220043956.GA16208@www.zefox.net> References: <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <EC6CC83C-BC0A-4A12-866A-9FA24083FF7E@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <E62FFB2B-9424-434D-9358-280FD8EC1B91@yahoo.com> <20211220043956.GA16208@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>> 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: >>>>=20 >>>>> On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote: >>> .... >>>>>> (The above are JMicro based.) Can you identify your adapter >>>>>> type? >>>>>>=20 >>>>>=20 >>>>> The enclosure is simply marked SABRENT EC_UASP,=20 >>>>> The usb-sata bridge is marked JMS576 >>>>> 2026 QH8A3A A >>>>> E76H20013 >>>>=20 >>>> THat is one of the ones listed on >>>>=20 >>>> = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ >>>>=20 >>>> as potentially fixable (with quirks possibly involved). See: >>>>=20 >>>> https://www.sabrent.com/download/jmicron-sabrent-update-tool/ >>>>=20 >>>> for SABRENT's Firmware-Update Tool. Looks like Windows7+ is >>>> a required context for doing the firmware update. >>>>=20 >>> 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 >>>=20 >>>> I've not checked if FreeBSD has any quirks in place. >>>>=20 >>> My troublesome Pi3 and trouble-free Pi4 with JMicron bridge report >>> umass0: SCSI over Bulk-Only; quirks =3D 0x8100 >>> da0: quirks=3D0x2<NO_6_BYTE> >>=20 >> FreeBSD version(s)? (The quirks lists can be distinct.) >> U-Boot versions(s)? >> RPi* firmware version(s)? >=20 > 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. >=20 > 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,=20 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=20 > 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). >=20 > I probably shouldn't compare the Pi4 with the Pi3, they're > very different in the USB department.=20 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=20 >>> an ASMT bridge reports >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>> da0: quirks=3D0x2<NO_6_BYTE> >>> It has no trouble finding the disk in repeated attempts. >>=20 >> 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 >=20 >> U-Boot versions? > On the microSD: > U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700)=20 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. >>=20 >> And are the RPi3's the same model (B vs. B+)? >>=20 >=20 > Probably not, they were bought some time apart. I'd be hard pressed=20 > 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.) >>>>=20 >>>=20 >>> It's clear that I'm pushing limits quite hard at startup. Still, by >>> the time of disk discovery the initial surge is over. >>=20 >> Being mismatched for power could have non-time-local >> consequences to either the drive or the adapter or >> the RPi*. >>=20 >> (Avoiding USB Hub protocol activity is a separate/additional >> distinction.) >>=20 >>> There's no >>> mouse or keyboard on either Pi3. The Pi3 that finds the disk is=20 >>> running -current, the Pi3 that can't find the disk is stable/13. >>=20 >> 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? >>=20 > The best summary I can come up with is:=20 > 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. >>=20 >=20 > I've got a powered usb-sata adapter on my shopping list. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?85C29A39-824B-4FFF-8EE4-70CECE7AD09D>