Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

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:
>> 
>> 
>> 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....
>> 
>> The email with the patch is Friday's 12:58 PM email about
>> the patching involving 3 mdelay(...) calls.
>> 
> At this stage that's possible too 8-(
> 
> 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 
> 
> which contains 3 references to mdelay. 
> 
> -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
> 
> 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. 

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. 
>>> 
>>> The first in the script file left the disk LED stuck on with 
>>> error 22 prominent, the second left the disk LED stuck off, 
>>> with error 110 repeating.
>>> 
>>> The script file is at 
>>> http://nemesis.zefox.com/~fbsd/
>>> in file pelorus_console.txt5_concise_loop_fails
>>> 
>> 
>> 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.
>> 
>> 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.
>> 
> 
> 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 
> 
>> 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.
> 
> It's one of the few things I'm marginally capable of 8-)


===
Mark Millard
marklmi at yahoo.com