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

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On 2022-Oct-1, at 14:21, bob prohaska <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.