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

On 2022-Sep-27, at 13:06, Mark Millard <[email protected]> wrote:

> On 2022-Sep-27, at 12:48, Klaus Küchemann <[email protected]> wrote:
> 
>> Am 27.09.2022 um 21:20 schrieb Mark Millard <[email protected]>:
>>> 
>>> On 2022-Sep-27, at 11:33, Klaus Küchemann <[email protected]> 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.
>>>> 
>>>> just a guess : 
>>>> electrical problem(of the Pi itself)  which could perhaps be fixed by  manipulating the scan delay time .
>>> 
>>> Looks to me like:
>>> 
>>> https://github.com/u-boot/u-boot/blob/master/common/usb_hub.c
>>> 
>>> might be relevant, not just:
>>> 
>>> https://github.com/u-boot/u-boot/blob/master/common/usb.c
>>> 
>>> 
>>> For example, usb_hub.c is where usb_pgood_delay is involved.
>>> (My patch to enable my boot media assigns that, not that
>>> such helped Bob.)
>>> 
>>> But I've not been able to uniquely identify all the specific
>>> identifiers for all the (relevant) "usb boot scan delays",
>>> although I'd expect that pgood_delay (and its usb_pgood_delay)
>>> would be considered an example.
>>> 
>>> ===
>>> Mark Millard
>>> marklmi at yahoo.com
>> 
>> good idea,
>> I would then suggest to enable debug also in common/usb_hub.c
>> by adding #define DEBUG or #define LOG_DEBUG ..
>> 
>> for the usb.c I’d expect something from the mdelay function as an usb scan timer..
>> so let’s see what debug logs  usb.c & usb_hub.c  will spit out ..
> 
> I'm not sure it would be relevant, there is also:
> 
> https://github.com/u-boot/u-boot/blob/master/common/usb_storage.c
> 
> But , unlike usb_pgood_delay that I recognized and it
> being in usb_hub.c , I've no specific identification
> of something relevant from usb_storage.c .

Also, it looks like having LOG_DEBUG force DEBUG is a recent
change for:

https://github.com/u-boot/u-boot/commits/master/include/log.h

Commits on Jul 26, 2022
log: force DEBUG when LOG_DEBUG is activated 

So, for the vintage of U-Boot source that the u-boot ports are
based on, DEBUG would need to be separately defined.

The logic in question in the modern log.h requires LOG_DEBUG to
be defined before the: #include <log.h>


include/log.h

@@ -194,6 +194,9 @@ int _log_buffer(enum log_category_t cat, enum log_level_t level,

#ifdef LOG_DEBUG
#define _LOG_DEBUG	LOGL_FORCE_DEBUG
#ifndef DEBUG
#define DEBUG
#endif
#else
#define _LOG_DEBUG	0
#endif

The inner #ifndef DEBUG related 3 lines are the new
code.

So it may be best to always #define LOG_DEBUG in whatever
*.c file(s) before the line with: #include <log.h>

Even the old logic indicates such ( _LOG_DEBUG handling ).

===
Mark Millard
marklmi at yahoo.com