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

[Mark Millard]

On 2021-Mar-13, at 17:29, tech-lists <tech-lists at zyxst.net> wrote:

> Hi,
> 
> (in my reply below I'm using md5 to differentiate btwn files with
> identical names)

A means of finding information that can be used to track down
which vintage is in use for the start*.elf files is to use the
start*.elf file(s) and do something like:

# strings start4.elf | grep VC_BUILD_ID_

The output can be compared to output from other files
and there are build dates/times (not release dates)
that can be used to get the time frame. For example:

# strings /boot/efi/start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

(The *.dat files do not seem to have such identification
text. Similarly for various other types of files. So this
does not cover mixing and matching across vintages across
all files: only if the files have been kept together.)

This works independent of worrying about how you got the
copy of the file.

The above is the version that sysutils/rpi-firmware is
currently set up to put in:

/usr/local/share/rpi-firmware/

(Of course, this does nothing for u-boot or bootaa64.efi
or the like.)

> 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?
> 
> I didn't even think about the u-boot already on the image! I just
> followed the notes i made in
> https://cloud.zyxst.net/~john/FreeBSD/current/rpi4b/installing.txt
> which installed u-boot.bin dated Oct 5 and has md5 of
> d208763206d50d3ec40b04cc81685b29 and that worked.

Too bad we did not learn the status of the official
build's u-boot.

> The one provided with
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img
> has md5 967c3a667af11512bafd2525ef97af5f and is dated 11th March. I've
> not tried this one, as I overwrote it before booting it for the first
> time. 
> I got the latest u-boot.bin when Klaus kindly offered it (md5
> 1b868cc0550df026e1a4e7baf2cca223 dated 13th March)
> 
>> Be very careful with referencing "latest" start4.elf and
>> the like because folks could easily interpret such to be
>> something like (using start4.elf as an example):
>> 
>> https://github.com/raspberrypi/firmware/blob/master/boot/start4.elf
>> 
>> that can change on a regular basis and is far from guaranteed
>> to be a version that works for FreeBSD use. (In recent months
>> such usually has not worked. Even tagged versions need not
>> work for FreeBSD use, as was true for FreeBSD tried to use
>> some in the range 1.20210104 through 1.20210201 .)
> 
> My reference was:
> https://github.com/raspberrypi/firmware/raw/master/boot/fixup4.dat
> https://github.com/raspberrypi/firmware/raw/master/boot/start4.elf
> 
> from my notes but yeah, point taken. I am still trying to get my head around git, after using svn and cvs for years.

A means of avoiding worrying about where you got
the start*.elf files is using those commands like:

# strings /boot/efi/start4.elf | grep VC_BUILD_ID_

The VC_BUILD_ID_TIME gives a strong hint at the
date of the binary commit to the public repository:
say within a week or so after. A few file downloads
and output comparisons can identify exactly which
if needed.

(Of course, this does nothing for u-boot or bootaa64.efi
or the like.)


>> My guess here is that you are referring to materials from the
>> most recent sysutils/rpi-firmware port. Those are (for now)
>> based on somewhat older RPi* materials. Using start4.elf as
>> an example, sysutils/rpi-firmware is based on, in part,
>> 
>> https://github.com/raspberrypi/firmware/blob/1.20210303/boot/start4.elf
> 
> I'd not installed the port at any stage. The md5 for the start4.elf above is 1a13569ce69f758c87a71dba78750f0d and the md5 of the one I downloaded
> is 741c0a91981196e2bc01b0b25f458045 (dated 10th March).

Again for RPi* firmware I'd recommend use of the
output from commands like:

# strings /boot/efi/start4.elf | grep VC_BUILD_ID_

on some *.elf file(s), as VC_BUILD_ID_TIME is useful
to know without extra steps. 


>> If one does find materials in master that work and wants to
>> refer to them, it is best to find what master translates to
>> at the time and refer to that specifically, for example:
>> 
>> https://github.com/raspberrypi/firmware/tree/0591568b29a724de406aa737fc8e13f68c423f3f
>> 
>> (One has to look at the commits history to figure out
>> such an absolute untagged reference.)
> 
> OK. So in my example, in this case start4.elf (of 10th March), the absolute URL would be https://github.com/raspberrypi/firmware/raw/0591568b29a724de406aa737fc8e13f68c423f3f/boot/start4.elf
> ?
> 
> ...and that's a stable URL? just making sure

The big hexadecimal numeral is a commit hash/ID in that
repository and so is supposed to be unique, given access
to the repository is even available and the commit is
still present.

I will note that the /raw/ part of your URL does get
translated to /tree/ in the URL shown for the content.

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