Hi Quentin, On Mon, Sep 28, 2026 at 5:26 PM Quentin Schulz <[email protected]> wrote: > > Hi Alexey, > > On 7/31/26 7:10 PM, Alexey Charkov wrote: > > When a generated FIT is used to boot Linux directly, bypassing U-Boot > > proper (Falcon mode), there is no runtime code to discover the kernel > > command line and (optional) initrd location and include them in a FDT. > > > > To facilitate easier preparation of a ready-to-boot FIT, add support for > > pre-patching the FDTs in a FIT with a preconfigured /chosen node including > > the bootargs and initrd location. > > > > This sounds wrong to me. Why should we hardcode those at build time? We > already do DT fixups in U-Boot proper *at runtime*, so we should > probably do the same in xPL when booting in Falcon mode instead of > hardcoding stuff. Since you're aware of this, I'm guessing you decided > against, but you don't tell us why. I'm a bit worried going with the > suggested implementation means we'll eventually have a binman node > property for each DT node/property we want to write/override.
The "regular" Falcon way of doing things (i.e. the one not involving TF-A) has so far been: "capture what U-Boot patches into the args to be passed to the kernel, package it into a fixed binary, and boot only that". No runtime fixups. So I more or less followed that pattern, but tried to make it a bit more accessible by eliminating the "capture something at runtime and save it somehow somewhere" step, which I find unnecessarily painful. Maybe runtime fixups could be brought into xPL, but they are excruciatingly slow, whereas speed is the main reason for wanting Falcon mode boot in the first place. Right now with Falcon mode on RK3576 I'm getting 2.5 seconds from applying power to _userspace_ (i.e. full graphical UI drawn on the screen), whereas the best I could get with U-Boot is just over 3s to its boot menu, much of that time spent going over the flat devicetree before relocation in O(n^2) passes. And those 3s are after stripping the massive pinctrl node with hundreds of its always-present children from the pre-relocation DT, which alone saves ~0.4s. > > Signed-off-by: Alexey Charkov <[email protected]> > > --- > > tools/binman/entry.py | 8 ++++ > > tools/binman/etype/fit.py | 103 > > ++++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 111 insertions(+) > > > > diff --git a/tools/binman/entry.py b/tools/binman/entry.py > > index ce7ef28e94b1..e0dea8bf3a49 100644 > > --- a/tools/binman/entry.py > > +++ b/tools/binman/entry.py > > @@ -636,6 +636,14 @@ class Entry(object): > > self.Detail('GetData: size %s' % to_hex_size(self.data)) > > return self.data > > > > + def GetNode(self): > > + """Get the devicetree node which describes this entry > > + > > + Returns: > > + Node: Node for this entry > > + """ > > + return self._node > > + > > def GetPaddedData(self, data=None): > > """Get the data for an entry including any padding > > > > diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py > > index 32caa03a7e16..750ff5b47ed5 100644 > > --- a/tools/binman/etype/fit.py > > +++ b/tools/binman/etype/fit.py > > @@ -304,6 +304,40 @@ class Entry_fit(Entry_section): > > > > See :ref:`fdtgrep_filter` for more information. > > > > + Patching /chosen into the generated device trees > > + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > + When the OS is booted directly from this FIT (e.g. Falcon mode) U-Boot > > + proper never runs, so its usual runtime /chosen fixups do not happen. > > Two > > + optional properties on the `@fdt-SEQ` node make binman patch each > > generated > > + device tree at build time: > > + > > + fit,bootargs > > + A string written to /chosen/bootargs of every generated device tree > > + (any existing value is overwritten). Typically set to > > `CONFIG_BOOTARGS` > > + via the preprocessed devicetree source. > > + > > + fit,initrd > > + The image name of a loadable (e.g. "ramdisk") to use as the > > initramfs. > > + Its `load` address and packed size are written to > > + /chosen/linux,initrd-start and /chosen/linux,initrd-end (at the > > width of > > + the device tree's root #address-cells) and reserved in the FDT > > + memory-reservation map, mirroring fdt_initrd(). If the referenced > > image > > + is absent or empty (e.g. an optional initramfs that was not > > supplied) > > + the initrd properties are omitted. > > + > > This sounds wrong, why would the FDT image node need to know about which > ramdisk may be used? Shouldn't we rather have a ramdisk property in a > configuration node, and then patch the FDT based on that information? Falcon mode boot where these are useful is for a fixed-configuration boot flow anyway, where one wouldn't have a way to select among several ramdisks to go with the kernel image. So putting this information directly where the user (i.e. the kernel) will find it cuts out intermediate steps, which in turn improves speed and reduces complexity. Best regards, Alexey
