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

On 2022-Sep-27, at 18:57, bob prohaska <[email protected]> wrote:

> On Tue, Sep 27, 2022 at 05:14:54PM -0700, Mark Millard wrote:
>> On 2022-Sep-27, at 16:29, bob prohaska <[email protected]> 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.

>> In other words, can you tell if . . .
>> 
>> A) The RPi* firmware and then U-Boot both restarted
>> vs.
>> B) Just U-Boot restarted, not the RPi* firmware?
>> 
>> If you can tell, which was it?
>> 
> Looks to me as if A) is the case. After the 
> 
> Device 0:
> 
> line comes 
> 
> Raspberry Pi Bootcode

That indicates that U-Boot did not initiate the reboot
of the RPi3B: there should have been messages from
U-Boot for it being about to make such a request.

This again looks like a possible power problem where the
RPi3B uncontrollably restarts. Even a very short power
problem can lead to such.

Another possibility is if the RPi3B firmware has a
watchdog running that initiated the reset after
something took too long in the watchdog's protocol
for monitoring progress/activity.

I do not know a way to get evidence for which.

> Read File: config.txt, 239
> Read File: start.elf, 2952960 (bytes)
> Read File: fixup.dat, 7314 (bytes)
> MESS:00:00:21.191824:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:21.196253:0: brfs: File read: 239 bytes
> MESS:00:00:21.252921:0: HDMI0:EDID error reading EDID block 0 attempt 0
> 
> The machine is headless, so I think the HDMI errors are normal.

Yep.

> Following the self-inflicted reboot the machine reached multi-user.
> 
> I'll see if I can figure out how to apply your patches shortly.

Like when you tried my usb_pgood_delay related patch,
you put the files in the files/ directory, allowing
the one replacement to happen. (I do not cover the
attachment to file conversion part of the sequencing
for your context. As I understand it went fine last
time.)

===
Mark Millard
marklmi at yahoo.com