Date: Sun, 2 Oct 2022 22:46:36 +0200 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <64C1085D-D3F8-45A3-80FB-4B88F81E480E@googlemail.com> In-Reply-To: <EEC43DA1-6B68-4FDD-A68A-A3055E86E407@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> <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com> <EEC43DA1-6B68-4FDD-A68A-A3055E86E407@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 02.10.2022 um 22:18 schrieb Klaus K=C3=BCchemann = <maciphone2@googlemail.com>: >=20 >=20 >=20 >> Am 02.10.2022 um 21:58 schrieb Mark Millard <marklmi@yahoo.com>: >>=20 >> On 2022-Oct-2, at 12:35, Klaus K=C3=BCchemann = <maciphone2@googlemail.com> wrote: >>=20 >>> 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. >>=20 >> 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. >>=20 >> It is not obvious if earlier activity contributes or not >> to the problems observed after "1 Storage Device(s) found". >>=20 >> So far nothing has gotten near having things just work for >> booting without manual intervention, multiple retries >> being involved sometimes. >>=20 >>> 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 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > hard to read and remember every log but I thought Bob wrote about = aprox. 30 successful reboots after the mdelay patch, > while of course that could be coincidence, who really knows what = happens in this untrackable inconsistent behavior of the usb-boot?! >=20 >> Am 02.10.2022 um 21:48 schrieb Mark Millard <marklmi@yahoo.com>: >>=20 >> (RaspiOS and Ubuntu do not use U-Boot last I knew. So >> they do not make for good comparisons for the purpose >> as far as I know.) >=20 > RaspiOS doesn=E2=80=99t , Ubuntu(and others) use u-boot since years = =E2=80=A6 > while possible Ubuntu(or others) have own u-boot patches , > from guessing it seems more probable that they also will sometimes = hang after (re)boot. >=20 > If I would want to keep such a device as an online server, like Bob = does, for whatever reason I would=20 > Implement something like an =E2=80=9EIPMI=E2=80=9C or simpler said: > An immediate console remote access after being warned by a script that = the machine is offline. > But I would remove it from cluster if there are known Hardware = problems.=20 >=20 >=20 > Regards >=20 > Klaus >=20 >=20 =E2=80=A6 but of course, Mark, that is correct : overwriting parts of the msdos-partition by linux ones could be the last = resort to save something=E2=80=A6 but if linux had patched inside u-boot, as you did it for Bob, I would = see other problems coming=E2=80=A6 Regards Klaus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64C1085D-D3F8-45A3-80FB-4B88F81E480E>