Am 10. Januar 2026 09:30:03 MEZ schrieb Aswin Murugan <[email protected]>: >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`
"Write to ESP" would imply at build time? Do combined dtbs exist in Linux? Why use them here? How are dtbs handled in earlier code like TFA? Could that earlier code pass the specific dtb for the board? Best regards Heinrich >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 >>
