RPi4B: booting USB3 SSD media vs. config.txt in FreeBSD snapshot builds (and relelase builds): avoiding error=USB_ERR_TIMEOUT

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=1
  dtparam=audio=on,i2c_arm=on,spi=on
  dtoverlay=mmc
  dtoverlay=disable-bt
  device_tree_address=0x4000
  kernel=u-boot.bin
  
  [pi4]
  hdmi_safe=1
  armstub=armstub8-gic.bin
+#
+# Local addition that avoids USB3 SSD boot failures that look like:
+#   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT
+#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?
+initial_turbo=60

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=60 (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.)

===
Mark Millard
marklmi at yahoo.com