Date: Tue, 5 Jul 2022 14:17:17 -0700 From: Mark Millard <marklmi@yahoo.com> To: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) when dd'd to the example USB3 media then used to try to boot via USB3 port Message-ID: <FEE03609-9D06-46FF-A9B0-A58B2622FF43@yahoo.com> References: <FEE03609-9D06-46FF-A9B0-A58B2622FF43.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context:
A) One type of USB3 media (USB2 compatible) works for booting via =
USB2-port.
B) The same media fails for USB3-port based boot attempts.
C) I boot the same type of media for main [so: 14] instead of =
13.1-RELEASE.
D) An alternate type of USB3 media (USB2 compatible) booted via USB3 =
just
fine via 13.1-RELEASE.
The details . . .
I intended for for use in the Rev 1.4 8 GiByte RPi4B's
by first going onto USB3 media (of the same kind I
normally use on the RPi4B's with main and the like).
So, I tried:=20
# dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 \
bs=3D1m conv=3Dsync status=3Dprogress
and then tried to boot the RPi4B via the media and it gets
the following (the kernel loads and runs but . . .):
. . .
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 3 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
mountroot: waiting for device /dev/ufs/rootfs...
Mounting from ufs:/dev/ufs/rootfs failed with error 19.
Loader variables:
vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
vfs.root.mountfrom.options=3Drw
Manual root filesystem specification:
<fstype>:<device> [options]
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.
eg. ufs:/dev/da0s1a
zfs:zroot/ROOT/default
cd9660:/dev/cd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
? List valid disk boot devices
. Yield 1 second (for background tasks)
<empty line> Abort manual input
mountroot>=20
Plugging into the other USB3 port and attempting the
power on boot just changes the port numbers from 3 to 2
in the sequence.
Plugging into a USB2 port does not have the problem and
it completes the boot and operates. (The media is USB3
but USB2 compatible as well.)
Adding to /boot/loader.conf :
# First, 3 additions:
kern.cam.boot_delay=3D10000
vfs.mountroot.timeout=3D10
vfs.root_mount_always_wait=3D1
and retrying via a USB3 port just results in:
. . .
Root mount waiting for: usbus0 CAM
uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for 10 =
more seconds
Mounting from ufs:/dev/ufs/rootfs failed with error 2.
Loader variables:
vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
vfs.root.mountfrom.options=3Drw
Manual root filesystem specification:
<fstype>:<device> [options]
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.
eg. ufs:/dev/da0s1a
zfs:zroot/ROOT/default
cd9660:/dev/cd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
? List valid disk boot devices
. Yield 1 second (for background tasks)
<empty line> Abort manual input
mountroot>=20
So: same problem.
For reference, from the media being plugged into a different
aarch64 FeeBSD machine running main:
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
Samsung PSSD T7 Touch (0x04e8:0x4001)
ugen1.5: <Samsung PSSD T7 Touch> at usbus1
umass0 on uhub4
umass0: <Samsung PSSD T7 Touch, class 0/0, rev 3.20/1.00, addr 9> on =
usbus1
umass0: SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <Samsung PSSD T7 Touch 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2<NO_6_BYTE>
The RPi4B is of a vintage that has the "3 GiByte DMA" issue
present, not that it would be likely to be contributing here.
So I then tried the sequence using a different type of USB3
media (also USB2 compatible), placed in a USB3 port to boot:
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.5: <OWC Envoy Pro mini> at usbus1
umass0 on uhub4
umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 11> on =
usbus1
umass0: SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2<NO_6_BYTE>
For this media, the sequence worked and booted successfully.
So the issue is somehow specific to some USB3 media=20
used in the USB3 ports but not to others. "reset failed,
error=3DUSB_ERR_TIMEOUT" may need more time or better
recovery if a wider range of boot devices are to be
supported. May be the T7 Touch needs more than the
standard amount of time to reset as a USB3 device or
some such. (I've no clue about the details.)
=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?FEE03609-9D06-46FF-A9B0-A58B2622FF43>