[PATCH v3 0/7] Add FIT multi-DTB selection for Qualcomm platforms

[Sumit Garg]

On Fri, May 01, 2026 at 09:39:53AM +0200, Jan Kiszka wrote:
> On 01.05.26 08:54, Sumit Garg wrote:
> > Hi Jan,
> > 
> > On Fri, Apr 17, 2026 at 02:15:43PM +0200, Jan Kiszka wrote:
> >> On 17.04.26 14:09, Aswin Murugan wrote:
> >>> This series adds dynamic device tree selection from FIT images for
> >>> Qualcomm Snapdragon platforms, enabling U-Boot to select the
> >>> appropriate DTB based on hardware parameters detected from SMEM.
> >>>
> >>> Qualcomm fit based DTB format is documented in [1]
> >>> The fit image contains only DTB, while the kernel will be part of UKI image.
> >>>
> >>
> >> I suppose you know that UKIs (systemd-boot, EFI Boot Guard) provide DTB
> >> selection as well. However, that is a fix-up for the case the firmware
> >> does not provide a fitting DTB. This here is supposed to support the
> >> firmware DTB delivery, correct?
> >>
> > 
> > I would say instead that it's an alternate way to bundle multiple DTBs
> > in a specific DT partition which are used by firmware to select
> > appropriate DTB for the board the firmware is running on.
> 
> Right. We (and likely not only us) implemented that kind of DTB
> selection many years ago for the IOT2050 boards with existing U-Boot
> features here. But we embedded the supported DTBs into the U-Boot FIT
> image so that they naturally become part of the secure boot chain.

Yeah but this apporach of DTBs only FIT decouples it from how kernel
secure boot chain works whether it's based on UEFI secure boot or FIT
based or any other approach.

> 
> > 
> > The source of this DTBs are from kernel only where the OEM has to take
> > care of 1:1 compatibility among kernel and DTB. This approach has been
> > deployed for Yocto and Android based systems but I do agree with general
> > purpose distros bundling DTBs in UKIs is surely an alternative option.
> 
> This is just a workaround for broken vendor firmware or vendor kernels.
> In the ideal world, the firmware delivers an upstream-approved DTB to an
> upstream kernel. Any update of firmware or kernel only augments bindings
> and DTBs, adding features or refining them in a compatible way, not
> breaking them - SystemReady.

Here this multi DTB isn't part of the kernel image and nor part of the
firmware image but has to get independent updates which surely have to
be aligned with the kernel to avoid any breakage. However, this approach
tries to acheive SystemReady in that way.

> 
> In real world, premature vendor code gets shipped first and only cleaned
> up later on via upstream (if at all). Then you need to fix up the
> mismatches between in-field firmware and upstreamed kernels. And all
> that obviously in secure, updatable way, therefore UKI embedding.
>

I do agree the DT incompatibilities are always hard to manage however
the vertically integrated stacks like Android or Yocto which Qualcomm
SoCs supported don't always want DTBs or overlays to be bundled alongside
the kernel image. However, surely we want the general purpose distros to
be supported as well which can always over-ride DT as needed.

In summary, from Qualcomm point of view, we will try to support both these
multi FIT DTBs approach as well as the UKI bundling. In the end it really
depends on the OS vendors to choose whichever approach suits best to
their needs when it comes to in field updates.

-Sumit