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

> Am 28.09.2022 um 00:27 schrieb Mark Millard <marklmi@yahoo.com>:
> 
> On 2022-Sep-27, at 14:20, Klaus Küchemann <maciphone2@googlemail.com> wrote:
>> 
>>> Am 27.09.2022 um 22:36 schrieb Mark Millard <marklmi@yahoo.com>:
>>> 
>>> …..So, for the vintage of U-Boot source that the u-boot ports are
>>> based on, DEBUG would need to be separately defined….
>> 
>> If you mean the freebsd u-boot port, I would suggest to completely ignore older versions/vintages .
>> afaik Fbsd will not accept any device specific patch which didn’t made it (u-boot-) upstream.
>> And u-boot also won’t accept such patches if not extensively validated.
>> So you can use the port to compile but I suggest to use the master stream of u-boot as source
>> ( I think that's what you had in mind anyway)
> 
> sysutils/u-boot-* are based on:
> 
> /usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION?=      2022.04
> 
> I expect that Bob is working with that version for problem
> identification (which need not be of a U-Boot issue).
> Changes to U-Boot to improve things would be a separate
> issue --if such changes are even possible. (Bob is not that
> far along.)
> 
> My note was based on having LOG_DEBUG and DEBUG defined in a
> way that works for 2022.04 and after without having to worry
> about the status of the change in log.h .
> 
>>> Am 27.09.2022 um 22:36 schrieb Mark Millard <marklmi@yahoo.com>:
>>> 
>>> 
>>> So it may be best to always #define LOG_DEBUG in whatever
>>> *.c file(s) before the line with: #include <log.h>
>> 
>> Although that seems a bit unusual maybe u-boot planned it that way( placing the #define in line 1 of the files),I haven't investigated that yet …
>> I would begin with a simple #define DEBUG in common/usb.c and then look what happens…
>> and then I would continue with the other files you suggested if there’s no relevant output from usb.c debug…
>> using the master stream of u-boot…
> 
> Until the following are changed to have appropriate
> values at the overall configuration level, it does
> not appear that LOG_DEBUG and/or DEBUG will do
> anything:
> 
> QUOTE
> The following options are used to enable logging
> at compile time:
> 
> 	CONFIG_LOG - Enables the logging system
> 	CONFIG_LOG_MAX_LEVEL - Max log level to
> 		build (anything higher is compiled out)
> 	CONFIG_LOG_CONSOLE - Enable writing log
> 		records to the console
> END QUOTE
> 
> I expect that means having them set appropriately
> in rpi_arm64_defconfig for the experiments.
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com

I don’t expect that changes made directly in source code of a file would need to be enabled in KCONFIG or elsewhere ,
not sure and maybe `m wrong  because my last u-boot compilation is a longer while ago , but I think that #define DEBUG 
will enable console output (of course only of the debug functions in the file itself). By the way, 
nothing is bad with e.g. : /*CONFIG_LOG - Enables the logging system*/   :-)

I`m curious if you and Bob will post your 1st debug output, 
Then you can optionally ask e.g. expert  HPS to translate USB specific output ;-) 

Good luck,

Regards 

Klaus