Date: Sun, 2 Oct 2022 12:58:35 -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: <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com> In-Reply-To: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com> References: <20220929002131.GA77106@www.zefox.net> <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com> <A8C2BA4E-4520-4B34-9614-DDC4D8BEB097@yahoo.com> <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com> <E3A1C678-8C47-4283-9F9F-4C9011DB8A2B@yahoo.com> <20221001174724.GA98055@www.zefox.net> <ABFDD634-5CB6-4DAE-B4DE-629CE7E4FE06@yahoo.com> <20221001193033.GA98348@www.zefox.net> <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com> <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com> <20221002182049.GA2255@www.zefox.net> <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Oct-2, at 12:35, Klaus K=C3=BCchemann = <maciphone2@googlemail.com> wrote: > Am 02.10.2022 um 20:20 schrieb bob prohaska <fbsd@www.zefox.net>: >>=20 >> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote: >>>=20 >>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment >>>=20 >>> still shows all the debug output. It did not >>> avoid the timing changes. >>>=20 >>> You might need to not use either of: >>>=20 >>> patch-common_usb__hub.c >>> patch-common_usb__storage.c >>>=20 >>> and to disable the LOG_DEBUG and DEBUG lines in: >>>=20 >>> patch-common_usb.c >>>=20 >>> via turning them into comments by adding // as >>> indicated below: >>>=20 >>> +//#define LOG_DEBUG >>> +//#define DEBUG >>>=20 >>=20 >> I think the changes were successful, u-boot compiles and >> runs. There's no extra output, and unfortunately only one=20 >> successful reboot so far. Bus scanning seems quite slow. >> Storage devices are rarely found on reset, but usb reset >> does sometimes work. Run bootcmd_usb0 paused for minutes >> at Device 0: and paused again after reporting ..current device. >> No echo from the console, ctrl-C did nothing.=20 >>=20 >> The attempt sequence was >> SRBSPRMRPRRPUPPRRUPUCUUC >> where=20 >> S is shutdown -r >> R is reset of u-boot >> U is usb reset >> P is powercycle >> M is stop at mountroot >> C is run bootcmd_usb0 >>=20 >> The console log is at >> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug >>=20 >> It now appears that the run bootcmd_usb0 rather reliably gets >> stuck, with the disk LED on steadily (no activity). Maybe in >> one of the loops seen earlier?=20 >>=20 >> Thanks again for all your help! >>=20 >> bob prohaska >>=20 >=20 >=20 > So if you now reapply the #define DEBUG patches(while keeping the = mdelay-patch) and the reboot issues definitely went away > we have a typical so called Heisenbug, hopefully more or less now a = fixed issue. No. Bob has more than one problem: more problems observed after "1 Storage Device(s) found". The DEBUG/mdelay combination only seemed to cause the "1 Storage Device(s) found" to be at least more reliable, not later stages. It is not obvious if earlier activity contributes or not to the problems observed after "1 Storage Device(s) found". So far nothing has gotten near having things just work for booting without manual intervention, multiple retries being involved sometimes. > Well, USB-boot problems on earlier Pi models( afaik all except the 4) = are commonly known, from defective HW to power cycle issues we will find = a lot of discussions on the WWW and we will see that even the = debug-message =E2=80=9Eis your USB cable bad?=E2=80=9C did fix issues = in some cases. Others applied RNG devices or external clock or even = plugging a mouse fixed it( to change usb enumeration). >=20 > I think with the working u-boot.bin after 1500 successful reboots you = can be sure it=E2=80=99s working =E2=80=A6. > just kidding=E2=80=A6 :-) >=20 =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?38DFEB91-AC60-4FD1-8088-95B0A06C5E5D>