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

Wed Mar 17 00:33:52 UTC 2021

On 2021-Mar-16, at 15:22, Mark Millard <marklmi at yahoo.com> wrote:

> 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.

Just an FYI:

For an RPi* using the likes of:

# strings /boot/efi/u-boot.bin | grep 'U-Boot 2'
U-Boot 2020.10 (Dec 13 2020 - 08:04:27 +0000)

to see an indication of the u-boot version and
time frame is sort of like using:

# 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)

to do so for RPi* firmware *.elf file(s).

A somewhat analogous sequence for the FreeBSD kernel
is to use something like:

# strings /boot/kernel/kernel | grep 'FreeBSD 1[0-9]\.[0-9]'
WARNING: Device "%s" is Giant locked and may be deleted before FreeBSD 14.0.
@(#)FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG
FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG

(But it is not as useful by itself for FreeBSD
with source file patching maintained in the
local git repository.)

The kernel of interest might not be the one that is running.

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