Date: Fri, 30 Sep 2022 12:37:00 -0700 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <4C6619C8-CE5A-4B3A-84F0-2F02BC2ED4D2@yahoo.com> In-Reply-To: <A2D394A3-8382-4EB2-A697-8A3D5F2687A2@googlemail.com> References: <A8C2BA4E-4520-4B34-9614-DDC4D8BEB097@yahoo.com> <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com> <E3A1C678-8C47-4283-9F9F-4C9011DB8A2B@yahoo.com> <20220929054120.GA77803@www.zefox.net> <D7A62820-4928-49F0-8387-C1E6D998B121@yahoo.com> <ABFBD0E6-8A9B-4C99-84DF-BF398F23678A@yahoo.com> <20220929151926.GA80020@www.zefox.net> <F316420B-C7AF-4131-9734-06117FFE212D@yahoo.com> <20220929170927.GB80020@www.zefox.net> <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com> <20220930002742.GA81169@www.zefox.net> <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com> <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com> <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com> <ED81813C-6F25-4751-BBCA-BC711684B219@yahoo.com> <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com> <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com> <A2D394A3-8382-4EB2-A697-8A3D5F2687A2@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-30, at 12:02, Klaus K=C3=BCchemann =
<maciphone2@googlemail.com> wrote:
> Am 30.09.2022 um 20:36 schrieb Mark Millard <marklmi@yahoo.com>:
>>=20
>> Which "the"? The Hub in question is internal to the
>> RPi3B. It also shows up on my RPi3B with no external
>> hubs involved. (But I've never had the failure mode
>> occur.)
>>=20
>> Manufacturer=20
>> Product U-Boot Root Hub
>> SerialNumber=20
>> bind node usb1@1
>>=20
>> It is a hub with 5 ports, one associated with the
>> EtherNet port and 4 for plugging things in. Or,
>> that is my understanding.
That description is a little abbreviated, skipping
a stage of hub. =46rom the RPi3B that I have access
to, with only a couple of USB ports with devices
plugged in (so some ports not showing):
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 (480 Mb/s, 2mA)
| =20
+-4 Mass Storage (480 Mb/s, 500mA)
Samsung PSSD T7 Touch ***REPLACED***
Bob had reported seeing:
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
and:
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)
that are the same up to permuting which device
goes with which of 3,4,5. (The 3,4,5 being the
numbers directly under 2 is stable.)
> :-), I started reading the discussion from the beginning because I =
missed the Hub-manufacturer in the logs,
> Now I know it=E2=80=99s the internal, thanks for Info .
> I was absolutely sure from the beginning that this is a =
3b-power-issue (regulator or whatever)=E2=80=A6
> I guess you also wrote that.
I treat it as a possibility. I'm not aware of a
good way to get solid evidence indicating one
way vs. the other.
> Since my lowest model is 3b+, I never turned on any RPI during this =
discussion.
>=20
>>=20
>> I've little clue what would interfere with its
>> operation in this specific way.
>=20
> =46rom reading the logs we end up in line 377 of common/usb_hub.c :
> 'cannot reset port=E2=80=98
> The comment beginning in line 305 indicates that perhaps more attempts =
of a reset=20
> could work around mysterious power or disconnect issues( although for =
nVidia not rpi).
> So by guessing I would say, a code injection of reset retries could =
perhaps help,
FYI: Bob is using my rpi.h patch that enables my
devices. It has a usb_ready_retry in addition to
the usb_pgood_delay:
# 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
I've never checked if my booting would by just as
reliable without the usb_ready_retry . Both usb_*'s
are from one suggestion I found on the web and I did
not explore further once booting worked well.
> I would ask a long year known USB-expert if it=E2=80=99s worth to try =
hacking usb_hub.c=20
> but it=E2=80=99s better not to call his name so loud again :-) =E2=80=A6=
HPS is aware of this issue and of the exchange, and
has commented earlier on --about how port numbering
works (at least in one particular library).
I'm also not sure that Bob would want to maintain
his own patching for sysutils/u-boot-rpi-arm64 as
it progresses U-Boot versions over time. If all
potential changes were not up-streamable, I do not
know what Bob would choose to do.
=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?4C6619C8-CE5A-4B3A-84F0-2F02BC2ED4D2>