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

On 2022-Oct-2, at 11:20, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
>> 
>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>> 
>> still shows all the debug output. It did not
>> avoid the timing changes.
>> 
>> You might need to not use either of:
>> 
>> patch-common_usb__hub.c
>> patch-common_usb__storage.c
>> 
>> and to disable the LOG_DEBUG and DEBUG lines in:
>> 
>> patch-common_usb.c
>> 
>> via turning them into comments by adding // as
>> indicated below:
>> 
>> +//#define LOG_DEBUG
>> +//#define DEBUG
>> 
> 
> I think the changes were successful, u-boot compiles and
> runs. There's no extra output, and unfortunately only one 
> 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. 
> 
> The attempt sequence was
> SRBSPRMRPRRPUPPRRUPUCUUC
> where 
> 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
> 
> The console log is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug
> 
> 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? 

Of 27 " Storage Device(s) found" notices:

18 are: "0 Storage Device(s) found".
 9 are: "1 Storage Device(s) found".

so the 3 mdelay(...) lines are far from sufficient for
that issue. I see no way to tell if some variation of
them (different delays and/or a subset of the 3) is
somehow necessary.

It would seem that some of the delays from the debug
output to the console were an essential part of the
prior lack of examples of "0 Storage Device(s) found".

I'm not worrying about what happens after " Storage
Device(s) found" so long as "0 Storage Device(s) found"
is still an issue for one or both of:

0x152d:0x0577
0x152d:0x0583

In part that is because, for all I know, the source of
the earlier problem might well also contribute to the
later problem(s), even when "1 Storage Device(s) found"
happens.

If the build had the adjusted mdelay and the 2 additional
mdelay calls in place, it is not obvious if they should
be kept or not.



Fedora 37 is in Beta currently and is supposed to be
final in late October or so. It is the first Fedora
version to officially support RPi4B's, now that it
has accelerated display support and the like.

Fedora (older and 37) uses U-Boot for how it boots
RPi*'s. If you had the resources, I'd suggest producing
Fedora-based media and seeing if it has the same sort of
U-Boot-stage problems in your device-types context.
(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.)



I'm going to provide notes below about how I produced the
patch-common_usb*.c files. The sysutils/u-boot-rpi-arm64
port did/does not already have patches for these files.

I build via poudriere, not via use of /wrkdirs/ . . . so I can use
/wrkdirs/ . . . as an area to look at source code without needing
to worry about building the port in there. Starting with a /wrkdirs
that did not contain a /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/
I did:

# make -C /usr/ports/sysutils/u-boot-rpi-arm64/ extract

to populate /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/ .

I then made copies of the sources that I was going to change,
adding a .orig suffix to the names of the copies. Showing the
resulting paths:

# find -s /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/ -name '*.orig' -print
/wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/usb.c.orig
/wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/usb_hub.c.orig
/wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/usb_storage.c.orig

The copies were made via:

# cd /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/
# cp -aRx common/usb.c         common/usb.c.orig
# cp -aRx common/usb_hub.c     common/usb_hub.c.orig
# cp -aRx common/usb_storage.c common/usb_storage.c.orig

(-aRx use is just habitual for me.)

I then made changes to the 3 common/usb*.c versions of those files,
editing not shown here.

After that I produced the patch files via:

# diff -u common/usb.c.orig common/usb.c         > /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb.c
# diff -u common/usb.c.orig common/usb_hub.c     > /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__hub.c
# diff -u common/usb.c.orig common/usb_storage.c > /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__storage.c

Doing the diff from work/u-boot-2022.04/ with the common/ part of
the paths being explicit is important to the content produced in
te patch-* files.

The "_" vs. "__" use after  "patch-" is important in
the patch-* names:

"_"  is used where a "/"                  is in the original path.
"__" is used where just one "_" by itself is in the original path.

The FreeBSD ports infrastructure does the translations
to produce the parts of the final path needed.

===
Mark Millard
marklmi at yahoo.com