Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
- Reply: Klaus_Küchemann : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- Reply: bob prohaska : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- In reply to: Klaus_Küchemann : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 27 Sep 2022 22:27:10 UTC
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