Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

On 2022-Sep-27, at 19:13, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Sep-27, at 18:57, bob prohaska <fbsd@www.zefox.net> wrote:
> 
>> On Tue, Sep 27, 2022 at 05:14:54PM -0700, Mark Millard wrote:
>>> On 2022-Sep-27, at 16:29, bob prohaska <fbsd@www.zefox.net> wrote:
>>> 
>>>> On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
>>>>> . . .
>>>> . . .
>>>> U-Boot> usb reset
>>>> resetting USB...
>>>> Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
>>>> USB DWC2
>>>> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>>>>     scanning usb for storage devices... 1 Storage Device(s) found
>>>> U-Boot> 
>>>> 
>>>> Issuing
>>>> U-Boot> run bootcmd_usb0
>>>> 
>>>> Device 0: 
>>>> 
>>>> [tens of seconds pause, looks like u-boot started over]
>>>> 
>>>> U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)
>>> . . .
>>> 
>>> Do you have RPi* firmware debug output ennabled such that
>>> you would see messages from it if the RPi* firmware started
>>> over?
>>> 
>> I do now, enable_uart=1 is set in config.txt
> 
> Good.

Beyond enable_uart=1 there is, quoting from:

https://github.com/raspberrypi/firmware/issues/1301

QUOTE
"uart_2ndstage=1" causes the second-stage loader (bootcode.bin, Pi 4 EEPROM) and the main firmware (start*.elf) to output diagnostic information to UART0. Output is likely to interfere with Bluetooth operation unless disabled ("dtoverlay=disable-bt") or switched to the other UART ("dtoverlay=miniuart-bt"), and if the UART is accessed simultaneously to output from Linux then data loss could occur, so this is not a feature to activate except when trying to diagnose a loading problem.
END QUOTE

It is possible that this extra output might put
out messages about watchdog activity if such is
involved in the restarts.

For the current purposes, dtdebug=1 probably does
not provide anything of interest. But it is
available to enable as well.


===
Mark Millard
marklmi at yahoo.com