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

[tech-lists]

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.

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

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.

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.

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

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

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. 

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.

So, the things that are fixed for me are sdmmc initialisation (presumably
u-boot fixed this) on stable/13 and usb initialisation (which making a
generic kernel on main/14 fixes).

[3] only thing tested on current/14 is booting and buildworld
-- 
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20210316/eeb79ffd/attachment.sig>