Date: Wed, 28 Sep 2022 01:15:49 +0200 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: Mark Millard <marklmi@yahoo.com>, 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: <F75EA98D-6B3E-4225-B40D-DA4E211ED641@googlemail.com> In-Reply-To: <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.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> <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 28.09.2022 um 00:27 schrieb Mark Millard <marklmi@yahoo.com>: >=20 > 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) >=20 > sysutils/u-boot-* are based on: >=20 > /usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION?=3D = 2022.04 >=20 > 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.) >=20 > 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 . >=20 >>> 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 >=20 > 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: >=20 > QUOTE > The following options are used to enable logging > at compile time: >=20 > 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 >=20 > I expect that means having them set appropriately > in rpi_arm64_defconfig for the experiments. >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com I don=E2=80=99t 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=20 will enable console output (of course only of the debug functions in the = file itself). By the way,=20 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,=20 Then you can optionally ask e.g. expert HPS to translate USB specific = output ;-)=20 Good luck, Regards=20 Klaus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F75EA98D-6B3E-4225-B40D-DA4E211ED641>