Date: Tue, 27 Sep 2022 23:59:22 +0200 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: bob prohaska <fbsd@www.zefox.net>, Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <DCB529B2-BD2F-4630-8BEA-22608AD3FA92@googlemail.com> In-Reply-To: <20220927213342.GA72077@www.zefox.net> References: <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> <20220927213342.GA72077@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 27.09.2022 um 23:33 schrieb bob prohaska <fbsd@www.zefox.net>: >=20 > [sent also to uboot@freebsd.org. If that's verboten or needless > please indicate] Verboten :-) Ha Ha , you speak German, great ! >=20 > On Tue, Sep 27, 2022 at 08:33:33PM +0200, Klaus K??chemann wrote: >>=20 >>> Am 27.09.2022 um 19:58 schrieb Klaus K??chemann = <maciphone2@googlemail.com>: >>>=20 >>>=20 >>>> Am 27.09.2022 um 18:03 schrieb bob prohaska <fbsd@www.zefox.net>: >>>>=20 >>>> I did look at common/usb.c but it's far from obvious how one >>>> can turn on the logging feature so as to report more errors >>>> to the console. >>>=20 >>> you can add the following to common/usb.c (e.g. insert in line 44): >>>=20 >>> #define DEBUG >>>=20 >>> -- >>>=20 >>> that should then print out all debug functions inside the usb.c file = to the console=20 >>> after recompilation of u-boot. >>>=20 >>> Regards >>>=20 >>> Klaus >>=20 >> I saw there is /*#include <log.h>*/ available in usb.c=20 >> so you could also try to add : >>=20 >> #define LOG_DEBUG >>=20 >> to the common/usb.c file which should also then enable the debug = functions >> which then would be output in logging style. >>=20 >> You will need the debug output to to narrow down the issue. >>=20 > I tried running make clean, make extract, adding #define DEBUG and = #define LOG_DEBUG > at line 44 in common/usb.c, then running make from = /usr/ports/sysutils/u-boot-rpi-arm64. > The resulting u-boot.bin is still 582712 bytes, just as before. AIUI = one effect of turning > on debug is a larger executable, so it appears I'm doing something = wrong or those=20 > changes alone aren't sufficient.=20 Perhaps Mark is right that #define LOG_DEBUG has to be placed in line 1 = of the file ?=20 I didn`t investigate( all I say is from remembering past issues) . >=20 >=20 >> just a guess :=20 >> electrical problem(of the Pi itself) which could perhaps be fixed by = manipulating the scan delay time . >>=20 > Power issues don't seem prevalanet. Voltage at both the Pi3 and hub = USB > ports is never below 5.0 volts, usually around 5.15, with 5.0 at the > time of power-on and probably POST. Well, I didn=E2=80=99t mean voltage in that sense, but it=E2=80=99s = possible that the Pi3=20 has another voltage regulator chip onboard than newer PIs and that=20 this older regulator isn=E2=80=99t capable of handling power regulation = correctly(e.g. for the specific Sabrent device) .. just a guess.. >=20 > I also replaced the powered hub with a second, nominally > identical, unit. That helped, shutdown -r worked 8 tries > out of 11. This with > U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000) >=20 > Switching to a recent u-boot-rpi-arm64 seemed to > make matters much worse. Went back to the older > version of u-boot. Very interesting, to be honest: 8 tries of 11 is not really bad, so I would continue with that setup=20 For the case that it=E2=80=99s not mission critical production system = :-) >=20 > It's tempting to say the switch is the problem, but the > disk holding -current from which I copied the old u-boot=20 > booted reliably using the Pi3 and its previous hub and=20 > power supply. >=20 > That's where my question of supporting files came from. > Right now the stable-13 disk has an added > FORCE_TURBO=3D1 in config.txt, which seems to help. The > rest of the files in /booto/msdos are as provided in > the original image file. Do any of them, beyond=20 > config.txt, have an effect on u-boot's behavior? Yes, all files in boot/msdos (e.g. dtb & start.elf) related to the = device have effect on behavior=20 But I hadn`t tested that with Pi3 >=20 > Thanks for reading! >=20 > bob prohaska >=20 So maybe that trial&error by switching to older/other available = u-boot-versions or boot files may help as you said=20 But locating the real issue should only be possible by enabling debug = output =E2=80=A6 Regards=20 Klaus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DCB529B2-BD2F-4630-8BEA-22608AD3FA92>