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

bob prohaska <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm,gmane.os.freebsd.devel.ports
Message-ID <[email protected]>
[sent also to [email protected]. If that's verboten or needless
please indicate]

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 <[email protected]>:
> > 
> > 
> >> Am 27.09.2022 um 18:03 schrieb bob prohaska <[email protected]>:
> >> 
> >> 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. 


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

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.

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?

Thanks for reading!

bob prohaska
 




>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.