Re: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED]

On 2021-Mar-15, at 10:26, tech-lists <tech-lists at zyxst.net> wrote:

> On Sat, Mar 13, 2021 at 01:04:01PM -0800, Mark Millard wrote:
> 
>> If I gather correctly, it works but so does the one found in
>> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img
>> ? In other words, the material from
>> fbsd-rpi4-u-boot2021-04-klaus/files/u-boot.bin/download
>> 
>> works but is not required to make the RPi4B work?
> 
> Yes. I have tested it, and it "works" to the extent that it boots
> normally and I can't see any issues[1] at first glance.

So there would seem to be no urgent aspect of
existing RPi[34] u-boot ports vs. Klaus K.'s
build(s) to lead Klaus to put up reviews on
Phabricator for updates to:

sysutils/u-boot-rpi-arm64
sysutils/u-boot-rpi3
sysutils/u-boot-rpi4

> For clarity, the sha256 of the u-boot provided from the FreeBSD image is
> SHA256 (u-boot.bin) =
> 8fa7d8d0f8d9708f7adecb89ca239a52c2f9b6911c20e27b71e4d99d132dbfc4
> 
> The latest u-boot from Klaus is
> SHA256 (u-boot.bin) =
> 48b6d9b3837aabaa7ad9830babe15722f2c46cc03f48f1b64ef40d2c0d0f7529
> 
> In both cases, the start4.elf and fixup4.dat that I'm using are the same vintage:
> 
> % sha256 start4.elf
> SHA256 (start4.elf) =
> dce1545e7133835b77871295292f692a84101722f6ceecf73f91f2248ba01907
> 
> % strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
> VC_BUILD_ID_USER: dom
> VC_BUILD_ID_TIME: 10:12:47
> VC_BUILD_ID_VARIANT: start
> VC_BUILD_ID_TIME: Mar 10 2021
> VC_BUILD_ID_BRANCH: bcm2711_2
> VC_BUILD_ID_HOSTNAME: buildbot
> VC_BUILD_ID_PLATFORM: raspberrypi_linux
> VC_BUILD_ID_VERSION: 4b9ea44619376439c801684745a12299b45ae2bb (clean)

Good to know, thanks.

It may be that the Mar 10 2021 build/release is only
a fix relative to the Mar 5 2021 release and not
relative to the Feb 25 2021 build/release.

(I'm not sure that builds and releases are always
the same day. But it does happen frequently as
I understand.)

> % sha256 /boot/msdos/fixup4.dat SHA256 (/boot/msdos/fixup4.dat) =
> 0526e9e190fa1f957c3c7e8063116e0adfd9a0eb9c72c2fe67d59140ef84dc1a
> 
> These were downloaded from https://github.com/raspberrypi/firmware/raw/0591568b29a724de406aa737fc8e13f68c423f3f/boot/start4.elf
> and
> https://github.com/raspberrypi/firmware/raw/0591568b29a724de406aa737fc8e13f68c423f3f/boot/fixup4.dat
> 
> [1] how would I "test" the installed[2] u-boot.bin to make sure it was
> working correctly?

I was thinking of whatever criteria you used when you
wrote:

QUOTE
. . .
> https://sourceforge.net/projects/fbsd-rpi4-u-boot2021-04-klaus/files/u-boot.bin/download

Pleased to report this new u-boot works perfectly! thank you
END QUOTE

I had not quizzed you about what it takes to have the
status "works perfectly". (I would expect that "works
perfectly" has to involve how the combination of u-boot
and RPi* firmware operate together in making the
judgment.)

> [2] the one that was on
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img

[2] has both a different u-boot and a different
group of RPi* firmware files.

There would seem to be no urgent aspect of the
existing sysutils/rpi-firmware port vs. the
Mar 10 2021 RPI* materials to lead anyone to
put up a review on Phabricator for updating:

sysutils/rpi-firmware


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"