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

> Am 27.09.2022 um 23:33 schrieb bob prohaska <fbsd@www.zefox.net>:
> 
> [sent also to uboot@freebsd.org. If that's verboten or needless
> please indicate]

Verboten :-) Ha Ha , you speak German, great !

> 
> On Tue, Sep 27, 2022 at 08:33:33PM +0200, Klaus K??chemann wrote:
>> 
>>> Am 27.09.2022 um 19:58 schrieb Klaus K??chemann <maciphone2@googlemail.com>:
>>> 
>>> 
>>>> Am 27.09.2022 um 18:03 schrieb bob prohaska <fbsd@www.zefox.net>:
>>>> 
>>>> I did look at common/usb.c but it's far from obvious how one
>>>> can turn on the logging feature so as to report more errors
>>>> to the console.
>>> 
>>> you can add the following to common/usb.c (e.g. insert in line 44):
>>> 
>>> #define DEBUG
>>> 
>>> --
>>> 
>>> that should then print out all debug functions inside the usb.c file to the console 
>>> after recompilation of u-boot.
>>> 
>>> Regards
>>> 
>>> Klaus
>> 
>> I saw there is  /*#include <log.h>*/ available in usb.c 
>> so you could also try to add :
>> 
>> #define LOG_DEBUG
>> 
>> to the common/usb.c file which should also then enable the debug functions
>> which then would be output in logging style.
>> 
>> You will need the debug output to to narrow down the issue.
>> 
> I tried running make clean, make extract, adding #define DEBUG and #define LOG_DEBUG
> at line 44 in common/usb.c, then running make from /usr/ports/sysutils/u-boot-rpi-arm64.
> The resulting u-boot.bin is still 582712 bytes, just as before. AIUI one effect of turning
> on debug is a larger executable, so it appears I'm doing something wrong or those 
> changes alone aren't sufficient. 

Perhaps Mark is right that #define LOG_DEBUG has to be placed in line 1 of the file ? 
I didn`t investigate( all I say is from remembering past issues) .


> 
> 
>> just a guess : 
>> electrical problem(of the Pi itself)  which could perhaps be fixed by  manipulating the scan delay time .
>> 
> Power issues don't seem prevalanet. Voltage at both the Pi3 and hub USB
> ports is never below 5.0 volts, usually around 5.15, with 5.0 at the
> time of power-on and probably POST.

Well, I didn’t mean voltage in that sense, but it’s possible that the Pi3 
has another voltage regulator chip onboard than newer PIs and that 
this older regulator isn’t capable of handling power regulation correctly(e.g. for the specific Sabrent device)
 .. just a guess..

> 
> I also replaced the powered hub with a second, nominally
> identical, unit. That helped, shutdown -r worked 8 tries
> out of 11. This with
> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
> 
> Switching to a recent u-boot-rpi-arm64 seemed to
> make matters much worse. Went back to the older
> version of u-boot.

Very interesting, to be honest:
8 tries of 11 is not really bad, so I would continue with that setup 
For the case that it’s not mission critical production system :-)

> 
> It's tempting to say the switch is the problem, but the
> disk holding -current from which I copied the old u-boot 
> booted reliably using the Pi3 and its previous hub and 
> power supply.
> 
> That's where my question of supporting files came from.
> Right now the stable-13 disk has an added
> FORCE_TURBO=1 in config.txt, which seems to help. The
> rest of the files in /booto/msdos are as provided in
> the original image file. Do any of them, beyond 
> config.txt, have an effect on u-boot's behavior?

Yes, all files in boot/msdos (e.g.  dtb & start.elf) related to the device have effect on behavior 
But I hadn`t tested that with Pi3

> 
> Thanks for reading!
> 
> bob prohaska
> 

So  maybe that trial&error by switching to older/other available u-boot-versions or boot files may help as you said 
But locating the real issue should only be possible by enabling debug output …


Regards 

Klaus