Date: Thu, 22 Sep 2022 19:11:18 -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: <280D9065-A158-4E52-AA18-CA2CB1C247AC@yahoo.com> In-Reply-To: <20220922014500.GA46697@www.zefox.net> References: <20220919221553.GA33878@www.zefox.net> <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> <20220921154240.GA37735@www.zefox.net> <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com> <20220921175026.GA45144@www.zefox.net> <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com> <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com> <20220922014500.GA46697@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-21, at 18:45, bob prohaska <fbsd@www.zefox.net> wrote:
> On Wed, Sep 21, 2022 at 01:27:45PM -0700, Mark Millard wrote:
>> I used:
>>=20
>> tar -xf /usr/ports/distfiles/u-boot/u-boot-2022.04.tar.bz2 =
u-boot-2022.04/include/configs/rpi.h
>>=20
>> to create a local u-boot-2022.04/include/configs/rpi.h
>> in order to look at the modern file. The
>> ENV_DEVICE_SETTINGS line from:
>>=20
>> #define CONFIG_EXTRA_ENV_SETTINGS \
>> "dhcpuboot=3Dusb start; dhcp u-boot.uimg; bootm\0" \
>> ENV_DEVICE_SETTINGS \
>> ENV_DFU_SETTINGS \
>> ENV_MEM_LAYOUT_SETTINGS \
>> BOOTENV
>>=20
>> appears to be at line 173.
>>=20
>> A correct patch file finds the matching lines despite the
>> difference in line numbers, a difference that is not too
>> large by its matching criteria (given correct text matches).
>>=20
>> The modern FreeBSD lists might allow text attachments so
>> I'll try that publicly. (It still has the 210 line number.)
>>=20
> The patch emailed as an attachment applied without a problem.
> Better still, it seemed to help with mass storage device discovery
> for the first five or so tries. Around try six, the system lost
> the ability to recognize the USB mass storage device and then
> seemed to get stuck in a loop, with repeated attempts failing.=20
>=20
> After setting initial_turbo=3D60 in config.txt the first reboot
> found the disk, the second did not. Running usb reset then
> found the disk, but run bootcmd_usb0 seemingly caused a reset
> that _then_ found the disk.=20
>=20
> The display of usb tree output isn't always the same. On a failed try =
it=20
> looked like
> 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)
> JMicron =20
>=20
> On a successful try it looked like=20
> scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot: 0=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 Hub (480 Mb/s, 100mA)
> | | GenesysLogic USB2.1 Hub=20
> | |
> | +-6 Mass Storage (480 Mb/s, 500mA)
> | JMicron SABRENT 000000000000A
> | =20
> +-4 Vendor specific (12 Mb/s, 90mA)
> | FTDI FT232R USB UART AM00KE3E
> | =20
> +-5 Vendor specific (480 Mb/s, 2mA)
>=20
> Not sure if this is even relevant, but it does seem odd.
>=20
(Response delayed by an OS upgrade mess [not FreeBSD].)
As I understand it USB* standards do not define a stable
order for devices to enumerate. So even if all the boots
worked, if you had a record of the "USB device tree" for
each you would likely find that the trees varied in what
the numbering (and, so ordering) was.
More significant might be the distinction:
Mass Storage (480 Mb/s, 500mA)
JMicron
vs.
Mass Storage (480 Mb/s, 500mA)
JMicron SABRENT 000000000000A
where the one that does not say "SABRENT 000000000000A"
(less information) is the one that failed. Seems like
it could not complete its SABRENT related activity
successfully/completely even though the rest of the
tree looks normal (ignoring numbering/ordering).
Overall your description seems to be "still varies
based on a seemingly random basis" and the problem
was not fixed by the patch / initial_turbo
combination. It does not even seem obvious that a
long run failure rate would be noticeably improved.
The "SABRENT" aspect might be the only part that is
varying in a manor that matters. But I do not know
what to do to investigate that aspect.
=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?280D9065-A158-4E52-AA18-CA2CB1C247AC>