Bug 259353 - FreeBSD-13.0-RELEASE boot failure on Raspberry Pi 4 Model B Rev 1.4
Summary: FreeBSD-13.0-RELEASE boot failure on Raspberry Pi 4 Model B Rev 1.4
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 13.0-RELEASE
Hardware: arm64 Any
: --- Affects Only Me
Assignee: Li-Wen Hsu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-22 10:07 UTC by Greg Donald
Modified: 2021-10-28 12:51 UTC (History)
3 users (show)

See Also:


Attachments
Screenshot of boot failure (282.79 KB, image/jpeg)
2021-10-22 10:11 UTC, Greg Donald
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Donald 2021-10-22 10:07:41 UTC
FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img fails to boot on my Raspberry Pi 4 Model B Rev 1.4.

I've confirmed my sdcard and board both work by installing Debian which boots fine.

I've attached a screenshot.
Comment 1 Greg Donald 2021-10-22 10:11:27 UTC
Created attachment 228941 [details]
Screenshot of boot failure
Comment 2 Li-Wen Hsu freebsd_committer 2021-10-22 19:31:37 UTC
Can you also test 14.0-CURRENT image?

I have tested FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img with Raspberry Pi 4 Model B Rev 1.2, the u-boot.bin in this image is too old and can only work with Rev 1.1. Replacing it with the one in the 14.0-CURRENT image or u-boot-rpi4 pkg resolves booting issue.
Comment 3 Greg Donald 2021-10-22 21:24:11 UTC
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20211014-04c91ac48ad-250051.img boots and runs successfully.
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-22 23:19:01 UTC
^Triage: Track this in bug 259353 (same logical issue)

*** This bug has been marked as a duplicate of bug 259352 ***
Comment 5 Mark Millard 2021-10-23 00:42:27 UTC
(In reply to Kubilay Kocak from comment #4)

FreeBSD 12.x makes no claim to support RPi4B's, 13.0 does.
There are RPi4B specifics in 13 and later that were never
put back in 12.x as far as I know.

I doubt this should be listed as a duplicate.
Comment 6 Li-Wen Hsu freebsd_committer 2021-10-23 03:22:04 UTC
This is not a duplicated issue, 12.x doesn't support RPi4 while 13.0-RELEASE image doesn't support RPi4 Rev >= 1.2 because of the u-boot.bin used when creating release image was too old to support newer RPi4 hardware revision.

We can't do much with RELEASE images since it's released, but we can document these workarounds. For people want to use newer RPi4 revision, it's recommended to use 13.0-STABLE or 14.0-CURRENT snapshot images for now.
Comment 7 Li-Wen Hsu freebsd_committer 2021-10-23 03:30:17 UTC
I'm updating the docs.
Comment 8 Li-Wen Hsu freebsd_committer 2021-10-23 04:47:03 UTC
https://wiki.freebsd.org/arm/Raspberry%20Pi#RPI4
Comment 9 Mark Millard 2021-10-23 07:02:27 UTC
(In reply to Li-Wen Hsu from comment #6)

13.0-RELEASE does too support at least some RPi4B v1.4 's
that have appropriate vintage EEPROM contents.

For example, I just took a microsd card that has 13.0-RELEASE
and booted one of the RPi4B 8 GiByte systems that I have
access to, other than it has my personal adjustments to
config.txt involved. I will note that this is a serial console
context, not a HDMI one.

I beleive the submittal is valid for investigation.

Deatils from my boot attempt:

root@generic:~ # uname -apKU
FreeBSD generic 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 06:06:55 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1300139 1300139

root@generic:~ # strings /boot/msdos/start4.elf | grep VC_BUILD_
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)

root@generic:~ # ls -Tldt /boot/msdos/*
-rwxr-xr-x  1 root  wheel      429 Apr 13 12:58:14 2021 /boot/msdos/config.txt
drwxr-xr-x  1 root  wheel     4096 Apr  8 23:46:42 2021 /boot/msdos/overlays
drwxr-xr-x  1 root  wheel     4096 Apr  8 23:46:30 2021 /boot/msdos/EFI
drwxr-xr-x  1 root  wheel     4096 Apr  8 23:46:30 2021 /boot/msdos/dtb
-rwxr-xr-x  1 root  wheel     5888 Apr  8 21:04:52 2021 /boot/msdos/armstub8-gic.bin
-rwxr-xr-x  1 root  wheel     5888 Apr  8 21:04:52 2021 /boot/msdos/armstub8.bin
-rwxr-xr-x  1 root  wheel      240 Apr  8 20:56:28 2021 /boot/msdos/README
-rwxr-xr-x  1 root  wheel   566720 Apr  7 20:51:26 2021 /boot/msdos/u-boot.bin
-rwxr-xr-x  1 root  wheel     1594 Mar  3 05:29:56 2021 /boot/msdos/LICENCE.broadcom
-rwxr-xr-x  1 root  wheel    26894 Mar  3 05:29:56 2021 /boot/msdos/bcm2710-rpi-2-b.dtb
-rwxr-xr-x  1 root  wheel    29011 Mar  3 05:29:56 2021 /boot/msdos/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root  wheel    28392 Mar  3 05:29:56 2021 /boot/msdos/bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root  wheel    49090 Mar  3 05:29:56 2021 /boot/msdos/bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root  wheel    52456 Mar  3 05:29:56 2021 /boot/msdos/bootcode.bin
-rwxr-xr-x  1 root  wheel     7314 Mar  3 05:29:56 2021 /boot/msdos/fixup.dat
-rwxr-xr-x  1 root  wheel     5448 Mar  3 05:29:56 2021 /boot/msdos/fixup4.dat
-rwxr-xr-x  1 root  wheel     3187 Mar  3 05:29:56 2021 /boot/msdos/fixup4cd.dat
-rwxr-xr-x  1 root  wheel     8452 Mar  3 05:29:56 2021 /boot/msdos/fixup4db.dat
-rwxr-xr-x  1 root  wheel     8454 Mar  3 05:29:56 2021 /boot/msdos/fixup4x.dat
-rwxr-xr-x  1 root  wheel     3187 Mar  3 05:29:56 2021 /boot/msdos/fixup_cd.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 05:29:56 2021 /boot/msdos/fixup_db.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 05:29:56 2021 /boot/msdos/fixup_x.dat
-rwxr-xr-x  1 root  wheel  2952960 Mar  3 05:29:56 2021 /boot/msdos/start.elf
-rwxr-xr-x  1 root  wheel  2228800 Mar  3 05:29:56 2021 /boot/msdos/start4.elf
-rwxr-xr-x  1 root  wheel   793116 Mar  3 05:29:56 2021 /boot/msdos/start4cd.elf
-rwxr-xr-x  1 root  wheel  3722504 Mar  3 05:29:56 2021 /boot/msdos/start4db.elf
-rwxr-xr-x  1 root  wheel  2981192 Mar  3 05:29:56 2021 /boot/msdos/start4x.elf
-rwxr-xr-x  1 root  wheel   793116 Mar  3 05:29:56 2021 /boot/msdos/start_cd.elf
-rwxr-xr-x  1 root  wheel  4794472 Mar  3 05:29:56 2021 /boot/msdos/start_db.elf
-rwxr-xr-x  1 root  wheel  3704808 Mar  3 05:29:56 2021 /boot/msdos/start_x.elf

root@generic:~ # more /boot/msdos/config.txt 
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
#
# Local additions:
enable_uart=1
uart_2ndstage=1
dtdebug=1
disable_commandline_tags=1
disable_overscan=1
gpu_mem_1024=32

[pi4]
# Locally avoid hdmi_safe's dislay scaling:
#hdmi_safe=1
armstub=armstub8-gic.bin
#
# Local additions:
over_voltage=6
arm_freq=2000
sdram_freq_min=3200
force_turbo=1



While I do not have the context to test it now, I have used
HDMI via booting the media before. That is why hdmi_safe=1
was commented out above.
Comment 10 Mark Millard 2021-10-23 07:14:22 UTC
(In reply to Li-Wen Hsu from comment #8)

I beleive the claim that is there:

QUOTE
Rpi 4 Rev >= 1.2 doesn't boot with FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img image.
The u-boot.bin used when creating 13.0-RELEASE image was too old to support newer RPi4 hardware revision.
END QUOTE

is false for even some 8 GiByte RPi4B's, per my example boot.

But in Comment #9 I forgot to report the U-Boot version in case I'm
miss remembering about the /boot/msdosfs/ content being the original
material:

root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2"
U-Boot 2021.04 (Apr 08 2021 - 10:46:22 +0000)
Comment 11 Mark Millard 2021-10-23 07:46:16 UTC
(In reply to Mark Millard from comment #10)

I will note that there is a known U-Boot limitation documented in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256441
and:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983


Separately from that, there may be DMA reliablility issues
for 4 GiByte and 8 GiByte RPI4B's, even though some can boot
just fine.

My test for this involved duplicating a huge file and seeing
if a diff aferwards would pass. (It was also a USB3 SSD context,
not a microsd card context.)

(My normal bectl context for the RPi4B's runs with patches for
any of releng/13.0 , stable/13 , or main and such passed the test
last I tried.)
Comment 12 Mark Millard 2021-10-23 08:10:37 UTC
(In reply to Mark Millard from comment #10)

There was also one person that got a RPi4B (2 GiByte) labeled with:

2711ZPKFSB06C0T

on the processor. Normal is:

2711ZPKFSB06BOT

It did take a more recent U-Boot to deal with the
2711ZPKFSB06C0T part for that person.

The RPi4B 8GiByte boards that I have access to are
2711ZPKFSB06BOT ones.

It does not appear that v1.4 vs. not indicates
2711ZPKFSB06BOT vs. 2711ZPKFSB06C0T .

(Sorry it is taking me so long to remember various
details.)
Comment 13 Mark Millard 2021-10-23 08:27:47 UTC
(In reply to Mark Millard from comment #12)

Looks like I did substitute 2021.04 U-Boot onto my
media: it was what booted the 2711ZPKFSB06C0T
example and back then I tested it would still boot
the 2711ZPKFSB06BOT ones that I have access to:

2020.10 U-boot booted 2711ZPKFSB06BOT but not 2711ZPKFSB06C0T.
2021.04 U-Boot booted both.

(Someone else did the 2711ZPKFSB06C0T tests.)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080
comment num. 5 and later have some of the old 2711ZPKFSB06C0T
related material.
Comment 14 Mark Millard 2021-10-23 09:42:22 UTC
(In reply to Mark Millard from comment #13)

To check my memory of a pure image result . . .

I dd'd a 13.0_RELEASE image to a microsd card and used it to
boot the 8 GiByte RPi4B (so a v1.4, there being no smaller
version number for 8 GiByte ones):

root@generic:~ # strings /boot/msdos/start4.elf | grep "VC_BUILD_"
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)

root@generic:~ # strings /boot/msdos/u-boot.bin | grep "U-Boot 2"
U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000)

root@generic:~ # uname -apKU
FreeBSD generic 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 06:06:55 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1300139 1300139

Of course, this is a 2711ZPKFSB06B0T context. not a
2711ZPKFSB06C0T one.