Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2022-Sep-27, at 14:20, Klaus Küchemann <[email protected]> wrote: > >> Am 27.09.2022 um 22:36 schrieb Mark Millard <[email protected]>: >> >> …..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 <[email protected]>: >> >> >> 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