sysutils/rpi-firmware: Update to 1.20241001
See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281863
Temporarily remove Raspberry Pi 5 related files.
Details
Details
Tested on Raspberry Pi 4 B 8GB.
Download 14.1-RELEASE arm64 RPI and make a bootable microsd card.
Update firmware using rpi-eeprom via Raspberry Pi OS.
sudo apt update && sudo apt install rpi-eeprom sudo rpi-eeprom-update -a
Make rpi-firmware and install
cd /usr/ports/sysutils/rpi-firmware make install cp -pr /usr/local/share/rpi-firmware/* /boot/efi/
Make latest u-boot-rpi4 and install
cd /usr/ports/sysutils/u-boot-rpi4 make install cp /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin /boot/
or
cd /usr/ports/sysutils/u-boot-rpi-arm64 make install cp /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin /boot/
Reboot.
freebsd@generic:~ % uname -a FreeBSD generic 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC arm64
If a red screen appears, update the firmware first. If a rainbow screen appears, set hdmi_safe to 0 in the config.txt file.
Diff Detail
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
The official FreeBSD builds for aarch64 RPi* (including the for the RPi4Bs) use: /usr/ports/sysutils/u-boot-rpi-arm64/
instead of using /usr/ports/sysutils/u-boot-rpi4/ . As stands that includes the likes of:
*.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/1[543].*/
FreeBSD-15.*-CURRENT-arm64-aarch64-RPI-*.img.xz
FreeBSD-14.*-STABLE-arm64-aarch64-RPI-*.img.xz
FreeBSD-13.*-STABLE-arm64-aarch64-RPI-*.img.xz
*.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/1[43].*/
FreeBSD-14.*-RELEASE-arm64-aarch64-RPI.img.xz
FreeBSD-13.*-RELEASE-arm64-aarch64-RPI.img.xz
all being based on /usr/ports/sysutils/u-boot-rpi-arm64/ . So use of /usr/ports/sysutils/u-boot-rpi-arm64/ likely should be tested.
Also, as far as I know, FreeBSD's kernel has had no work done to support the likes of any of:
%%DATADIR%%/bcm2712-rpi-5-b.dtb
%%DATADIR%%/bcm2712-rpi-cm5-cm4io.dtb
%%DATADIR%%/bcm2712-rpi-cm5-cm5io.dtb
%%DATADIR%%/bcm2712-rpi-cm5l-cm4io.dtb
%%DATADIR%%/bcm2712-rpi-cm5l-cm5io.dtb
%%DATADIR%%/bcm2712d0-rpi-5-b.dtb
or anything involving pi5 in the name ( or: bcm2712 ). (But there is https://github.com/worproject/rpi5-uefi?tab=readme-ov-file for UEFI/ACPI use that works for what it supports.)
I do not know about if %%DATADIR%%/bcm2711-rpi-cm4s.dtb is supported but it seems unlikely that any explicit kernel updates for it have been done.
Comment Actions
The ports sysutils/u-boot-rpi4 and sysutils/u-boot-rpi-arm64 serve as slave ports for sysutils/u-boot-master. Both ports share the same source code, as indicated by their repositories: u-boot-rpi4 and u-boot-rpi-arm64. The primary difference between them lies in their naming. For more details, you can also refer to the FreshPorts entry for u-boot-master.
Comment Actions
So far as I know, any notable difference is just from different rpi_*_defconfig selections:
< MODEL= rpi-arm64 < BOARD_CONFIG= rpi_arm64_defconfig --- > MODEL= rpi4 > BOARD_CONFIG= rpi_4_defconfig
In my view that was enough to suggest the testing of sysutils/u-boot-rpi-arm64 --unless one analyzes the differences in the involved rpi_*_defconfig 's other ways and concludes that there would be no significant difference. (I'm not familiar with the differences.)
Comment Actions
I also commented on the addition of lots of unsupported RPi5 / bcm2712 related files. As I understand, historically any unsupported RPi*'s normally have their files omitted in this port.
Comment Actions
https://github.com/u-boot/u-boot/blob/master/configs/rpi_arm64_defconfig https://github.com/u-boot/u-boot/blob/master/configs/rpi_4_defconfig They are indeed different. But for my test They both run fine.
freebsd@generic:~ % pkg info u-boot-rpi-arm64 u-boot-rpi-arm64-2024.07 Name : u-boot-rpi-arm64 Version : 2024.07 Installed on : Sat Oct 5 17:32:36 2024 UTC Origin : sysutils/u-boot-rpi-arm64 Architecture : FreeBSD:14:* Prefix : /usr/local Categories : sysutils Licenses : GPLv2 Maintainer : uboot@FreeBSD.org WWW : https://www.denx.de/wiki/U-Boot Comment : Cross-build das u-boot for model rpi-arm64 Annotations : Flat size : 634KiB Description : U-Boot loader and related files for the 64 bit variants of the RPI This u-boot config is made to be bootable on any 64bits RPI like the RPI2v1.1 RPI3 and RPI4. For general information about U-Boot see WWW: https://www.denx.de/wiki/U-Boot
Comment Actions
I’m not sure how to handle this either. As far as I know, FreeBSD currently doesn't support Raspberry Pi 5 (Although I used Raspberry Pi 5 + UEFI + FreeBSD 15.0). However, these files already exist upstream, and if I delete them, people might forget about them later. I've already deleted the large kernel_2712.img, which should be fine.
Comment Actions
I'll note that upstream 1.20230405 had bcm2711-rpi-cm4s.dtb but the port did not. But if that was deliberate vs. not I cannot tell.
As for the pi5, I expect that if someone worked on adding FreeBSD kernel support for FreeBSD's normal U-Boot style of booting, they would make the additions as part of that effort and would not be likely to forget.
But, with the files present, folks looking at the port could end up assuming support and then reporting bugs in a form based on the assumption of a supported status.
And the u-boot-rpi-arm64 text "This u-boot config is made to be bootable on any 64bits RPI like the RPI2v1.1 RPI3 and RPI4." is wrong now for the "any" because of the RPi5 family. Its is also wrong about the "RPI2v1.1" (which is armv7 based: Cortex-A7). The RPi2v1.2 is aarch64 based (Cortex-A53) and would be the correct RPi2 reference. The wording should probably explicitly indicate the lack of support for using U-Boot based booting of RPi5 family members or reference something like "bootable only on the RPI2v1.2 RPI3 and RPI4 associated families". (I take the text as only describing what FreeBSD supports, not general U-Boot use that might not involve FreeBSD.)
This comment was removed by markmi_dsl-only.net.
| sysutils/rpi-firmware/pkg-plist | ||
|---|---|---|
| 71 | The above line references a file that has a ${RM} ${WRKSRC}/overlays/bcm2712d0.dtbo referencing it as well. The 2712 is an implicit reference to a pi5 family context. Likely the line should be removed here. | |
Comment Actions
The release referenced was fairly quickly replaced. Sometimes this indicates problematical prior releases. Most recent to oldest:
tag 1.20241126 (Released 2024-Nov-26)
tag 1.20241125 (Released 2024-Nov-25)
tag 1.20241008 (Released 2024-Oct-10)
[Note that the release status was later than the tag status. Date delays for release status have happened before: possible testing time?]
tag 1.20241001 (Released 2024-Oct-01)
[The one referenced.]
Note: Sometimes a tagged build is never declared to be a release, but all of the above were. Being released the same day as tagged might indicate a lack of a final testing period.
I've not done any testing to know the status, not having the time. So this note is not a claim of inappropriateness. It just might prompt some validation effort based on the commit history from after the referenced tag/release.
Comment Actions
Basic 14.2-RELEASE testing and main testing [so: 15 as stands] and 13.4-RELEASE testing might be appropriate?
14.2-RELEASE was just announced.
Testing main may be important for being able to maintain support: If main ends up broken, it is not obvious that anyone would want to deal with getting FreeBSD's kernel to work with the update.
I will note that the https://github.com/pftf/RPi4 EDK2 distribution did: "Revert DTB to the 2023.05.12 version" 8 months ago and has stayed with that to avoid https://github.com/pftf/RPi4/issues/252 .
[I should note that modern FreeBSD detects an error in the EDK2 implementation that it used to not detect --and the handling is to panic, preventing booting with the EDK2. Still, a EDK2 firmware/DTB incompatibility status can be suggestive of FreeBSD possibly having related issues.]