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

On Sat, Oct 01, 2022 at 11:32:52AM -0700, Mark Millard wrote:
> On 2022-Oct-1, at 10:47, bob prohaska <[email protected]> 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. 

> > 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. 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-)

Thanks for all your help!

bob prohaska