[PATCH 4/4] rockchip: binman: Add support for Falcon mode FIT images with ATF+Linux

[Alexey Charkov]

Hi Quentin,

On Fri, Jun 26, 2026 at 3:32 PM Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Alexey,
>
> On 6/9/26 6:52 PM, Alexey Charkov wrote:
> > Modern Rockchip SoCs such as RK3576 require ATF to be running to provide
> > firmware services to the OS. To enable booting Linux in Falcon mode on
> > such SoCs, add binman support for generation of FIT images containing
> > appropriately split ATF raw binaries (as is currently done by binman for
> > U-boot proper images), externally preprocessed DTB and a Linux kernel.
> >
>
> This is a bit misleading I believe. This is generating an image for
> falcon booting via USB download mode. The earlier patches support falcon
> boot when booting from standard storage media. We do not need this to do
> falcon boot in general (or maybe I misunderstood).

This patch creates both a USB download-able image (with SPL prepended)
and a "plain" FIT with Linux as the payload for booting via Falcon
mode, which can be written to persistent storage.

> I'm against this patch, specifically the part modifying
> rockchip-u-boot.dtsi. The only U-Boot part in the whole process is
> concatenating SPL with the new FIT image (which has the FDT optionally
> coming from it else externally), which you can do outside of U-Boot
> yourself. I don't see why U-Boot should accept this patch but maybe I'm
> missing something?

U-boot here (or rather its preconfigured binman instance) is mostly
parsing the TF-A ELF file and creating atf-SEQ entries in the image.
It also ensures consistency between what U-boot SPL expects (as it's
encoded in the current rockchip-u-boot.dtsi) and what lands in the
Falcon FIT image. It is possible to generate the Falcon FIT
independently of the U-boot tree, but doing so manually is a royal
pain. I believe in the end people would still use the U-boot codebase
as the image generator, but we'll just make their lives more miserable
if we can't include an entry in the existing template (with the
deduplication Jonas suggested).

> This implementation is also specific to Linux, will we have patches to
> support Zephyr, FreeBSD, etc... in the future? I see this as opening a
> door for things we don't want to have to deal with. How will you deal
> with multiple device trees? With device tree overlays? How will you deal
> with A/B update mechanism with falcon boot?

Currently U-boot SPL doesn't support direct boot into Zephyr, FreeBSD
etc, from what I can see, but it does support Linux images on other
platforms (those not needing TF-A) even without my patches. So other
OSes are out of scope, as are device tree overlays. Falcon by design
only supports a pre-patched DTB with all runtime detection already
baked in [1], so one would likely pre-apply any required overlay(s)
along with the /chosen node fixups before including the DTB into the
FIT image.

Multiple device trees should work once I implement Jonas' suggestion,
as long as they are runtime selectable by compatible strings via board
code. It's not a generic distro-boot mechanism though and will
probably never be one, because it's coupled to specific hardware by
design.

A/B updates should work (or not work) the same way as A/B updates of
the U-boot proper work (or don't work), respectively. I haven't yet
explored that avenue, but can't see a fundamental reason why it
couldn't be done.

[1] https://docs.u-boot.org/en/stable/develop/falcon.html#example-with-fdt-a3m071-board

> To be clear, I'm not saying what this allows is a bad idea, I'm saying
> U-Boot is not the right place for this.

Well the U-Boot repo historically hosts `mkimage`, which packs a Linux
kernel (or something else) into a format U-Boot understands. I see
substantial similarities between these cases.

Best regards,
Alexey