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

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 01 Oct 2022 23:59:53 UTC 
On 2022-Oct-1, at 14:21, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Oct 01, 2022 at 12:58:00PM -0700, Mark Millard wrote:
>> 
>> What you report for behavior below suggests that you got
>> an appropriate u-boot.bin in place.
>> 
> 
> That's a relief!
> 
>> 
>> Given the "no failures to find a boot device",
>> I suggest an experiment of (temporarily?)
>> reverting to the official rpi_arm64_fragment
>> (to disable the U-Boot logging) and seeing how
>> it behaves without the extra messages.
>> 
> 
> Done, using a copy of rpi_arm64_fragment from
> another FreeBSD box that's dated April 5th.
> I didn't think it'd be that old, hope not!

I'm confused. Something like:

# git -C /usr/ports/ restore sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment

should put back the official:

/usr/ports/sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment

content for use in a following build. (But, I'm
assuming that you use a git-based way of having
/usr/ports/ content managed.)

I'll note that the file has only one check-in, the
one where it was first added to that port. It is
from 2020-12-15. See:

https://cgit.freebsd.org/ports/log/sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment


> Out of 14 boot attempts, about 7 ended in loops.
> Only two shutdown -r now attempts succeeded. The
> transcipt is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
> 
> I'll resume experiments in the morning after checking email.
> 

There were no examples of "0 Storage Device(s) found".
But such still needs testing without any U-Boot debug
output involved.


===
Mark Millard
marklmi at yahoo.com