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

Tue Mar 16 22:22:16 UTC 2021

On 2021-Mar-16, at 09:44, tech-lists <tech-lists at zyxst.net> wrote:

> On Mon, Mar 15, 2021 at 06:50:02PM -0700, Mark Millard wrote:
> 
>> 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
> 
> I don't know what (version) those ports make, as I've never tested/used them. My way of working (directly updating firmware files) is a hangover from the time when there was little support for the rpi4/8GB and I've just never changed my method. Maybe that needs changing.

Where those ports are/were used in official FreeBSD
builds . . .

sysutils/u-boot-rpi-arm64 (from latest) is what is used
in building the official, weekly snapshots'

FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-*.img.xz

images. Some version from quarterly is used
in building the official:

FreeBSD-13.0-*-arm64-aarch64-RPI.img.xz

images.

FreeBSD-13.0-RC3-arm64-aarch64-RPI.img.xz this week
should finally use a sysutils/u-boot-rpi-arm64 version
from quarterly that no longer has the RPi* firmware
based USB problem(s).

FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz

from last week was the first to use a version of
sysutils/u-boot-rpi-arm64 from latest that no
longer had the RPI*firmware USB problem(s) but
it had FreeBSD kernel USB problems reported by
its debug kernel.

[I'm ignoring u-boot's not handling having multiple
storage LUNs in a USB device here.]

Back when there were separate snapshots for
RPi4 and RPi3 for 64-bit, sysutils/u-boot-rpi4
and sysutils/u-boot-rpi3 were used. (The detailed
u-boot options for at least sysutils/u-boot-rpi4
are somewhat different than for
sysutils/u-boot-rpi-arm64 .)

Two of the ports are intended to be RPi4 vs.
RPi3 (and RPi2 v1.2) specific. In an RPi4
context, materials from sysutils/u-boot-rpi3
should not be used.

What versions are built . . .

As far as I know all the u-boot ports are currently
picking up the default 2020.10 assignment that
is in sysutils/u-boot-master plus whatever local
patches that they may have. sysutils/u-boot-master
specifies other details for specific ports as well.

>>> [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
> 
> what I was looking for when I asked the question was whether you might
> know a method of testing it programmatically. I mean, I'm not a programmer, so I don't know where to look. I don't even know what the
> three firmware files do, apart from leveraging the booting process. 

u-boot is used in booting but (for the most part?)
does not survive the OS finishing its boot: basically
nothing to test for u-boot after booting successfully.

General testing is just if you are having boot problems.
The mess is if the answer is yes and then the problem
needs to be tracked down to contributions from some
combination of firmware, u-boot, loader.efi (bootaa64.efi),
FreeBSD kernel, or world materials (in part depending
on how far things got for the configuration).

> By "works perfectly", what I mean is it seems to do everything asked of it.
> The stable/13 machine, as well as self-hosting, runs poudriere for about 500
> packages, runs mail clients, is a web server, uses usb3+zfs for
> additional (2Tb) storage, boots off sdcard, is clocked at 2GHz.

"Boots off sdcard" and possibly "is clocked at 2GHz" are
the parts of that tied to u-boot. (u-boot could force
the initial conditions for what the later stages see for
cpu clock rates and such.)

"Booting off USB without use of a microsd card" would
be another form of test tied to u-boot.

> I don't know what else to test apart from transferring files from sdmmc to
> usb3 storage and back and checking for crc errors, I mention because there was an issue with large file transfers a while ago.

The large file transfer problems that I know of were
for RPi4's with > 3 GiByte RAM configured and the
fix was to the FreeBSD kernel. (uefi/ACPI booting is
still limited to <= 3 GiByte for reliable operation:
the kernel fix was only to code not involved for ACPI
handling.)

>> I had not quizzed you about what it takes to have the
>> status "works perfectly".
> 
> Hopefully, the above answers that. If not, please suggest some tests to
> run?

I think your activity was fine for the purposes
involved.

You might want to recheck some official snapshots
and 13.0 releases as they are released, hopefully
not having to make substitutions copied from
elsewhere else once this week's materials are
available (including the debug FreeBSD kernel).

>> (I would expect that "works perfectly" has to involve how the combination of u-boot and RPi* firmware operate together in making the
>> judgment.)
> 
> All I can say for certain is that this combination
> wget
> https://sourceforge.net/projects/fbsd-rpi4-u-boot2021-04-klaus/files/u-boot.bin/download
> -O u-boot.bin
> fetch
> https://github.com/raspberrypi/firmware/raw/0591568b29a724de406aa737fc8e13f68c423f3f/boot/start4.elf
> fetch
> https://github.com/raspberrypi/firmware/raw/0591568b29a724de406aa737fc8e13f68c423f3f/boot/fixup4.dat

Hopefully none of that copying will be needed
to get materials once this week's 13.0-RC3 and
main snapshots are available and materials from
them are put to use (msdos file system materials).

Getting such materials from the official builds
helps check that the official builds are good.
Getting them from elsewhere does not directly
do so.

> "work perfectly" (but see [3]), with both a stable/13 (13-n244890) GENERIC rpi4 and current/14 (main-n245454) rpi4 with a GENERIC-NODEBUG kernel.
> 
>> [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:
> 
> I'm not sure either way because I don't know if or how any of the three
> files work when it comes to initialising usb, or sdmmc which is where I
> started.

Both the RPi* firmware and u-boot could potentially
mess things up. As things are, absent specific
evidence, the RPi* firmware is more likely to be
what broke things if something is discovered to
be broken.

The 3 different u-boots are alternatives for each
other, although two are intended to be RPi4 vs.
RPi3(/RPi2 V1.2) specific.

For helping check modern official-build materials,
sysutils/u-boot-rpi-arm64 is the one to check.

> Additionally, main-n245454 (generic, so debug kernel) unmodified will boot if there's nothing usb attached. If my usb3 disk is plugged in after it boots, the pi will panic. If I reboot replacing just the u-boot with Klaus's u-boot, I get the same result. 

Until this week's main snapshot build and 13.0-RC3
build, problems with USB are expected and are from
one or both of 2 places:

A) Older RPi* firmware that is known-broken

B) FreeBSD debug kernel panics about inappropriate
   sleeping being allowed for memory allocations.
   (Recently added validation code reporting
    pre-existing problems as I understand.)
   NOTE: (B) was not limited to arm or aarch64
         platforms but (A) is so limited.

Both should be fixed in this week's build materials.

u-boot was not involved in causing either of those
problems. (The only known u-boot issue for USB seems
to be that it does not support USB devices that have
multiple storage LUNs in the device.)

> If I replace all 3 files with the latest versions as described in the
> URLs, (again generic kernel so with debug on main/14), it will still panic when usb is plugged in. Presumably these "latest" files are ahead of those made by ports.

It only takes the debug kernel to be involved to have
the panics about inappropriate sleeping being allowed.
This problem was not limited to RPi4 or aarch64 or
even to arm. Even with good RPi* firmware and a
good u-boot, it was a problem made obvious by the
debug FreeBSD kernel.

> So, the things that are fixed for me are sdmmc initialisation (presumably
> u-boot fixed this) on stable/13

As I remember you initially reported a 2020.07 or
some such older u-boot before you updated it. So
not necessarily surprising that an update helped.

> and usb initialisation (which making a
> generic kernel on main/14 fixes).

For debug FreeBSD kernel, it takes both a modern
enough kernel build vintage and an appropriate
RPi* firmware vintage before USB booting and
the like will work well. Neither is sufficient
by itself, both are necessary.

In other words: There has been more than one
USB-support problem present recently for RPi4's,
problems being from separate pieces of software.
This makes it messier to track the issues.

> [3] only thing tested on current/14 is booting and buildworld

Sounds good.

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