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.

In D46956#1070341, @markmi_dsl-only.net wrote:

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

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.

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

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.

In D46956#1070369, @markmi_dsl-only.net wrote:

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

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

In D46956#1070371, @markmi_dsl-only.net wrote:

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.

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.

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

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.

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