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
