Date: Mon, 7 Jun 2021 13:09:52 -0700 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <AE504C28-E8B1-4633-9A23-18C02457CD7E@yahoo.com> In-Reply-To: <20210607184016.GA11184@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> <20210607184016.GA11184@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jun-7, at 11:40, bob prohaska <fbsd at www.zefox.net> wrote: > On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via freebsd-arm = wrote: >>=20 >>=20 >> On 2021-Jun-6, at 09:00, bob prohaska <fbsd at www.zefox.net> wrote: >>=20 >>>=20 >>> It's a dual-boot system, with a complete FreeBSD-current install >>> on both USB and microSD storage.=20 >>=20 >> How do you control which device provides kernel+world >> if both have a kernel_world? >>=20 >=20 > If the machine is powered up and not touched, it boots from the > microSD card. If boot is interrupted at the u-boot prompt it's > (was) possible to issue a=20 > usb reset > command, at which point the external USB hard drive was discovered. > At that point issuing a=20 > run bootcmd_usb0 > command would boot kernel and mount world from the USB device.=20 I see I force to to tell me what you had already reported. Sorry for that. As for your manual usb commands . . . Looking around on the web I see reports of the: Request Sense returned 02 04 01 (and the matching Device NOT ready) mean that the problem will occur and that repeating usb start or usb reset again until it does not report that leads to things working. But I've also seen other, more complete information indicating that there is a environment setting (showing an example value): usb_ready_retry=3D5 to set up before the usb restart (or usb start) command. It deals with the issue more explicitly for slow devices. Another one is (units: msec): usb_pgood_delay=3D10000 There are also device that have problems with large transfers and require extra protocol to deal with transfer problems before they will work again, U-Boot not doing that. usb_max_blk=3D20 sets a old historical value that generally just works for such devices form what I read. I see no indication that other usb commands are worthwhile until one has avoided that "Request Sense returned 02 04 01" message for usb reset (a.k.a. usb start). The reports of this sort of thing are not limited to RPi's and go back to at least 2014. If I understand correctly, usb_ready_retry and usb_pgood_delay and usb_max_blk are part of normal U-Boot builds these days. But I'm not certain of that. I will note: QUOTE Common USB Commands: - usb start: - usb reset: (re)starts the USB. All USB devices will be initialized and a device tree is build for them - usb tree: shows all USB devices in a tree like display . . . Storage USB Commands: - usb scan: scans the USB for storage devices.The USB must be running for this command (usb start) . . . END QUOTE Note that the wording indicates that having the tree is not the same as having classified the storage devices: storage classification is an seprate step. "usb reset" seems to automatically do a scan. But, still, the tree listing things that "usb storage" or "usb part" would not is apparently normal util after a successful "usb scan" has occured (possibly automatically executed). >> I suggest trying the same vintage that is on 13.0-RELEASE's >=20 > I've written the 13.0-release image to a microSD card and tried > that. It reports a version of > U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >=20 > Stopped at the u-boot prompt and given the=20 > usb reset command, zero storage devices are found. However, > usb tree still reports >=20 > 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 AM00FGTR > | =20 > +-4 Vendor specific (480 Mb/s, 2mA) > | =20 > +-5 Mass Storage (480 Mb/s, 0mA) > ASMT ASM105x 12345678D558 >=20 > The mismatch between what usb reset and usb tree report strikes me > as extremely puzzling. See my earlier notes about tree vs. storage and part information. > As an experiment, I tried booting with no microSD card installed at > all. This got confusing; u-boot still came up, apparently from the > USB hard drive. The RPi internal code is handling the USB drive initially and loading the RPifirmware from the USB drive. That firmware is in turn loading U-Boot in this case. It is when U-Boot tries to take over and set up the USB drive for its own use that things are having the problem. > The USB disk is still not found by usb scan, but it=20 > is recognized by usb tree.=20 See the earlier notes about tree vs. storage and part information. > As a final test I tried connecting a monitor that had been used with=20= > this Pi previously. The monitor's presence made no difference, the > display looked normal. =20 >=20 > A hands-off boot to single user is successful from the microSD card.=20= > It's possible to see and access the USB hard drive.=20 This sequence by-passes U-Boot having to have usb storage operational. The FreeBSD kernel is better behaved for handling the properties of your devices involved. > At this point I'm beginning to suspect some obscure mischief with the > USB-SATA adapter, based only on earlier intermittent problems = detecting > the USB hard drive. In those cases a few repeats of usb scan found > the disk and allowed booting from it. =20 But did the problem cases show: Request Sense returned 02 04 01 or: Device NOT ready ? Or were such details different? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE504C28-E8B1-4633-9A23-18C02457CD7E>