Date: Tue, 5 Jul 2022 15:45:25 -0700 From: Mark Millard <marklmi@yahoo.com> To: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Re: 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: <D5AEF496-4C52-4D7C-9DF3-1C6BACFDBAC1@yahoo.com> In-Reply-To: <FEE03609-9D06-46FF-A9B0-A58B2622FF43@yahoo.com> References: <FEE03609-9D06-46FF-A9B0-A58B2622FF43@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-5, at 14:17, Mark Millard <marklmi@yahoo.com> wrote: > Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context: >=20 > 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. >=20 > The details . . . >=20 > 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 >=20 > # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 \ > bs=3D1m conv=3Dsync status=3Dprogress >=20 > and then tried to boot the RPi4B via the media and it gets > the following (the kernel loads and runs but . . .): >=20 > . . . > 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. >=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 > Plugging into the other USB3 port and attempting the > power on boot just changes the port numbers from 3 to 2 > in the sequence. >=20 > 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.) >=20 > Adding to /boot/loader.conf : >=20 > # First, 3 additions: > kern.cam.boot_delay=3D10000 > vfs.mountroot.timeout=3D10 > vfs.root_mount_always_wait=3D1 >=20 > and retrying via a USB3 port just results in: >=20 > . . . > 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. >=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 > So: same problem. >=20 > For reference, from the media being plugged into a different > aarch64 FeeBSD machine running main: >=20 > 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> >=20 > The RPi4B is of a vintage that has the "3 GiByte DMA" issue > present, not that it would be likely to be contributing here. >=20 >=20 > So I then tried the sequence using a different type of USB3 > media (also USB2 compatible), placed in a USB3 port to boot: >=20 > 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> >=20 > For this media, the sequence worked and booted successfully. >=20 >=20 > 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.) I substituted a 13-STABLE kernel.txz expansion and got the same result using that kernel. (There are not .img files for this currently.) But using: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img does not have the problem. =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?D5AEF496-4C52-4D7C-9DF3-1C6BACFDBAC1>