Date: Sat, 16 Jul 2022 11:19:06 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Cc: "manu@freebsd.org" <manu@FreeBSD.org> Subject: Re: Workaround for a FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img (and more) USB3 boot failure on 8 GiByte RPi4B Rev 1.4, B0T SOC [inaccurate timeouts] Message-ID: <E101DE0E-BA17-4B89-A131-9D871D8F9236@yahoo.com> In-Reply-To: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D@yahoo.com> References: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Less invasive workaround and an explanation of what may be going onto mess up (some?) timeouts from be as long as intended, in this case one for USB3 activity.] On 2022-Jul-15, at 23:14, Mark Millard <marklmi@yahoo.com> wrote: > I've reported the following boot problem to the lists > before but for older stable/13 and releng/13.1 versions. > I thought it had been fixed but it turns out something > else I had done hid the problem. >=20 > Both before and now, it turns out to fail or not based > on using the original config.txt vs. using one with > at least one specific line added that for some reason > avoids the problem. (I'm not blaming RPi* firmware.) >=20 > The failure looks like: >=20 > . . . > Release APs...done > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > uhub0: 5 ports with 4 removable, self powered > ugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0 > uhub1 on uhub0 > uhub1: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.21, addr 1> on = usbus0 > Root mount waiting for: usbus0 > uhub1: 4 ports with 4 removable, self powered > Root mount waiting for: usbus0 > uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2 > mountroot: waiting for device /dev/ufs/rootfs... > Mounting from ufs:/dev/ufs/rootfs failed with error 19. >=20 > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs > vfs.root.mountfrom.options=3Drw >=20 > Manual root filesystem specification: > <fstype>:<device> [options] > Mount <device> using filesystem <fstype> > and with the specified (optional) option list. >=20 > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >=20 > ? List valid disk boot devices > . Yield 1 second (for background tasks) > <empty line> Abort manual input >=20 > mountroot>=20 >=20 > Both types of USB3 SSD boot media that I use get the problem. > One type I've used for many years and another for over > a year. Both USB3 ports lead to failure. >=20 > Similarly, more than one U-Boot version makes no difference > to the observed failure. >=20 > The workaround I've found is as shown below: >=20 > root@generic:~ # diff -u /boot/msdos/config.txt.orig = /boot/msdos/config.txt > --- /boot/msdos/config.txt.orig 2022-07-15 02:43:02.000000000 +0000 > +++ /boot/msdos/config.txt 2022-07-15 04:39:30.000000000 +0000 > @@ -9,3 +9,8 @@ > [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 ? > +force_turbo=3D1 Following the implications in: = https://forums.raspberrypi.com/viewtopic.php?f=3D29&t=3D6201&start=3D425#p= 180099 QUOTE . . . is done early in boot, before the cpufreq driver is loaded, and so measures the stock (700MHz) frequency. Now this is value is used = elsewhere in linux when calibrating delays. E.g. the sdcard driver might call udelay(1) and expect to get a delay of at least one microsecond. However if the ARM is now at 1GHz, it will only get a 0.7 microseconds, which could cause a problem. To help investigate this, I've add a config.txt parameter, = initial_turbo, which means turbo will be enabled from boot for this many seconds (up to 60), or until cpufreq driver sets a frequency. END QUOTE I've switched to trying: # diff -u /boot/msdos/config.txt.orig /boot/msdos/config.txt --- /boot/msdos/config.txt.orig 2022-07-15 02:43:02.000000000 +0000 +++ /boot/msdos/config.txt 2022-07-15 05:10:06.000000000 +0000 @@ -9,3 +9,8 @@ [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 and this was enough to avoid the problems. (I've not tried to find a near minimum for initial_turbo, I just used the maximum.) It looks like stable/13 and releng/13.1 are sensitive to scaling time based on early clock rates that later change to faster rates, making timeouts happen in the wrong time frame. I've not seen evidence of this for main [so: 14]. Or that is my guess at this point, not having driectly verified a time scale difference at the involved code.. I've no clue if it is better for FreeBSD to add-in initial_turbo=3D60 to its contig.txt vs. doing something to avoid the sensitivity to initial and later varying clock rates. Covering releng/13.1 without an EN (or whatever it is called) would happen via initial_turbo=3D60 use in the port's config.txt . I do not know if main [so: 14] has different timeout handling that might explain why I've not found the problem in that context. > I do not claim that is the only possibily, just that it > has sufficient in my context. Turned out initial_turbo=3D60 was another workaround. > As my normal configuration uses "force_turbo=3D1", I would only > have ever noticed the issue if I'd tried to boot before making > the config.txt changes I normally have in place. Thus, the > issue might have been around for a notable time without my > noticing. >=20 >=20 > I've tried my U-Boot based main [so: 14] boot media without > the "force_turbo=3D1". It booted just fine. >=20 =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?E101DE0E-BA17-4B89-A131-9D871D8F9236>