Re: [RFC PATCH v1 0/3] efi_loader: Introduce platform hook for FDT selection

[Sumit Garg <sumit.garg@kernel.org>]

On Mon, Jan 12, 2026 at 02:48:21PM +0100, Casey Connolly wrote:
> Hi Aswin,
> 
> On 10/01/2026 09:30, Aswin Murugan wrote:
> > Thanks everyone for all the valuable feedback. I appreciate the detailed
> > reviews and want to address the concerns raised.
> > 
> > I should have been clearer upfront about what makes Qualcomm platforms
> > different here. Qualcomm has its own combined-dtb format that's been
> > used across Linux products. The format is documented in [1] and the
> > combined dtb file is placed in a separate dtb partition
> > 
> > The combined-dtb file contains multiple DTBs concatenated together as a
> > single dtb file, each with Qualcomm-specific properties:
> > - qcom,msm-id (platform ID and SoC revision)
> > - qcom,board-id (board variant and subtype)
> > - qcom,pmic-id (PMIC models - up to 4)
> > 
> > At runtime, we read hardware info from SMEM (shared memory interface
> > with the firmware) and match it against these properties to pick the
> > right DTB.
> > 
> > *Why Existing Approaches Don't Quite Fit*
> > 
> > After reviewing the feedback from Heinrich, Ilias, Simon & Sumith, I
> > realize the core issue is that all the existing U-Boot mechanisms assume
> > separate DTB files on the ESP:
> > 
> > VisionFive2 approach: Uses EEPROM detection in SPL and sets `$fdtfile`
> > to point to individual files like `dtb/starfive/jh7110-milkv-mars.dtb`,
> > `dtb/starfive/jh7110-starfive-visionfive-2-v1.3b.dtb`
> > 
> > eficonfig and distro boot: These mechanisms work great for selecting
> > between multiple DTB files.
> > 
> > The common thread is they all expect individual DTB files, while
> > Qualcomm's deployment model uses a single combined-dtb.dtb file that
> > requires parsing and extraction. This is the fundamental gap we're
> > trying to bridge.
> > 
> >  I agree with Simon that using the weak function approach is not an
> > ideal solution. we should be avoiding adding hooks in the EFI loader.
> > Instead, we need to handle this at the board level and work with the
> > existing `$fdtfile` mechanism.
> > 
> > *Proposed Approach*
> > 
> > Based on all the feedback, here's the revised plan:
> > For v2:
> > 1. In board code: Parse combined-dtb.dtb, extract the matching DTB,
> > write to ESP as `dtb/qcom-<board>.dtb`
> 
> In board code - this should be a new file in mach-snapdragon with a new
> config option.
> 
> I don't think it's correct to write to the ESP, that's a very good way
> to frustrate users and developers imo. Once the proper FDT has been
> found it can be installed as the default for EFI booting by setting
> $fdt_addr to point to it (see efi_install_fdt() in
> lib/efi_loader/efi_helper.c), as well as setting $fdtfile
> 
> This way fdt_addr can be overwritten during boot by the user, and if
> there is an FDT found on the ESP then we can be sure it was put there by
> the distro or user and it should be used instead.
> 
> So in the end the priority of where the FDT is sourced from will look
> like this:
> 
> 1. OS loader (GRUB/sd-boot)
> 2. FDT loaded/configured by user (e.g. in eficonfig)
> 3. DTB found on the ESP by U-Boot (based on $fdtfile)
> 4. FDT from qcom-specific dtb partition
> 5. U-Boot's own FDT
> 
> I think this strikes a good balance without imposing confusing logic on
> the user, particularly if there is a nice log message when the FDT is
> installed from the qcom combined DTB.

Sounds reasonable to me.

-Sumit

> 
> Kind regards,
> 
> > 3. Set `$fdtfile` to point to the extracted file
> > 4. Let standard EFI mechanisms handle the rest
> > 5. Drop the weak function approach entirely
> > 
> > Does this approach address the concerns raised, or suggest a different
> > direction? I'm particularly interested in feedback on runtime DTB
> > extraction to ESP is acceptable, or if there's a better way to bridge
> > between our combined-dtb format and U-Boot's expectations.
> > 
> > [1] https://docs.qualcomm.com/doc/80-70023-27/topic/
> > configure_and_secure_boot_with_systemd_boot_and_uki.html#multi-dtb-support
> > 
> > Thanks,
> > Aswin
> > 
> > On 1/6/2026 5:51 PM, Aswin Murugan wrote:
> >> This RFC patch series introduces a weak function hook to allow
> >> platforms to
> >> provide custom device tree selection logic while keeping common EFI
> >> loader code generic.
> >>
> >> Background:
> >> Currently, EFI loader supports loading a single DTB file.
> >> Qualcomm platforms require special multi-DTB selection logic that:
> >> - Reads hardware information from SMEM (Shared Memory)
> >> - Selects the appropriate device tree from a combined DTB file based on:
> >>    * Platform ID (SoC variant)
> >>    * Board variant and subtype
> >>    * PMIC configuration
> >>    * SoC revision.
> >>
> >> Solution:
> >> Introduce `efi_load_platform_fdt()` as a weak function:
> >> - Weak implementation in lib/efi_loader/efi_fdt.c (defaults to no-op)
> >> - Called from efi_bootmgr_run() after efi_load_distro_fdt()
> >> - Qualcomm override in arch/arm/mach-snapdragon/efi_fdt_qcom.c
> >>
> >> Aswin Murugan (3):
> >>    efi_loader: Add platform hook for FDT loading
> >>    soc: qcom: smem: Added socinfo header file
> >>    mach-snapdragon: Implement Qualcomm multi-DTB selection
> >>
> >>   arch/arm/mach-snapdragon/Makefile       |   1 +
> >>   arch/arm/mach-snapdragon/efi_fdt_qcom.c | 339 ++++++++++++++++++++++++
> >>   include/soc/qcom/socinfo.h              | 114 ++++++++
> >>   lib/efi_loader/efi_fdt.c                |  34 +++
> >>   4 files changed, 488 insertions(+)
> >>   create mode 100644 arch/arm/mach-snapdragon/efi_fdt_qcom.c
> >>   create mode 100644 include/soc/qcom/socinfo.h
> >>
> 
> -- 
> // Casey (she/her)
>