Paths

Table of Contentst

sysutils/rpi-firmware: Update to 1.20260521
ClosedPublic
Actions

Authored by jlduran on Jul 12 2026, 7:44 PM.

Details

Reviewers

manu
senguptaangshuman17_gmail.com
eduardo
freebsd_darkain.com

Group Reviewers

arm64
portmgr

Commits

R11:9d7c8619026d: sysutils/rpi-firmware: Update to 1.20260521

Summary

Update the Raspberry Pi firmware binaries to the latest upstream release
to provide native support for GPT partition schemes.

This update is related to the NanoBSD Reimagined GSoC 2026 project,
which aims to standardize on GPT layouts across all supported embedded
platforms.

Test Plan

Tested on a Raspberry Pi 4, using GPT boot.
Do not have access to previous boards for regression testing.

Diff Detail

Repository

R11 FreeBSD ports repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

jlduran requested review of this revision.Jul 12 2026, 7:44 PM

jlduran created this revision.

Harbormaster completed remote builds in B74751: Diff 181851.Jul 12 2026, 7:44 PM

jlduran edited the test plan for this revision. (Show Details)Jul 12 2026, 7:45 PM

jlduran added a reviewer: manu.

jlduran added a reviewer: senguptaangshuman17_gmail.com.

eduardo added a subscriber: eduardo.Jul 14 2026, 10:36 AM

jlduran added reviewers: arm64, eduardo.Jul 17 2026, 2:31 PM

jlduran added a reviewer: freebsd_darkain.com.

Hello!
I would really like to commit this patch this Friday. If there are reports of regressions, it will be swiftly reverted. Thank you!

emaste added a subscriber: jim.chen.1827_gmail.com.Jul 28 2026, 6:49 PM

manu accepted this revision.Jul 29 2026, 5:48 AM

This revision is now accepted and ready to land.Jul 29 2026, 5:48 AM

Closed by commit R11:9d7c8619026d: sysutils/rpi-firmware: Update to 1.20260521 (authored by jlduran). · Explain WhyJul 29 2026, 4:27 PM

This revision was automatically updated to reflect the committed changes.

jlduran added a commit: R11:9d7c8619026d: sysutils/rpi-firmware: Update to 1.20260521.

The RPi4 variants and RPi5 variants have the firmware in the EEPROM, not on external media. (*.dtb are still on external media.)

All vintages of the RPi5 EEPROM contents support GPT. Old enough vintages of the RPi4 EEPROM content do not.

As far as I know, something like, ssay, the RPi2 v1.1 (Cortex-A7 armv7) requires an MBR sd card with the bootcode.bin on it to provide an updated environment that that can then boot GPT on other media, such as USB media.

Prior to the RPi4's, there was no means to update an older type RPi* to have new internal bootcode to support more functionality without loading it from external media instead.

So . . .

QUOTE
Tested on a Raspberry Pi 4, using GPT boot.
Do not have access to previous boards for regression testing.
END QUOTE

This is a invalid test. It tested the EEPROM contents of the RPI4, not what is being updated here.

QUOTE
Update the Raspberry Pi firmware binaries to the latest upstream release
to provide native support for GPT partition schemes.
END QUOTE

This goal was not achieved, unfortunately.

In D58197#1361219, @markmi_dsl-only.net wrote:

The RPi4 variants and RPi5 variants have the firmware in the EEPROM, not on external media. (*.dtb are still on external media.)

All vintages of the RPi5 EEPROM contents support GPT. Old enough vintages of the RPi4 EEPROM content do not.

As far as I know, something like, ssay, the RPi2 v1.1 (Cortex-A7 armv7) requires an MBR sd card with the bootcode.bin on it to provide an updated environment that that can then boot GPT on other media, such as USB media.

Prior to the RPi4's, there was no means to update an older type RPi* to have new internal bootcode to support more functionality without loading it from external media instead.

So . . .

QUOTE
Tested on a Raspberry Pi 4, using GPT boot.
Do not have access to previous boards for regression testing.
END QUOTE

This is a invalid test. It tested the EEPROM contents of the RPI4, not what is being updated here.

QUOTE
Update the Raspberry Pi firmware binaries to the latest upstream release
to provide native support for GPT partition schemes.
END QUOTE

This goal was not achieved, unfortunately.

Thanks for taking a closer look at this. To clarify, are you suggesting a revert, or is this primarily a request to make the commit message more explicitly descriptive of what was tested?

The goal of updating the firmware binaries isn't to give old, un-updatable hardware new internal EEPROM capabilities, but rather to ensure that release(7) has access to the latest upstream binaries and that NanoBSD Reimagined can access them to boot a GPT-partitioned Raspberry Pi board. GPT-partitioned Raspberry Pi images were built using NanoBSD reimagined (a GSoC 2026 project); we currently have two Raspberry Pi 4 GPT-partitioned systems: one using UFS and another one using ZFS. See D59235 for current improvements/suggestions.

If you have access to an old Raspberry Pi, the test is to use release(7) with this updated port and verify that you can still boot. It will obviously use an MBR partition scheme, as that is what release/arm64/RPI.conf uses (PART_SCHEME="MBR"). It is just to verify that the new binaries do not break something.

In D58197#1361225, @jlduran wrote:

In D58197#1361219, @markmi_dsl-only.net wrote:

. . .

Thanks for taking a closer look at this. To clarify, are you suggesting a revert, or is this primarily a request to make the commit message more explicitly descriptive of what was tested?

I'm just noting that the goal specified was not achieved. The update did not change the status of GPT support for any RPi* . The tested environment ignores the processor-code files that actually holds executable firmware. The file updates may well be reasonable for other purposes --but may end up requiring FreeBSD kernel changes to track possible *.dtb and *.dtbo changes. That is one reason sysutils/rpi-firmware is rarely updated.

The goal of updating the firmware binaries isn't to give old, un-updatable hardware new internal EEPROM capabilities,

but rather to ensure that release(7) has access to the latest upstream binaries and that NanoBSD Reimagined can access them to boot a GPT-partitioned Raspberry Pi board.

Hybrid MBR/GPT? The older RPI* families require MBR to be involved, posibly via a hybrid MBR/GPT meeting certain criteria. No firmware read in from any boot media can change that initial requirement to get the boot process started. bootcode.bin has to be loaded from media that the old RPI*'s have internal MBR code to handle only MBR. Once bootcode.bin is loaded, only following stages can deal with GPT for the older RPI* families. The RPi[45]'s do not use bootcode.bin or processor-code firmware files from any media. They do use some of the *.dtb and *.dtbo files from the media and some of the other non-processor-code files from there.

GPT-partitioned Raspberry Pi images were built using NanoBSD reimagined (a GSoC 2026 project); we currently have two Raspberry Pi 4 GPT-partitioned systems: one using UFS and another one using ZFS. See D59235 for current improvements/suggestions.

The RPI4 does not use the processor-code firmware files that were updated, just appropriate non-code files. Your test did not involve the processor-code firmware on the media at all when you tested using an RPi4. What version of the EEPROM content was in the RPI4 at the time? Part of that is what you tested instead. Testing RPi4's and RPi5 will always be insufficient for coverage of any other RPi* relative to processor-code firmware.

If you have access to an old Raspberry Pi, the test is to use release(7) with this updated port and verify that you can still boot. It will obviously use an MBR partition scheme, as that is what release/arm64/RPI.conf uses (PART_SCHEME="MBR"). It is just to verify that the new binaries do not break something.

I've been booting RPi4's and RPi5's via just USB GPT partitioned media for many years, no sd card media with RPi* processor code files involved. (The RPI5's are via EDK2 UEFI/ACPI drafts, not a FreeBSD port or a U-Boot.)

I'll note that I do boot GPT USB media now on the older RPi* --but in order to do so, I also have a MBR based SD card in each such older RPi*-- and that media has the bootcode.bin file to load, which, in turn, enables the GPT partition handling for later stages of the boot process.

I would suggest posting to the arm news group a request for the testing. My available range of RPi* is rather limited: One RPi2B v1.1 (cortex-A7 armv7), one RPi2B v1.2 (cortex-A53, aarch64), one RPi3B (cortex-A53, aarch64), some RPi4B's (cortex-A72's with 4 GiByte or 8 GiByte, B0T vintage other than one C0T vintage), one RPi5B C 1 vintage (cortext-A76 aarch64) with 8 GiBytes, one RPI5B D0 vintage (cortext-A76 aarch64) with 16 GiBytes. Most of these are rarely used these days.

I've never made a formal style release of FreeBSD as far as I remember, and am not familiar with the process of making official-style releases. I doubt that I would allocate the time and resources involved. I've be more likely to just substitute the files from an updated /usr/local/share/rpi-firmware/ (after installing the package from a poudriere-devel based build) onto the existing boot media. (I have one USB media that can be used in booting every FreeBSD aarch64 system that I have access to, not just RPi* aarch64 systems.)

In D58197#1361256, @markmi_dsl-only.net wrote:

In D58197#1361225, @jlduran wrote:

In D58197#1361219, @markmi_dsl-only.net wrote:

. . .

Thanks for taking a closer look at this. To clarify, are you suggesting a revert, or is this primarily a request to make the commit message more explicitly descriptive of what was tested?

I'm just noting that the goal specified was not achieved. The update did not change the status of GPT support for any RPi* . The tested environment ignores the processor-code files that actually holds executable firmware. The file updates may well be reasonable for other purposes --but may end up requiring FreeBSD kernel changes to track possible *.dtb and *.dtbo changes. That is one reason sysutils/rpi-firmware is rarely updated.

The goal of updating the firmware binaries isn't to give old, un-updatable hardware new internal EEPROM capabilities,

but rather to ensure that release(7) has access to the latest upstream binaries and that NanoBSD Reimagined can access them to boot a GPT-partitioned Raspberry Pi board.

Hybrid MBR/GPT? The older RPI* families require MBR to be involved, posibly via a hybrid MBR/GPT meeting certain criteria. No firmware read in from any boot media can change that initial requirement to get the boot process started. bootcode.bin has to be loaded from media that the old RPI*'s have internal MBR code to handle only MBR. Once bootcode.bin is loaded, only following stages can deal with GPT for the older RPI* families. The RPi[45]'s do not use bootcode.bin or processor-code firmware files from any media. They do use some of the *.dtb and *.dtbo files from the media and some of the other non-processor-code files from there.

GPT-partitioned Raspberry Pi images were built using NanoBSD reimagined (a GSoC 2026 project); we currently have two Raspberry Pi 4 GPT-partitioned systems: one using UFS and another one using ZFS. See D59235 for current improvements/suggestions.

The RPI4 does not use the processor-code firmware files that were updated, just appropriate non-code files. Your test did not involve the processor-code firmware on the media at all when you tested using an RPi4. What version of the EEPROM content was in the RPI4 at the time? Part of that is what you tested instead. Testing RPi4's and RPi5 will always be insufficient for coverage of any other RPi* relative to processor-code firmware.

If you have access to an old Raspberry Pi, the test is to use release(7) with this updated port and verify that you can still boot. It will obviously use an MBR partition scheme, as that is what release/arm64/RPI.conf uses (PART_SCHEME="MBR"). It is just to verify that the new binaries do not break something.

I've been booting RPi4's and RPi5's via just USB GPT partitioned media for many years, no sd card media with RPi* processor code files involved. (The RPI5's are via EDK2 UEFI/ACPI drafts, not a FreeBSD port or a U-Boot.)

I'll note that I do boot GPT USB media now on the older RPi* --but in order to do so, I also have a MBR based SD card in each such older RPi*-- and that media has the bootcode.bin file to load, which, in turn, enables the GPT partition handling for later stages of the boot process.

I would suggest posting to the arm news group a request for the testing. My available range of RPi* is rather limited: One RPi2B v1.1 (cortex-A7 armv7), one RPi2B v1.2 (cortex-A53, aarch64), one RPi3B (cortex-A53, aarch64), some RPi4B's (cortex-A72's with 4 GiByte or 8 GiByte, B0T vintage other than one C0T vintage), one RPi5B C 1 vintage (cortext-A76 aarch64) with 8 GiBytes, one RPI5B D0 vintage (cortext-A76 aarch64) with 16 GiBytes. Most of these are rarely used these days.

I've never made a formal style release of FreeBSD as far as I remember, and am not familiar with the process of making official-style releases. I doubt that I would allocate the time and resources involved. I've be more likely to just substitute the files from an updated /usr/local/share/rpi-firmware/ (after installing the package from a poudriere-devel based build) onto the existing boot media. (I have one USB media that can be used in booting every FreeBSD aarch64 system that I have access to, not just RPi* aarch64 systems.)

To put is simple:

# gpart show
=>      40  31116208  sdda0  GPT  (15G)
        40      8152         - free -  (4.0M)
      8192   1024000      1  ms-basic-data  (500M)
   1032192    532480      2  efi  (260M)
   1564672  29551576      3  freebsd-zfs  (14G)

# sysctl hw.fdt
hw.fdt.serial-number: 100000009df81ae6
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.4

Without the update in this revision, this was not possible.

In D58197#1361279, @jlduran wrote:

In D58197#1361256, @markmi_dsl-only.net wrote:

In D58197#1361225, @jlduran wrote:

In D58197#1361219, @markmi_dsl-only.net wrote:

. . .

. . .

To put is simple:

# gpart show
=>      40  31116208  sdda0  GPT  (15G)
        40      8152         - free -  (4.0M)
      8192   1024000      1  ms-basic-data  (500M)
   1032192    532480      2  efi  (260M)
   1564672  29551576      3  freebsd-zfs  (14G)

# sysctl hw.fdt
hw.fdt.serial-number: 100000009df81ae6
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.4

Without the update in this revision, this was not possible.

Much older RPI* files (and, likely, u-boot and such) used with an official pkgbase distribution of main from a while back:

# sysctl hw.fdt
hw.fdt.serial-number: 10000000c740af3c
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.5
# uname -apKU
FreeBSD aarch64-main-PkgBase 16.0-CURRENT FreeBSD 16.0-CURRENT main-n287813-a77257d60058 GENERIC-NODEBUG arm64 aarch64 1600019 1600019
aarch64-main-PkgBase aarch64  1600019 1600019 # ls -lodTt /boot/efi/*
drwxr-xr-x  1 root wheel -        8192 Oct 24 12:48:26 2025 /boot/efi/dtb
-rwxr-xr-x  1 root wheel uarch       0 Feb 20 02:29:58 2024 /boot/efi/timeout
-rwxr-xr-x  1 root wheel uarch  623400 Jan 24 09:59:48 2024 /boot/efi/u-boot.bin
drwxr-xr-x  1 root wheel -        8192 Jan 11 09:39:34 2024 /boot/efi/overlays
drwxr-xr-x  1 root wheel -        8192 Jan 11 09:39:22 2024 /boot/efi/EFI
-rwxr-xr-x  1 root wheel uarch    5888 Jan 11 05:43:38 2024 /boot/efi/armstub8-gic.bin
-rwxr-xr-x  1 root wheel uarch    5888 Jan 11 05:43:38 2024 /boot/efi/armstub8.bin
-rwxr-xr-x  1 root wheel uarch     240 Jan 11 05:34:58 2024 /boot/efi/README
-rwxr-xr-x  1 root wheel uarch    1480 Jan  4 11:50:04 2024 /boot/efi/config.txt
-rwxr-xr-x  1 root wheel uarch    1594 Apr  5 11:32:16 2023 /boot/efi/LICENCE.broadcom
-rwxr-xr-x  1 root wheel uarch   30390 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-2-b.dtb
-rwxr-xr-x  1 root wheel uarch   32753 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root wheel uarch   32142 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root wheel uarch   30285 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root wheel uarch   52593 Apr  5 11:32:16 2023 /boot/efi/bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root wheel uarch   52476 Apr  5 11:32:16 2023 /boot/efi/bootcode.bin
-rwxr-xr-x  1 root wheel uarch    7266 Apr  5 11:32:16 2023 /boot/efi/fixup.dat
-rwxr-xr-x  1 root wheel uarch    5399 Apr  5 11:32:16 2023 /boot/efi/fixup4.dat
-rwxr-xr-x  1 root wheel uarch    3173 Apr  5 11:32:16 2023 /boot/efi/fixup4cd.dat
-rwxr-xr-x  1 root wheel uarch    8381 Apr  5 11:32:16 2023 /boot/efi/fixup4db.dat
-rwxr-xr-x  1 root wheel uarch    8387 Apr  5 11:32:16 2023 /boot/efi/fixup4x.dat
-rwxr-xr-x  1 root wheel uarch    3173 Apr  5 11:32:16 2023 /boot/efi/fixup_cd.dat
-rwxr-xr-x  1 root wheel uarch   10230 Apr  5 11:32:16 2023 /boot/efi/fixup_db.dat
-rwxr-xr-x  1 root wheel uarch   10228 Apr  5 11:32:16 2023 /boot/efi/fixup_x.dat
-rwxr-xr-x  1 root wheel uarch 2975680 Apr  5 11:32:16 2023 /boot/efi/start.elf
-rwxr-xr-x  1 root wheel uarch 2251392 Apr  5 11:32:16 2023 /boot/efi/start4.elf
-rwxr-xr-x  1 root wheel uarch  805756 Apr  5 11:32:16 2023 /boot/efi/start4cd.elf
-rwxr-xr-x  1 root wheel uarch 3747688 Apr  5 11:32:16 2023 /boot/efi/start4db.elf
-rwxr-xr-x  1 root wheel uarch 2998888 Apr  5 11:32:16 2023 /boot/efi/start4x.elf
-rwxr-xr-x  1 root wheel uarch  805756 Apr  5 11:32:16 2023 /boot/efi/start_cd.elf
-rwxr-xr-x  1 root wheel uarch 4819624 Apr  5 11:32:16 2023 /boot/efi/start_db.elf
-rwxr-xr-x  1 root wheel uarch 3722504 Apr  5 11:32:16 2023 /boot/efi/start_x.elf
-rwxr-xr-x  1 root wheel uarch      88 Dec 31 23:00:00 1979 /boot/efi/ubootefi.var
# gpart show 
=>        34  1875384941  da0  GPT  (894G)
          34       32734       - free -  (16M)
       32768      501760    1  efi  (245M)
      534528    20971520    2  freebsd-swap  (10G)
    21506048    29360128    3  freebsd-swap  (14G)
    50866176    33554432    4  freebsd-swap  (16G)
    84420608    67108864    5  freebsd-swap  (32G)
   151529472    96468992    6  freebsd-swap  (46G)
   247998464   268435456    7  freebsd-swap  (128G)
   516433920     7340032    8  freebsd-swap  (3.5G)
   523773952    13631488   10  freebsd-swap  (6.5G)
   537405440  1337979528    9  freebsd-ufs  (638G)
  1875384968           7       - free -  (3.5K)
# gpart show -p
=>        34  1875384941     da0  GPT  (894G)
          34       32734          - free -  (16M)
       32768      501760   da0p1  efi  (245M)
      534528    20971520   da0p2  freebsd-swap  (10G)
    21506048    29360128   da0p3  freebsd-swap  (14G)
    50866176    33554432   da0p4  freebsd-swap  (16G)
    84420608    67108864   da0p5  freebsd-swap  (32G)
   151529472    96468992   da0p6  freebsd-swap  (46G)
   247998464   268435456   da0p7  freebsd-swap  (128G)
   516433920     7340032   da0p8  freebsd-swap  (3.5G)
   523773952    13631488  da0p10  freebsd-swap  (6.5G)
   537405440  1337979528   da0p9  freebsd-ufs  (638G)
  1875384968           7          - free -  (3.5K)
# gpart show -pl
=>        34  1875384941     da0  GPT  (894G)
          34       32734          - free -  (16M)
       32768      501760   da0p1  PkgBaseEFI  (245M)
      534528    20971520   da0p2  PkgBaseSwp10  (10G)
    21506048    29360128   da0p3  PkgBaseSwp14  (14G)
    50866176    33554432   da0p4  PkgBaseSwp16  (16G)
    84420608    67108864   da0p5  PkgBaseSwp32  (32G)
   151529472    96468992   da0p6  PkgBaseSwp46  (46G)
   247998464   268435456   da0p7  PkgBaseSwp128  (128G)
   516433920     7340032   da0p8  PkgBaseSwp3p5  (3.5G)
   523773952    13631488  da0p10  PkgBaseSwp6p5  (6.5G)
   537405440  1337979528   da0p9  PkgBaseUFS  (638G)
  1875384968           7          - free -  (3.5K)

Note: There are lots of files not used/needed by the RPi4 because this same media boots other systems: not minimal. (I did not show subdirectory contents above: shorter.) My config.txt is customized. My use of timeout is because I have some media that need the extra time and all the RPI* capable boot media have the file.

The same media boots the v1.1 and v1.4 and v1.5 RPi4B's that I happen to have access to. v1.5 was just handy to put to use.

One structural difference is that my context's efi partition is first instead of second, not that I know if such makes a behavioral difference. I have no idea why you have a ms-basic-data partition.

Have you published someplace boot log(s) from the context that did not work? What was the evidence related to the failure?

In D58197#1361299, @markmi_dsl-only.net wrote:

In D58197#1361279, @jlduran wrote:

In D58197#1361256, @markmi_dsl-only.net wrote:

In D58197#1361225, @jlduran wrote:

In D58197#1361219, @markmi_dsl-only.net wrote:

. . .

. . .

To put is simple:

# gpart show
=>      40  31116208  sdda0  GPT  (15G)
        40      8152         - free -  (4.0M)
      8192   1024000      1  ms-basic-data  (500M)
   1032192    532480      2  efi  (260M)
   1564672  29551576      3  freebsd-zfs  (14G)

# sysctl hw.fdt
hw.fdt.serial-number: 100000009df81ae6
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.4

Without the update in this revision, this was not possible.

Much older RPI* files (and, likely, u-boot and such) used with an official pkgbase distribution of main from a while back:

# sysctl hw.fdt
hw.fdt.serial-number: 10000000c740af3c
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.5
# uname -apKU
FreeBSD aarch64-main-PkgBase 16.0-CURRENT FreeBSD 16.0-CURRENT main-n287813-a77257d60058 GENERIC-NODEBUG arm64 aarch64 1600019 1600019
aarch64-main-PkgBase aarch64  1600019 1600019 # ls -lodTt /boot/efi/*
drwxr-xr-x  1 root wheel -        8192 Oct 24 12:48:26 2025 /boot/efi/dtb
-rwxr-xr-x  1 root wheel uarch       0 Feb 20 02:29:58 2024 /boot/efi/timeout
-rwxr-xr-x  1 root wheel uarch  623400 Jan 24 09:59:48 2024 /boot/efi/u-boot.bin
drwxr-xr-x  1 root wheel -        8192 Jan 11 09:39:34 2024 /boot/efi/overlays
drwxr-xr-x  1 root wheel -        8192 Jan 11 09:39:22 2024 /boot/efi/EFI
-rwxr-xr-x  1 root wheel uarch    5888 Jan 11 05:43:38 2024 /boot/efi/armstub8-gic.bin
-rwxr-xr-x  1 root wheel uarch    5888 Jan 11 05:43:38 2024 /boot/efi/armstub8.bin
-rwxr-xr-x  1 root wheel uarch     240 Jan 11 05:34:58 2024 /boot/efi/README
-rwxr-xr-x  1 root wheel uarch    1480 Jan  4 11:50:04 2024 /boot/efi/config.txt
-rwxr-xr-x  1 root wheel uarch    1594 Apr  5 11:32:16 2023 /boot/efi/LICENCE.broadcom
-rwxr-xr-x  1 root wheel uarch   30390 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-2-b.dtb
-rwxr-xr-x  1 root wheel uarch   32753 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root wheel uarch   32142 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root wheel uarch   30285 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root wheel uarch   52593 Apr  5 11:32:16 2023 /boot/efi/bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root wheel uarch   52476 Apr  5 11:32:16 2023 /boot/efi/bootcode.bin
-rwxr-xr-x  1 root wheel uarch    7266 Apr  5 11:32:16 2023 /boot/efi/fixup.dat
-rwxr-xr-x  1 root wheel uarch    5399 Apr  5 11:32:16 2023 /boot/efi/fixup4.dat
-rwxr-xr-x  1 root wheel uarch    3173 Apr  5 11:32:16 2023 /boot/efi/fixup4cd.dat
-rwxr-xr-x  1 root wheel uarch    8381 Apr  5 11:32:16 2023 /boot/efi/fixup4db.dat
-rwxr-xr-x  1 root wheel uarch    8387 Apr  5 11:32:16 2023 /boot/efi/fixup4x.dat
-rwxr-xr-x  1 root wheel uarch    3173 Apr  5 11:32:16 2023 /boot/efi/fixup_cd.dat
-rwxr-xr-x  1 root wheel uarch   10230 Apr  5 11:32:16 2023 /boot/efi/fixup_db.dat
-rwxr-xr-x  1 root wheel uarch   10228 Apr  5 11:32:16 2023 /boot/efi/fixup_x.dat
-rwxr-xr-x  1 root wheel uarch 2975680 Apr  5 11:32:16 2023 /boot/efi/start.elf
-rwxr-xr-x  1 root wheel uarch 2251392 Apr  5 11:32:16 2023 /boot/efi/start4.elf
-rwxr-xr-x  1 root wheel uarch  805756 Apr  5 11:32:16 2023 /boot/efi/start4cd.elf
-rwxr-xr-x  1 root wheel uarch 3747688 Apr  5 11:32:16 2023 /boot/efi/start4db.elf
-rwxr-xr-x  1 root wheel uarch 2998888 Apr  5 11:32:16 2023 /boot/efi/start4x.elf
-rwxr-xr-x  1 root wheel uarch  805756 Apr  5 11:32:16 2023 /boot/efi/start_cd.elf
-rwxr-xr-x  1 root wheel uarch 4819624 Apr  5 11:32:16 2023 /boot/efi/start_db.elf
-rwxr-xr-x  1 root wheel uarch 3722504 Apr  5 11:32:16 2023 /boot/efi/start_x.elf
-rwxr-xr-x  1 root wheel uarch      88 Dec 31 23:00:00 1979 /boot/efi/ubootefi.var
# gpart show 
=>        34  1875384941  da0  GPT  (894G)
          34       32734       - free -  (16M)
       32768      501760    1  efi  (245M)
      534528    20971520    2  freebsd-swap  (10G)
    21506048    29360128    3  freebsd-swap  (14G)
    50866176    33554432    4  freebsd-swap  (16G)
    84420608    67108864    5  freebsd-swap  (32G)
   151529472    96468992    6  freebsd-swap  (46G)
   247998464   268435456    7  freebsd-swap  (128G)
   516433920     7340032    8  freebsd-swap  (3.5G)
   523773952    13631488   10  freebsd-swap  (6.5G)
   537405440  1337979528    9  freebsd-ufs  (638G)
  1875384968           7       - free -  (3.5K)
# gpart show -p
=>        34  1875384941     da0  GPT  (894G)
          34       32734          - free -  (16M)
       32768      501760   da0p1  efi  (245M)
      534528    20971520   da0p2  freebsd-swap  (10G)
    21506048    29360128   da0p3  freebsd-swap  (14G)
    50866176    33554432   da0p4  freebsd-swap  (16G)
    84420608    67108864   da0p5  freebsd-swap  (32G)
   151529472    96468992   da0p6  freebsd-swap  (46G)
   247998464   268435456   da0p7  freebsd-swap  (128G)
   516433920     7340032   da0p8  freebsd-swap  (3.5G)
   523773952    13631488  da0p10  freebsd-swap  (6.5G)
   537405440  1337979528   da0p9  freebsd-ufs  (638G)
  1875384968           7          - free -  (3.5K)
# gpart show -pl
=>        34  1875384941     da0  GPT  (894G)
          34       32734          - free -  (16M)
       32768      501760   da0p1  PkgBaseEFI  (245M)
      534528    20971520   da0p2  PkgBaseSwp10  (10G)
    21506048    29360128   da0p3  PkgBaseSwp14  (14G)
    50866176    33554432   da0p4  PkgBaseSwp16  (16G)
    84420608    67108864   da0p5  PkgBaseSwp32  (32G)
   151529472    96468992   da0p6  PkgBaseSwp46  (46G)
   247998464   268435456   da0p7  PkgBaseSwp128  (128G)
   516433920     7340032   da0p8  PkgBaseSwp3p5  (3.5G)
   523773952    13631488  da0p10  PkgBaseSwp6p5  (6.5G)
   537405440  1337979528   da0p9  PkgBaseUFS  (638G)
  1875384968           7          - free -  (3.5K)

One structural difference is that my context's efi partition is first instead of second, not that I know if such makes a behavioral difference. I have no idea why you have a ms-basic-data partition.

Have you published someplace boot log(s) from the context that did not work? What was the evidence related to the failure?

I appreciate your interest in this subject. Let's move the discussion to another venue (discord?), unless of course, you want to revert this commit.
Note that I am booting using a micro SD card.
Just to answer your question as to why one efi partition and one ms-basic-data, this should be implied in D59235, at least in part. This is a nuageinit (cloud-init) partition, and I do not want to mix it with the EFI partition, as in the future, NanoBSD may use many EFI partitions; I would prefer to keep them separate (EFI and CIDATA) (an added advantage to this is that most operating systems will only automount the CIDATA partition). However, you can use just one msdos partition, if you are so inclined.
I propose performing the following test:

I can build a NanoBSD image using the old port, and flash it to my micro SD card.
Attempt to boot and note the exact green LED blinking pattern (I forgot which one it was). EDIT: green LED 7 short flashes (Kernel image not found).
Copy the new files to the msdos partition and boot normally.

If you propose additional tests, those are greatly welcomed.
I'm just unwilling to keep posting comments to this Phabricator Review unless this commit has actually broken something.
Feel free to contact me by email. Thank you.

1.20260521 did not actually fix the aarch64 RPi4B "green LED 7 short flashes (Kernel image not found)" issue that happens when GPT is involved on microsd cards used in the built-in slot, GPT used as in the test image that I was given for use in my testing.

The uncommitted 1.20260824 files do fix such in my testing. Specifically the files I copied that got tests results that booted were the *.bin , *.dat , and *.elf files listed below that are from an unxz of:

https://github.com/raspberrypi/firmware/releases/download/1.20260824/raspi-firmware_1.20260824.orig.tar.xz

# tar -xpf raspi-firmware_1.20260824.orig.tar
# ls -loaT raspi-firmware-1.20260824/boot/
total 22472
drwxrwxr-x  2 root wheel -     512 Aug 24 07:40:54 2026 .
drwxrwxr-x  3 root wheel -     512 Aug 24 07:40:54 2026 ..
-rw-rw-r--  1 root wheel -    1594 Aug 24 07:40:54 2026 LICENCE.broadcom
-rw-rw-r--  1 root wheel -   52624 Aug 24 07:40:54 2026 bootcode.bin
-rw-rw-r--  1 root wheel -    7381 Aug 24 07:40:54 2026 fixup.dat
-rw-rw-r--  1 root wheel -    5512 Aug 24 07:40:54 2026 fixup4.dat
-rw-rw-r--  1 root wheel -    3282 Aug 24 07:40:54 2026 fixup4cd.dat
-rw-rw-r--  1 root wheel -    8505 Aug 24 07:40:54 2026 fixup4db.dat
-rw-rw-r--  1 root wheel -    8501 Aug 24 07:40:54 2026 fixup4x.dat
-rw-rw-r--  1 root wheel -    3282 Aug 24 07:40:54 2026 fixup_cd.dat
-rw-rw-r--  1 root wheel -   10348 Aug 24 07:40:54 2026 fixup_db.dat
-rw-rw-r--  1 root wheel -   10350 Aug 24 07:40:54 2026 fixup_x.dat
-rwxrwxr-x  1 root wheel - 3022336 Aug 24 07:40:54 2026 start.elf
-rw-rw-r--  1 root wheel - 2298048 Aug 24 07:40:54 2026 start4.elf
-rw-rw-r--  1 root wheel -  843580 Aug 24 07:40:54 2026 start4cd.elf
-rw-rw-r--  1 root wheel - 3796040 Aug 24 07:40:54 2026 start4db.elf
-rw-rw-r--  1 root wheel - 3045288 Aug 24 07:40:54 2026 start4x.elf
-rwxrwxr-x  1 root wheel -  843580 Aug 24 07:40:54 2026 start_cd.elf
-rwxrwxr-x  1 root wheel - 4868072 Aug 24 07:40:54 2026 start_db.elf
-rwxrwxr-x  1 root wheel - 3768968 Aug 24 07:40:54 2026 start_x.elf

These do not enable RPi3B or RPi2B v1.2 GPT booting from microsd card in the built-in slot. FreeBSD has no RPi5 sysutils/u-boot-* or releases and, so, is untested by me. I've no access to other RPi* variations.

As for this commit based on 1.20260521 . . .

While this commit added a lot of files to sysutils/rpi-firmware , the /usr/src/release/arm64/RPI.conf was not updated to put any of them to use. My testing was targeted to a subset of what RPI.conf provides, based on what I have access to.

My testing was basically limited to boot failures vs. not, mostly the RPi4B "green LED 7 short flashes (Kernel image not found)" issue, as, until fixed, it blocked doing anything else for the RPi4B's. The testing used a modified context to dump out RPi* debug information and such and to avoid video, capturing serial console output. I also used the content of config_arm64.txt in config.txt , unlike the armv7 content in the test image that I was given.

I did not find 1.20260521 to change booting for what I had to test with: still broken from before.

For my limited context and type of testing, 1.20260521 did not seem to create new problems but also did not solve any. So: No known reason to revert even though it did not fix the RPi4B "green LED 7 short flashes (Kernel image not found)" issue.

NOTE added later:
Jose produced an image based on 1.20260521 and had me test the 3 types of RPi4B variants based on it (unmodified, no debugging or other changes). All 3 booted. I only checked the vintage of *.elf files:

start4.elf (and other *.elf files) have (showed via grep and tr , strings not being available):

VC_BUILD_ID_TIME: May 21 2026

and:

VC_BUILD_ID_VERSION: 288930ab4712b99596f32732664aaaeb881ef1e0 (clean)

This is the same vintage that I had failures with starting from the prior "known to fail" image that I was testing/debugging with. For that context and starting point, booting failed every time --even after manually updating the RPi* fiirmware files to the 1.20260521 files [that have the same *.elf vintage]-- until I put in place the August update *.elf and *.dat and bootcode.bin files [where the *.elf files had been updated].

bootcode.bin is unused by EEPROM based RPI* [so: 4 and 5 ignore it].