Hi Quentin, On Fri, Jun 26, 2026 at 3:32 PM Quentin Schulz <[email protected]> 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
