Date: Mon, 19 Sep 2022 17:26:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> In-Reply-To: <20220919221553.GA33878@www.zefox.net> References: <20220919221553.GA33878@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-19, at 15:15, bob prohaska <fbsd@www.zefox.net> wrote: > Dealing with a Pi3B running stable-13, current as of today. >=20 > Root device is a USB hard drive on a powered hub, no microSD. >=20 > About half the time it boots hands-off via power cycling or > shutdown -r, other times it stops in u-boot reporting: >=20 > U-Boot 2022.04 (Sep 05 2022 - 16:28:34 -0700) >=20 > DRAM: 948 MiB > RPI 3 Model B (0xa02082) > Core: 69 devices, 10 uclasses, devicetree: board > MMC: mmc@7e300000: 2 > Loading Environment from FAT... In: serial > Out: vidconsole > Err: vidconsole > Net: No ethernet found. > starting USB... > Bus usb@7e980000: USB DWC2 > scanning bus usb@7e980000 for devices... 6 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found >=20 > This looks a bit strange, since u-boot was loaded from the USB = disk.... I have 2 directions for this . . . #0: U-Boot resets the bus, re-enumerates the devices, etc. This can time out or otherwise fail despite prior activity by the RPi* firmware that managed to use the device. My NVMe USB SSD media have such issues with RPI4B's, also getting 0 found in U-Boot. This is why I build U-Boot using the patch: # more = /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20= --- include/configs/rpi.h.orig 2022-01-22 06:03:55.862541000 -0800 +++ include/configs/rpi.h 2022-01-22 06:03:05.435341000 -0800 @@ -210,6 +210,8 @@ ENV_DEVICE_SETTINGS \ ENV_DFU_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ + "usb_pgood_delay=3D2000\0" \ + "usb_ready_retry=3D5\0" \ BOOTENV =20 =20 It may well be that the Samsung T7 Touch's are outside of the USB specifications in some way that requires such. I can not claim that U-Boot is wrong relative to the specifications. It is just that the adjustment is needed for my media. #1: I'm unsure if this applies to more than RPi4B's and the like . . . Booting an RPi* can have the clock speed(s) vary during booting and this can mess up timeouts/waits/etc. during booting, timing too early, for example. I use one of: init_turbo=3D60 # or other sufficient number of seconds or, if I'm always after turbo mode for general operation, force_turbo=3D1 in config.txt to avoid the failure. On the RPi4B's I have to boot based on both #0 and #1 being in place. Either not being in place can lead to the 0 found status. A powered hub being involved adds complications not invovled in my context. > Next: >=20 > MMC Device 0 not found > no mmc device at slot 0 > MMC Device 1 not found > no mmc device at slot 1 > Card did not respond to voltage select! : -110 >=20 > Device 0: unknown device > missing environment variable: pxeuuid > Retrieving file: pxelinux.cfg/01-b8-27-eb-ba-68-d5 > Retrieving file: pxelinux.cfg/00000000 > Retrieving file: pxelinux.cfg/0000000 > Retrieving file: pxelinux.cfg/000000 > Retrieving file: pxelinux.cfg/00000 > Retrieving file: pxelinux.cfg/0000 > Retrieving file: pxelinux.cfg/000 > Retrieving file: pxelinux.cfg/00 > Retrieving file: pxelinux.cfg/0 > Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi > Retrieving file: pxelinux.cfg/default-arm-bcm283x > Retrieving file: pxelinux.cfg/default-arm > Retrieving file: pxelinux.cfg/default > Config file not found >=20 > At this point one can enumerate the USB devices: >=20 > U-Boot> usb tree > USB device tree: > 1 Hub (480 Mb/s, 0mA) > | U-Boot Root Hub=20 > | > +-2 Hub (480 Mb/s, 2mA) > | > +-3 Vendor specific (12 Mb/s, 90mA) > | FTDI FT232R USB UART AM00KE3E > | =20 > +-4 Vendor specific (480 Mb/s, 2mA) > | =20 > +-5 Hub (480 Mb/s, 100mA) > | GenesysLogic USB2.1 Hub=20 > | > +-6 Mass Storage (480 Mb/s, 500mA) >=20 > U-Boot>=20 >=20 > The obvious oddity is that clearly a mass storage device has > been found (indeed, u-boot was started from it) but u-boot > does not recognize it as the device to boot from.=20 What the RPi* firmware does to get U-Boot in place is not used by U-Boot for its activity. The RPi* firmware need not work the same as U-Boot, allowing for differing results. > So far it appears that rebooting from multi-user via shutdown -r > works about half the time. If the disk isn't recognized, an immediate > reset command usually ends the same way. Simply waiting for 15-30 > minutes before rebooting _usually_ results in successful disk=20 > discovery and boot.=20 >=20 > Can anyone suggest simple experiments that might shed light on > what's going on? The u-boot employed was compiled from ports > and system up to date at the time. The same type of disk on a > Pi4 running -current (no powered hub needed) boots without=20 > problems.=20 I warn that my notes above are based on RPi4B activity, not RPi3B use. Also, no power hub use is involved. How much applies to your context is a valid question. =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?9A2A4E83-22F2-4441-82BF-0B8E6718ED34>