Date: Sun, 2 Oct 2022 21:35:42 +0200 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: bob prohaska <fbsd@www.zefox.net>, Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com> In-Reply-To: <20221002182049.GA2255@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 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. 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). 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 :-) Regards Klaus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5FFDAA6A-AD8C-4E40-A2EB-4082E5086679>