All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@kernel.org>
To: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
Cc: trini@konsulko.com, casey.connolly@linaro.org,
	neil.armstrong@linaro.org, xypron.glpk@gmx.de,
	ilias.apalodimas@linaro.org,
	varadarajan.narayanan@oss.qualcomm.com, adrianox@gmail.com,
	paul.liu@linaro.org, sjg@chromium.org,
	wolfgang.wallner@at.abb.com, javier.tia@linaro.org,
	u-boot-qcom@groups.io, u-boot@lists.denx.de
Subject: Re: [RFC PATCH v1 0/3] efi_loader: Introduce platform hook for FDT selection
Date: Thu, 15 Jan 2026 12:20:10 +0530	[thread overview]
Message-ID: <aWiOIjLre9Ry70Jx@sumit-xelite> (raw)
In-Reply-To: <597c246c-113c-4b88-93bb-22ec5b525b55@oss.qualcomm.com>

On Sat, Jan 10, 2026 at 02:00:03PM +0530, 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)

As discussed in the thread here [1], combined DTB is a legacy format
which is superceeded by the FIT based [2]. So rather work on FIT based
DTB packaging. Along with that extend mkimage tooling support in order
to build that FIT based multi DTB image.

[1] https://github.com/qualcomm-linux/meta-qcom/pull/1373#discussion_r2684555441
[2] https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md

-Sumit

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

      parent reply	other threads:[~2026-01-15  6:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-06 12:21 [RFC PATCH v1 0/3] efi_loader: Introduce platform hook for FDT selection Aswin Murugan
2026-01-06 12:21 ` [PATCH v1 1/3] efi_loader: Add platform hook for FDT loading Aswin Murugan
2026-01-06 16:22   ` Simon Glass
2026-01-07 15:00   ` Ilias Apalodimas
2026-01-07 18:44   ` Heinrich Schuchardt
2026-01-06 12:21 ` [PATCH v1 2/3] soc: qcom: smem: Added socinfo header file Aswin Murugan
2026-01-06 12:21 ` [PATCH v1 3/3] mach-snapdragon: Implement Qualcomm multi-DTB selection Aswin Murugan
2026-01-08 12:10 ` [RFC PATCH v1 0/3] efi_loader: Introduce platform hook for FDT selection Sumit Garg
2026-01-10  8:30 ` Aswin Murugan
2026-01-12  8:10   ` Heinrich Schuchardt
2026-01-12 13:48   ` Casey Connolly
2026-01-15  6:51     ` Sumit Garg
2026-01-15  6:50   ` Sumit Garg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aWiOIjLre9Ry70Jx@sumit-xelite \
    --to=sumit.garg@kernel.org \
    --cc=adrianox@gmail.com \
    --cc=aswin.murugan@oss.qualcomm.com \
    --cc=casey.connolly@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=javier.tia@linaro.org \
    --cc=neil.armstrong@linaro.org \
    --cc=paul.liu@linaro.org \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot-qcom@groups.io \
    --cc=u-boot@lists.denx.de \
    --cc=varadarajan.narayanan@oss.qualcomm.com \
    --cc=wolfgang.wallner@at.abb.com \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.