[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-arm
Subject: Re: Raspberry Pi 4 CM Freebsd 13
From: Mark Millard via freebsd-arm <freebsd-arm () freebsd ! org>
Date: 2021-04-11 21:01:47
Message-ID: 628DFDA4-85B8-414F-9C06-2EFA9FA8220A () yahoo ! com
[Download RAW message or body]
On 2021-Apr-11, at 03:35, Sebastian Schaack <sebastian at schaack.io> wrote:
> I tried to install Freebsd 13 RC5 on my raspberry pi 4 CM . I copied the img to the \
> emmc , but it does not boot instead I got a uboot promt.
> Just to make sure that I did nothing wrong , I copied a raspbian to the emmc and \
> boot wents fine, but ok no surprise.
> Anyone got freebsd 13 to boot on the cm4 ? What do I have to to that uboots know \
> where my system is located ?
I do not have access to a CM4 so my notes here are more
generic than specific testing would produce.
Unfortunately, you likely have to deal with finding a combination
of materials that work together for the CM4:
pieeprom-*.bin
vl805-*.bin
start4.elf and other RPi firmware files (including bcm2711-rpi-cm4.dtb )
u-boot
FreeBSD's loader, kernel, world vintage(s), here 13.0-RC5
For example,
https://github.com/u-boot/u-boot/commits/master/board/raspberrypi/rpi
shows "rpi: Add identifier for the new CM4" is in a
2021-Feb-21 commit. (RPi400 too.)
That is after the version of u-boot that was used to make
FreeBSD-13.0-RC5-arm64-aarch64-RPI.img.xz ("2020.10"). So,
unless, some extra patch was dealing with such things, the
u-boot in that image might not well deal with the CM4.
"sysutils/u-boot-*: Update to 2021.04" only happened
recently: 2021-04-07 07:57:52 +0000 . Previously it
was based on "sysutils/u-boot-*: Update to 2020.10"
( as of 2020-11-07 18:59:37 +0000 ).
So u-boot is something that you might have to update
on the boot media after putting the 13.0-RC5 image
on that media.
FreeBSD-13.0-RC5-arm64-aarch64-RPI.img.xz is based on
sysutils/u-boot-rpi-arm64 but from before the CM4
identifier had been added. I do not know if a 2021.04
of it would well span the CM4 in addition to the RPi4
and RPi3 (in aarch64 mode). There might be more
configuration necessary for all I know.
At this stage, for the CM4, it is probably always important
to report what version of the EEPROM is involved in problem
and success reports. To ask what version is in use for any
success reports. That is because:
https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md
shows a lot of CM4 related development activity after the
last version promoted to be a default (a.k.a. critical),
back in 2020-Sep: The 2020-Sep-03 release was promoted on
2020-Sep-14.
As I understand the CM4 had not been around all that long
when the latest default was initially released.
You can see the pieeprom-*.bin releases in:
https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware/critical/
(now also known as default via a symbolic link)
https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware/stable/
(now also known as latest via a symbolic link)
https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware/beta/
FreeBSD does not provide was to deal with EEPROM updates
from FreeBSD. Testing alternative versions requires use
of another context to deal with changing the EEPROM
content.
More than the eeprom vintage and u-boot vintage likely
should be indicated in problem and success reports for
the CM4 (and, possibly, RPi400):
pieeprom-*.bin
vl805-*.bin
strings start*.elf | grep VC_BUILD_ID_ # such as start4.elf
bcm2711-rpi-cm4.dtb # version/vintage identification is not so easy
(bcm2711-rpi-400.dtb)
strings u-boot.bin | grep 'U-Boot 2'
FreeBSD's loader, kernel, world vintage(s), here 13.0-RC5
Note that an unmodified 13.0-RC5 image has:
# strings 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)
While this start4.elf has been observed to be reasonably
well behaved for RPi4B's, I'm not sure that much is known
about its behavior for CM4's.
It is not so easy to start with a bcm2711-rpi-cm4.dtb (or
the like) and figure out it version/vintage if one is
unsure of it matching the likes of the start4.elf that
is present. For 13.0-RC5 start4.elf and bcm2711-rpi-cm4.dtb
are from the same RPi firmware release.
Note that an unmodified 13.0-RC5 image also has:
# strings /mnt/u-boot.bin | grep 'U-Boot 2'
U-Boot 2020.10 (Apr 02 2021 - 04:02:14 +0000)
That "2020.10" may mean that it is too early of a
vintage for u-boot to well support the CM4 (or
RPi400).
Once stable/13 starts having snapshots, there may
be images that will have "2021.04" u-boot to try
(if one does not build and substitute things oneself).
An unfortunate problem is fairly likely if more
recent start4.elf and the like are required:
the BETA and LATEST versions frequently do not
work well across all the products. Just updating
sysutils/rpi-firmware and building it and
substituting the new material may be problematical
overall. Grabbing firmware from elsewhere may end
up being preferred for a time until a vintage is
known to be working for the range of RPi* devices.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
freebsd-arm@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]