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

On 2022-Oct-5, at 19:38, bob prohaska <fbsd@www.zefox.net> wrote:

> On Tue, Oct 04, 2022 at 11:27:00PM -0700, Mark Millard wrote:
>> 
> [big snip] 
>> On a possible issue: You have
>> 
>> ugen1.6: <FTDI FT232R USB UART> at usbus1
>> 
>> plugged in.
>> 
> [snip] 
>> It might be worth experimenting with
>> avoiding having more plugged in than:
>> 
>> Boot USB drive (I count your powered hub as part of this)
>> Ethernet cable
>> serial console connection
>> fan
>> power
> 
> The buildworld/kernel completed without issue and it seemed
> to help. Immediately afterward the machine reached
> S=shutdown, M=mountroot, F=disk detect fail, R=reset
> 
> SSMSSSSMSSSF
> Next I set device tree only, per your instructions and it reached
> RSFRFRFR so I tried ACPI only, reaching
> FR so I put back DT+ACPI, with result
> SMMRSSMSSSSSSSMFRS at which time I pulled out the FT232 usb-serial link.
> 
> That reached 
> SSMSSSMSSMMMSSFFSFSSSFSSS
> 
> Looks to me like pulling the FT232 didn't help, DT+ACPI works better
> than either alone.
> 
> 35 shutdown -r
> 10 mountroot failures
> 9 disk detection failures

I did not get a total count match so I
worked it though. . .

ACPI+DT  (broken up for easier  counting):
SSMSS SSMSS SF                 (S: 9, M:2, F:1, R:0)
SMMRS SMSSS SSSSM FRS          (S:11, M:4, F:1, R:2)
SSMSS SMSSM MMSSF FSFSS SFSSS  (S:16, M:5, F:4, R:0)
So: 5*10+2+3 == 55

But: 35+10+9 == 54

Totaling:

S: 9+11+16 == 36
M: 2+ 4+ 5 == 11
F: 1+ 1+ 1 ==  6
R: 0+ 2+ 0 ==  2

36+11+6+2 == 30+10+(6+1+6+2) == 55

It looks like:

S:   shutdown -r
M:   mountroot failures
F+R: "disk detection failures"

(That last was not clear to me on its own.)

I'll note that I'd sent a note about a commit to main
that might change the FreeBSD kernel time-frame failures.
It shows a 1 week MFC for if things go well for it.

> That's actually pretty good for the JMS577 enclosure. The world/kernel
> upgrade to stable/13-5ec288b57: Wed Oct  5 16:55:43 PDT 2022 seems
> to have been helpful (not sure why), omitting the FT232 didn't help
> much, if at all. 
> 
> Compared to yesterday I'm tempted to call it progress.

There are two widely different stages getting
failures:

Pre-kernel (so: U-Boot or EDK2 --or even RPi* firmware)
Kernel

Thus, any overall solution still using the 0x0577
(if there is such) has fixes or work arounds in
multiple places/stages. Any that are just work
arounds that are not committed end up having to be
locally maintained to keep the 0x0577 "solved"
status.

The same sort of thing applies to incomplete
workarounds that just make the 0x0577 results
better but still sometimes failing.

There is still the question of if the 0x0577 is
well behaved (or much better behaved) on a RPi4B.
If it is, then enclosure swapping might be
relevant.

> One thing I forgot to mention:
> 
> The microSD formerly hosted a RasPiOS installation. I simply
> cleaned out the DOS partition and installed the EDK2 files.
> At one point during buildworld I ran gstat and saw reports
> of zero activity for the microSD partitions. I didn't think
> the kernel would even notice them. Is that to be expected?

gpart show shows all the partitions/slices. gstat
can fairly generally list what gpart shows --and
more. Device I/O to all partitions is possible,
even for partitions for which the contained file
system (if any) is not supported.

gstat with what options? The following are rather
different in what is listed:

# gstat -p  # (Physical/rank-1 providers, basically: devices)
# gstat     # (all providers, includes partition/slice naming based rows)
              (Note: GPT freebsd-zfs partitions do not show gpt/LABEL,
               at least if they are in use as boot partitions)
# gstat -pc # (Physical/rank-1 providers --and all the consumers)
# gstat -c  # (all providers and all consumers)

(Provider naming probably looks more familiar than
consumer naming.)

(The wording ignores screen-line-count limitations on
what can be displayed.)

===
Mark Millard
marklmi at yahoo.com