Date: Sun, 11 Apr 2021 14:01:47 -0700 From: Mark Millard <marklmi@yahoo.com> To: Sebastian Schaack <sebastian@schaack.io> Cc: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi 4 CM Freebsd 13 Message-ID: <628DFDA4-85B8-414F-9C06-2EFA9FA8220A@yahoo.com> In-Reply-To: <D51E5D99-AC1C-47DE-A2FB-02E2A51C0545@schaack.io> References: <D51E5D99-AC1C-47DE-A2FB-02E2A51C0545@schaack.io>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > Just to make sure that I did nothing wrong , I copied a raspbian to = the emmc and boot wents fine, but ok no surprise. =20 >=20 > 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-not= es.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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?628DFDA4-85B8-414F-9C06-2EFA9FA8220A>