Date: Tue, 27 Dec 2022 12:31:56 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: RPi4B: booting USB3 SSD media vs. config.txt in FreeBSD snapshot builds (and relelase builds): avoiding error=USB_ERR_TIMEOUT Message-ID: <DC3D85D4-CEB7-42F3-ADBF-3DAD37759218@yahoo.com> References: <DC3D85D4-CEB7-42F3-ADBF-3DAD37759218.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is about "no microsd cards involved" booting of USB3 SSD media on RPI4B's. For some time I've had to edit the default config.txt that FreeBSD uses or booting USB3 SSDs fails. (Leading whitespace possibly not preserved:) # diff -u99 /boot/msdos/config.txt.orig /boot/msdos/config.txt --- /boot/msdos/config.txt.orig 2022-12-23 22:17:48.000000000 +0000 +++ /boot/msdos/config.txt 2022-12-27 17:22:08.000000000 +0000 @@ -1,11 +1,16 @@ [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin =20 [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin +# +# Local addition that avoids USB3 SSD boot failures that look like: +# uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT +# uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port ? +initial_turbo=3D60 The latest example is from an experiment with: # uname -apKU FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 = stable/13-n253304-461210143fbb: Fri Dec 23 23:25:49 UTC 2022 = root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1301510 1301510 that was otherwise unchanged. But this has been going on for some time. Given what makes it go from timeout to working, it suggests sensitivity to variations in clock rate that initial_turbo=3D60 (or analogous) avoids. (I've not tried to find an estimate of the minimum time figure that could be used.) FYI: the context happens to be serial console, no HDMI connection. It may be that the EEPROM vintage is involved in the variability. (Old enough ones might not have the variability?) But the EEPROM vintage may not be relevant, I do not know. I normally track: https://github.com/raspberrypi/rpi-eeprom/releases So I'm currently using RPI4B's with EEPROM content based on: rpi-boot-eeprom-recovery-2022-12-07-vl805-000138a1 materials. But, again, the issue is older. I do not have a first-failure time frame, however. Given the history and the boot failures, it looks to me like an initial_turbo assignment in the default FreeBSD rpi firmware port's config.txt would be appropriate. (Presumes no one deals with avoiding there being a frequency-variation sensitivity in the first place. I've not managed to identify where any sensitivities happen to be.) =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?DC3D85D4-CEB7-42F3-ADBF-3DAD37759218>