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

On 2022-Oct-1, at 10:47, bob prohaska <fbsd@www.zefox.net> wrote:

> On Wed, Sep 28, 2022 at 10:10:20PM -0700, Mark Millard wrote:
>> On 2022-Sep-28, at 20:31, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>>> . . .
>>> 
>>> It looks like that if you remove files/patch-common_usb__storage.c
>>> and rebuild/install the large output reporting usb reads will not
>>> happen.
>>> 
>> 
>> I've included a patch-common_usb__storage.c that comments out
>> the few high volume debug(...) instances but leaves the rest
>> in place. A dozen or so lines are still output via this source
>> file now and I was not sure if any might prove important. So
>> this way they are present to consider if this file is used
>> in the build.
>> 
> 

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

The email with the patch is Friday's 12:58 PM email about
the patching involving 3 mdelay(...) calls.

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

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.

===
Mark Millard
marklmi at yahoo.com