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

[Aswin Murugan]

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`
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
>