Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Oct 2022 12:58:00 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>, freebsd-uboot@freebsd.org
Subject:   Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
Message-ID:  <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
In-Reply-To: <20221001193033.GA98348@www.zefox.net>
References:  <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com> <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com> <20220928234341.GA77046@www.zefox.net> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Oct-1, at 12:30, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Oct 01, 2022 at 11:32:52AM -0700, Mark Millard wrote:
>> On 2022-Oct-1, at 10:47, bob prohaska <fbsd@www.zefox.net> wrote:
>>=20
>>=20
>> Wrong email for the patch in question. Wrong patch used
>> as well? (Actually, the log output still has the high
>> volume debug(...) messagess, so you did not use the patch
>> from the email that you replied to.)
> That's possible....
>>=20
>> The email with the patch is Friday's 12:58 PM email about
>> the patching involving 3 mdelay(...) calls.
>>=20
> At this stage that's possible too 8-(
>=20
> Right now sysutils/u-boot-rpi-arm64/files contains
> root@pelorus:/usr/ports/sysutils/u-boot-rpi-arm64/files # ls -l
> total 24
> -rw-------  1 root  wheel  964 Oct  1 09:39 patch-common_usb.c=20
>=20
> which contains 3 references to mdelay.=20
>=20
> -rw-------  1 root  wheel  382 Sep 28 21:31 patch-common_usb__hub.c
> -rw-------  1 root  wheel  362 Sep 28 21:31 =
patch-common_usb__storage.c
> -rw-------  1 root  wheel  291 Sep 28 21:31 =
patch-include_configs_rpi.h
> -rw-r--r--  1 root  wheel  510 Jul 24 09:31 =
patch-lib_efi__loader_efi__console.c
> -rw-r--r--  1 root  wheel  169 Sep 30 18:57 rpi_arm64_fragment
>=20
> If the sizes/dates are right maybe I copied the wrong u-boot.bin to =
/boot/msdos.
> If they're wrong a batch send of preferred patches is probably the =
best
> way to put things right.=20

What you report for behavior below suggests that you got
an appropriate u-boot.bin in place.

>>> In testing the patch thee seem to be more cases of u-boot getting
>>> stuck in a loop, not all of the identical.=20
>>>=20
>>> The first in the script file left the disk LED stuck on with=20
>>> error 22 prominent, the second left the disk LED stuck off,=20
>>> with error 110 repeating.
>>>=20
>>> The script file is at=20
>>> http://nemesis.zefox.com/~fbsd/
>>> in file pelorus_console.txt5_concise_loop_fails
>>>=20
>>=20
>> As I understand the possible result of the intended
>> patch is it might avoid the "0 Storage Device(s)
>> found" problem but need not avoid the later -110 -22
>> error code related problems.
>>=20
>> So if you no longer get "0 Storage Device(s) found"
>> problems, that is progress/good, independent of any
>> later issues. Otherwise the mdelay(...) changes are
>> probably a waste and would just be reverted.
>>=20
>=20
> Out of the last 24 boot attempts there have been 6
> loops and no failures to find a boot device.

Given the "no failures to find a boot device",
I suggest an experiment of (temporarily?)
reverting to the official rpi_arm64_fragment
(to disable the U-Boot logging) and seeing how
it behaves without the extra messages.

The timing changes from the messages could be
contributing to some of the behaviors you are
seeing.

> The
> log file is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt6_more_loops=20
>=20
>> It might not be handy to test lots of examples of
>> the "Storage Device(s) found" messages, independent
>> of what follows each non-zero one. But that is the
>> kind of thing needed to test the consequences of
>> the 3 mdelay(...) calls.
>=20
> It's one of the few things I'm marginally capable of 8-)


=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?46226720-D867-4AD3-9559-A4365FAC28C4>