Date: Tue, 27 Sep 2022 15:27:10 -0700 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com> In-Reply-To: <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com> References: <20220921154240.GA37735@www.zefox.net> <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com> <20220921175026.GA45144@www.zefox.net> <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com> <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com> <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net> <DBD238AA-8C65-46D2-87CC-A9875C6959BF@yahoo.com> <20220925193415.GA63733@www.zefox.net> <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com> <20220927160328.GA71742@www.zefox.net> <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com> <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com> <D8708275-D396-4D2F-9461-B305E522BCCE@yahoo.com> <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com> <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com> <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com> <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-27, at 14:20, Klaus K=C3=BCchemann = <maciphone2@googlemail.com> wrote: >=20 >> Am 27.09.2022 um 22:36 schrieb Mark Millard <marklmi@yahoo.com>: >>=20 >> =E2=80=A6..So, for the vintage of U-Boot source that the u-boot ports = are >> based on, DEBUG would need to be separately defined=E2=80=A6. >=20 > 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=E2=80=99= t made it (u-boot-) upstream. > And u-boot also won=E2=80=99t 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?=3D = 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>: >>=20 >>=20 >> So it may be best to always #define LOG_DEBUG in whatever >> *.c file(s) before the line with: #include <log.h> >=20 > 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 =E2=80=A6 > I would begin with a simple #define DEBUG in common/usb.c and then = look what happens=E2=80=A6 > and then I would continue with the other files you suggested if = there=E2=80=99s no relevant output from usb.c debug=E2=80=A6 > using the master stream of u-boot=E2=80=A6 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B>