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

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

[Aswin Murugan]

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

-- 
2.34.1

[PATCH v1 1/3] efi_loader: Add platform hook for FDT loading

[Aswin Murugan]

Introduce a weak function efi_load_platform_fdt() to allow platforms
to provide custom device tree selection logic. This enables platforms
with special requirements (such as multi-DTB selection based on
hardware detection) to load fdt.

The default weak implementation does nothing, Platforms can provide
a strong implementation to load platform-specific device trees.

Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
---
 include/efi_loader.h         |  2 ++
 lib/efi_loader/efi_bootmgr.c |  4 ++++
 lib/efi_loader/efi_fdt.c     | 23 +++++++++++++++++++++++
 3 files changed, 29 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3e70ac07055..62c3df48f71 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -1303,4 +1303,6 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq);
 
 void efi_load_distro_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
 
+void efi_load_platform_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
+
 #endif /* _EFI_LOADER_H */
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index a687f4d8e85..ed06a65feb7 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -1332,6 +1332,10 @@ efi_status_t efi_bootmgr_run(void *fdt)
 			efi_load_distro_fdt(handle, &fdt_distro, &fdt_size);
 			fdt = fdt_distro;
 		}
+		if (!fdt) {
+			efi_load_platform_fdt(handle, &fdt_distro, &fdt_size);
+			fdt = fdt_distro;
+		}
 	}
 
 	/*
diff --git a/lib/efi_loader/efi_fdt.c b/lib/efi_loader/efi_fdt.c
index bfaa9cfc207..bfcfd933adf 100644
--- a/lib/efi_loader/efi_fdt.c
+++ b/lib/efi_loader/efi_fdt.c
@@ -78,6 +78,29 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq)
 	return 0;
 }
 
+/**
+ * efi_load_platform_fdt() - Platform-specific FDT loading hook (weak)
+ *
+ * @handle:	handle of loaded image
+ * @fdt:	on return device-tree, must be freed via efi_free_pages()
+ * @fdt_size:	buffer size
+ *
+ * This weak function allows platforms to provide custom DTB selection logic.
+ * The default implementation does nothing, allowing the standard distro boot
+ * path to handle FDT loading. Platforms can override this function to
+ * implement custom multi-DTB selection or other platform-specific logic.
+ *
+ * If this function successfully loads a DTB, it should set *fdt to point to
+ * the loaded DTB and return. If it cannot load a DTB, it should set *fdt to
+ * NULL, and the standard distro boot logic will be used as fallback.
+ */
+__weak void efi_load_platform_fdt(efi_handle_t handle, void **fdt,
+				  efi_uintn_t *fdt_size)
+{
+	/* Default: do nothing, let standard distro boot handle it */
+	*fdt = NULL;
+}
+
 /**
  * efi_load_distro_fdt() - load distro device-tree
  *
-- 
2.34.1

Re: [PATCH v1 1/3] efi_loader: Add platform hook for FDT loading

[Simon Glass]

Hi Aswin,

On Tue, 6 Jan 2026 at 05:22, Aswin Murugan
<aswin.murugan@oss.qualcomm.com> wrote:
>
> Introduce a weak function efi_load_platform_fdt() to allow platforms
> to provide custom device tree selection logic. This enables platforms
> with special requirements (such as multi-DTB selection based on
> hardware detection) to load fdt.
>
> The default weak implementation does nothing, Platforms can provide
> a strong implementation to load platform-specific device trees.
>
> Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
> ---
>  include/efi_loader.h         |  2 ++
>  lib/efi_loader/efi_bootmgr.c |  4 ++++
>  lib/efi_loader/efi_fdt.c     | 23 +++++++++++++++++++++++
>  3 files changed, 29 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 3e70ac07055..62c3df48f71 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -1303,4 +1303,6 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq);
>
>  void efi_load_distro_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
>
> +void efi_load_platform_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
> +
>  #endif /* _EFI_LOADER_H */
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a687f4d8e85..ed06a65feb7 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -1332,6 +1332,10 @@ efi_status_t efi_bootmgr_run(void *fdt)
>                         efi_load_distro_fdt(handle, &fdt_distro, &fdt_size);
>                         fdt = fdt_distro;
>                 }
> +               if (!fdt) {
> +                       efi_load_platform_fdt(handle, &fdt_distro, &fdt_size);
> +                       fdt = fdt_distro;
> +               }
>         }
>
>         /*
> diff --git a/lib/efi_loader/efi_fdt.c b/lib/efi_loader/efi_fdt.c
> index bfaa9cfc207..bfcfd933adf 100644
> --- a/lib/efi_loader/efi_fdt.c
> +++ b/lib/efi_loader/efi_fdt.c
> @@ -78,6 +78,29 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq)
>         return 0;
>  }
>
> +/**
> + * efi_load_platform_fdt() - Platform-specific FDT loading hook (weak)
> + *
> + * @handle:    handle of loaded image
> + * @fdt:       on return device-tree, must be freed via efi_free_pages()
> + * @fdt_size:  buffer size
> + *
> + * This weak function allows platforms to provide custom DTB selection logic.
> + * The default implementation does nothing, allowing the standard distro boot
> + * path to handle FDT loading. Platforms can override this function to
> + * implement custom multi-DTB selection or other platform-specific logic.
> + *
> + * If this function successfully loads a DTB, it should set *fdt to point to
> + * the loaded DTB and return. If it cannot load a DTB, it should set *fdt to
> + * NULL, and the standard distro boot logic will be used as fallback.
> + */
> +__weak void efi_load_platform_fdt(efi_handle_t handle, void **fdt,
> +                                 efi_uintn_t *fdt_size)
> +{
> +       /* Default: do nothing, let standard distro boot handle it */
> +       *fdt = NULL;
> +}
> +
>  /**
>   * efi_load_distro_fdt() - load distro device-tree
>   *
> --
> 2.34.1
>

This is working at the wrong level and a weak function is not a good
idea IMO. You should have a way to determine the compatible string,
not a particular dtb, so that we can use the normal FIT-based
compatibles-string matching to boot, as is done on Qualcomm-based
Chromebooks, for example.

This is the sort of thing that a sysinfo driver could provide.

Also, for this particular platform, are you using grub as well?

Regards,
Simon

Re: [PATCH v1 1/3] efi_loader: Add platform hook for FDT loading

[Ilias Apalodimas]

Hi Aswin,

On Tue, 6 Jan 2026 at 14:22, Aswin Murugan
<aswin.murugan@oss.qualcomm.com> wrote:
>
> Introduce a weak function efi_load_platform_fdt() to allow platforms
> to provide custom device tree selection logic. This enables platforms
> with special requirements (such as multi-DTB selection based on
> hardware detection) to load fdt.
>
> The default weak implementation does nothing, Platforms can provide
> a strong implementation to load platform-specific device trees.

We have multiple methods of loading an alternative DT. You can for
example define them as a boot option ion the eficonfig command.
How you elaborate more on the requirements your platforms have and why
the existing code isn't enough?

Thanks
/Ilias
>
> Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
> ---
>  include/efi_loader.h         |  2 ++
>  lib/efi_loader/efi_bootmgr.c |  4 ++++
>  lib/efi_loader/efi_fdt.c     | 23 +++++++++++++++++++++++
>  3 files changed, 29 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 3e70ac07055..62c3df48f71 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -1303,4 +1303,6 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq);
>
>  void efi_load_distro_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
>
> +void efi_load_platform_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
> +
>  #endif /* _EFI_LOADER_H */
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a687f4d8e85..ed06a65feb7 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -1332,6 +1332,10 @@ efi_status_t efi_bootmgr_run(void *fdt)
>                         efi_load_distro_fdt(handle, &fdt_distro, &fdt_size);
>                         fdt = fdt_distro;
>                 }
> +               if (!fdt) {
> +                       efi_load_platform_fdt(handle, &fdt_distro, &fdt_size);
> +                       fdt = fdt_distro;
> +               }
>         }
>
>         /*
> diff --git a/lib/efi_loader/efi_fdt.c b/lib/efi_loader/efi_fdt.c
> index bfaa9cfc207..bfcfd933adf 100644
> --- a/lib/efi_loader/efi_fdt.c
> +++ b/lib/efi_loader/efi_fdt.c
> @@ -78,6 +78,29 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq)
>         return 0;
>  }
>
> +/**
> + * efi_load_platform_fdt() - Platform-specific FDT loading hook (weak)
> + *
> + * @handle:    handle of loaded image
> + * @fdt:       on return device-tree, must be freed via efi_free_pages()
> + * @fdt_size:  buffer size
> + *
> + * This weak function allows platforms to provide custom DTB selection logic.
> + * The default implementation does nothing, allowing the standard distro boot
> + * path to handle FDT loading. Platforms can override this function to
> + * implement custom multi-DTB selection or other platform-specific logic.
> + *
> + * If this function successfully loads a DTB, it should set *fdt to point to
> + * the loaded DTB and return. If it cannot load a DTB, it should set *fdt to
> + * NULL, and the standard distro boot logic will be used as fallback.
> + */
> +__weak void efi_load_platform_fdt(efi_handle_t handle, void **fdt,
> +                                 efi_uintn_t *fdt_size)
> +{
> +       /* Default: do nothing, let standard distro boot handle it */
> +       *fdt = NULL;
> +}
> +
>  /**
>   * efi_load_distro_fdt() - load distro device-tree
>   *
> --
> 2.34.1
>

Re: [PATCH v1 1/3] efi_loader: Add platform hook for FDT loading

[Heinrich Schuchardt]

Am 6. Januar 2026 13:21:32 MEZ schrieb Aswin Murugan <aswin.murugan@oss.qualcomm.com>:
>Introduce a weak function efi_load_platform_fdt() to allow platforms
>to provide custom device tree selection logic. This enables platforms
>with special requirements (such as multi-DTB selection based on
>hardware detection) to load fdt.
>
>The default weak implementation does nothing, Platforms can provide
>a strong implementation to load platform-specific device trees.
>
>Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
>---
> include/efi_loader.h         |  2 ++
> lib/efi_loader/efi_bootmgr.c |  4 ++++
> lib/efi_loader/efi_fdt.c     | 23 +++++++++++++++++++++++
> 3 files changed, 29 insertions(+)
>
>diff --git a/include/efi_loader.h b/include/efi_loader.h
>index 3e70ac07055..62c3df48f71 100644
>--- a/include/efi_loader.h
>+++ b/include/efi_loader.h
>@@ -1303,4 +1303,6 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq);
> 
> void efi_load_distro_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
> 
>+void efi_load_platform_fdt(efi_handle_t handle, void **fdt, efi_uintn_t *fdt_size);
>+
> #endif /* _EFI_LOADER_H */
>diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
>index a687f4d8e85..ed06a65feb7 100644
>--- a/lib/efi_loader/efi_bootmgr.c
>+++ b/lib/efi_loader/efi_bootmgr.c
>@@ -1332,6 +1332,10 @@ efi_status_t efi_bootmgr_run(void *fdt)
> 			efi_load_distro_fdt(handle, &fdt_distro, &fdt_size);
> 			fdt = fdt_distro;
> 		}
>+		if (!fdt) {
>+			efi_load_platform_fdt(handle, &fdt_distro, &fdt_size);
>+			fdt = fdt_distro;
>+		}
> 	}
> 
> 	/*
>diff --git a/lib/efi_loader/efi_fdt.c b/lib/efi_loader/efi_fdt.c
>index bfaa9cfc207..bfcfd933adf 100644
>--- a/lib/efi_loader/efi_fdt.c
>+++ b/lib/efi_loader/efi_fdt.c
>@@ -78,6 +78,29 @@ int efi_get_distro_fdt_name(char *fname, int size, int seq)
> 	return 0;
> }
> 
>+/**
>+ * efi_load_platform_fdt() - Platform-specific FDT loading hook (weak)
>+ *
>+ * @handle:	handle of loaded image
>+ * @fdt:	on return device-tree, must be freed via efi_free_pages()
>+ * @fdt_size:	buffer size
>+ *
>+ * This weak function allows platforms to provide custom DTB selection logic.
>+ * The default implementation does nothing, allowing the standard distro boot
>+ * path to handle FDT loading. Platforms can override this function to
>+ * implement custom multi-DTB selection or other platform-specific logic.
>+ *
>+ * If this function successfully loads a DTB, it should set *fdt to point to
>+ * the loaded DTB and return. If it cannot load a DTB, it should set *fdt to
>+ * NULL, and the standard distro boot logic will be used as fallback.
>+ */
>+__weak void efi_load_platform_fdt(efi_handle_t handle, void **fdt,
>+				  efi_uintn_t *fdt_size)
>+{
>+	/* Default: do nothing, let standard distro boot handle it */
>+	*fdt = NULL;
>+}
>+
> /**
>  * efi_load_distro_fdt() - load distro device-tree
>  *

Have a look at starfive_visionfive2_defconfig  which supports several boards and chooses the right devicetree based on a value in an EEPROM in SPL. In main U-Boot it sets a board specific value in $fdtfile which allows loading a device-tree from directory dtb/ on the ESP to override the U-Boot device-tree. 

Best regards

Heinrich

[PATCH v1 2/3] soc: qcom: smem: Added socinfo header file

[Aswin Murugan]

From: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

Added socinfo header file from linux [1]. This header
defines SoC ID constants, version macros, and helper APIs for querying
SoC details such as ID, revision, and features at runtime. It enables
platform-specific initialization and feature gating based on SoC info.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/soc/qcom/socinfo.h?id=7dcc1dfaa3d1cd3aafed2beb7086ed34fdb22303

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
---
 include/soc/qcom/socinfo.h | 114 +++++++++++++++++++++++++++++++++++++
 1 file changed, 114 insertions(+)
 create mode 100644 include/soc/qcom/socinfo.h

diff --git a/include/soc/qcom/socinfo.h b/include/soc/qcom/socinfo.h
new file mode 100644
index 00000000000..1bb6e200e1f
--- /dev/null
+++ b/include/soc/qcom/socinfo.h
@@ -0,0 +1,114 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef __QCOM_SOCINFO_H__
+#define __QCOM_SOCINFO_H__
+
+#include <linux/types.h>
+
+/*
+ * SMEM item id, used to acquire handles to respective
+ * SMEM region.
+ */
+#define SMEM_HW_SW_BUILD_ID		137
+
+#define SMEM_SOCINFO_BUILD_ID_LENGTH	32
+#define SMEM_SOCINFO_CHIP_ID_LENGTH	32
+
+/*
+ * SoC version type with major number in the upper 16 bits and minor
+ * number in the lower 16 bits.
+ */
+#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0xffff)
+#define SOCINFO_MINOR(ver) ((ver) & 0xffff)
+#define SOCINFO_VERSION(maj, min)  ((((maj) & 0xffff) << 16) | ((min) & 0xffff))
+
+/* Socinfo SMEM item structure */
+struct socinfo {
+	__le32 fmt;
+	__le32 id;
+	__le32 ver;
+	char build_id[SMEM_SOCINFO_BUILD_ID_LENGTH];
+	/* Version 2 */
+	__le32 raw_id;
+	__le32 raw_ver;
+	/* Version 3 */
+	__le32 hw_plat;
+	/* Version 4 */
+	__le32 plat_ver;
+	/* Version 5 */
+	__le32 accessory_chip;
+	/* Version 6 */
+	__le32 hw_plat_subtype;
+	/* Version 7 */
+	__le32 pmic_model;
+	__le32 pmic_die_rev;
+	/* Version 8 */
+	__le32 pmic_model_1;
+	__le32 pmic_die_rev_1;
+	__le32 pmic_model_2;
+	__le32 pmic_die_rev_2;
+	/* Version 9 */
+	__le32 foundry_id;
+	/* Version 10 */
+	__le32 serial_num;
+	/* Version 11 */
+	__le32 num_pmics;
+	__le32 pmic_array_offset;
+	/* Version 12 */
+	__le32 chip_family;
+	__le32 raw_device_family;
+	__le32 raw_device_num;
+	/* Version 13 */
+	__le32 nproduct_id;
+	char chip_id[SMEM_SOCINFO_CHIP_ID_LENGTH];
+	/* Version 14 */
+	__le32 num_clusters;
+	__le32 ncluster_array_offset;
+	__le32 num_subset_parts;
+	__le32 nsubset_parts_array_offset;
+	/* Version 15 */
+	__le32 nmodem_supported;
+	/* Version 16 */
+	__le32  feature_code;
+	__le32  pcode;
+	__le32  npartnamemap_offset;
+	__le32  nnum_partname_mapping;
+	/* Version 17 */
+	__le32 oem_variant;
+	/* Version 18 */
+	__le32 num_kvps;
+	__le32 kvps_offset;
+	/* Version 19 */
+	__le32 num_func_clusters;
+	__le32 boot_cluster;
+	__le32 boot_core;
+};
+
+/* Internal feature codes */
+enum qcom_socinfo_feature_code {
+	/* External feature codes */
+	SOCINFO_FC_UNKNOWN = 0x0,
+	SOCINFO_FC_AA,
+	SOCINFO_FC_AB,
+	SOCINFO_FC_AC,
+	SOCINFO_FC_AD,
+	SOCINFO_FC_AE,
+	SOCINFO_FC_AF,
+	SOCINFO_FC_AG,
+	SOCINFO_FC_AH,
+};
+
+/* Internal feature codes */
+/* Valid values: 0 <= n <= 0xf */
+#define SOCINFO_FC_Yn(n)		(0xf1 + (n))
+#define SOCINFO_FC_INT_MAX		SOCINFO_FC_Yn(0xf)
+
+/* Product codes */
+#define SOCINFO_PC_UNKNOWN		0
+#define SOCINFO_PCn(n)			((n) + 1)
+#define SOCINFO_PC_RESERVE		(BIT(31) - 1)
+
+#endif
-- 
2.34.1

[PATCH v1 3/3] mach-snapdragon: Implement Qualcomm multi-DTB selection

[Aswin Murugan]

From: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

Add Qualcomm-specific implementation of multi-DTB selection by
overriding the weak efi_load_platform_fdt() function. This enables
automatic device tree selection based on SoC information read from
SMEM (Shared Memory).

The implementation:
- Reads combined-dtb.dtb from the boot partition
- Parses qcom,msm-id, qcom,board-id, and qcom,pmic-id properties
- Matches against runtime SoC info (platform ID, board variant, PMIC)
- Selects the appropriate DTB for the current hardware configuration

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
---
 arch/arm/mach-snapdragon/Makefile       |   1 +
 arch/arm/mach-snapdragon/efi_fdt_qcom.c | 337 ++++++++++++++++++++++++
 2 files changed, 338 insertions(+)
 create mode 100644 arch/arm/mach-snapdragon/efi_fdt_qcom.c

diff --git a/arch/arm/mach-snapdragon/Makefile b/arch/arm/mach-snapdragon/Makefile
index 343e825c6fd..70f36c8ec19 100644
--- a/arch/arm/mach-snapdragon/Makefile
+++ b/arch/arm/mach-snapdragon/Makefile
@@ -5,3 +5,4 @@
 obj-y += board.o
 obj-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += capsule_update.o
 obj-$(CONFIG_OF_LIVE) += of_fixup.o
+obj-$(CONFIG_EFI_LOADER) += efi_fdt_qcom.o
diff --git a/arch/arm/mach-snapdragon/efi_fdt_qcom.c b/arch/arm/mach-snapdragon/efi_fdt_qcom.c
new file mode 100644
index 00000000000..f465fea71d8
--- /dev/null
+++ b/arch/arm/mach-snapdragon/efi_fdt_qcom.c
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm multi-DTB selection for EFI boot
+ *
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc.
+ */
+
+#define LOG_CATEGORY LOGC_EFI
+
+#include <efi_device_path.h>
+#include <efi_loader.h>
+#include <log.h>
+#include <string.h>
+#include <fdt_support.h>
+#include <smem.h>
+#include <dm.h>
+#include <soc/qcom/socinfo.h>
+
+struct qcom_board_id {
+	u32 variant;
+	u32 sub_type;
+};
+
+struct qcom_pmic_id {
+	u32 pmic_ver[4];
+};
+
+struct qcom_plat_id {
+	u32 plat_id;
+	u32 soc_rev;
+};
+
+struct qcom_smem_pmic_info {
+	u32 model;
+	u32 version;
+};
+
+struct qcom_dt_entry {
+	u32 plat_id;
+	u32 variant;
+	u32 sub_type;
+	u32 soc_rev;
+	u32 pmic_ver[4];
+	void *fdt;
+	u32 size;
+	u32 idx;
+};
+
+struct qcom_dt_entry qcom_dt_entries[64];
+
+#define PLAT_ID_SIZE    sizeof(struct qcom_plat_id)
+#define BOARD_ID_SIZE   sizeof(struct qcom_board_id)
+#define PMIC_ID_SIZE    sizeof(struct qcom_pmic_id)
+#define DEV_TREE_VERSION_V1 1
+#define DEV_TREE_VERSION_V2 2
+#define DEV_TREE_VERSION_V3 3
+#define DT_ENTRY_V1_SIZE 0xC
+#define PMIC_EXT_VERSION 0x0000000000010003
+
+#define fdt_board_variant(_b, _i)	\
+	(fdt32_to_cpu(((struct qcom_board_id *)_b)[_i].variant) & 0xff)
+#define fdt_board_sub_type(_b, _i)	\
+	(fdt32_to_cpu(((struct qcom_board_id *)_b)[_i].sub_type) & 0xff)
+#define fdt_plat_plat_id(_b, _i)	\
+	(fdt32_to_cpu(((struct qcom_plat_id *)_b)[_i].plat_id) & 0xffff)
+#define fdt_plat_soc_rev(_b, _i)	\
+	fdt32_to_cpu(((struct qcom_plat_id *)_b)[_i].soc_rev)
+#define fdt_pmic_pmic_ver(_b, _i, _x)	\
+	fdt32_to_cpu(((struct qcom_pmic_id *)_b)[_i].pmic_ver[_x])
+
+static int qcom_parse_one_dtb(void *fdt, struct socinfo *socinfo, void **match)
+{
+	const char *model, *pmic, *board, *plat;
+	int pmiclen, boardlen, platlen, minplatlen;
+	struct qcom_smem_pmic_info *smem_pmic_info;
+	int dtbver, i, j, k;
+
+	*match = NULL;
+
+	model = fdt_getprop(fdt, 0, "model", NULL);
+	pmic = fdt_getprop(fdt, 0, "qcom,pmic-id", &pmiclen);
+	board = fdt_getprop(fdt, 0, "qcom,board-id", &boardlen);
+	plat = fdt_getprop(fdt, 0, "qcom,msm-id", &platlen);
+
+	if (pmic && pmiclen > 0 && board && boardlen > 0) {
+		if ((pmiclen % PMIC_ID_SIZE) || (boardlen % BOARD_ID_SIZE)) {
+			log_err("qcom,pmic-id (%d) or qcom,board-id (%d) not a multiple of (%lu, %lu)\n",
+				pmiclen, boardlen, PMIC_ID_SIZE, BOARD_ID_SIZE);
+			return -1;
+		}
+		dtbver = DEV_TREE_VERSION_V3;
+		minplatlen = PLAT_ID_SIZE;
+	} else if (board && boardlen > 0) {
+		if (boardlen % BOARD_ID_SIZE) {
+			log_err("qcom,board-id (%d) not a multiple of %lu\n",
+				boardlen, BOARD_ID_SIZE);
+			return -1;
+		}
+		dtbver = DEV_TREE_VERSION_V2;
+		minplatlen = PLAT_ID_SIZE;
+	} else {
+		dtbver = DEV_TREE_VERSION_V1;
+		minplatlen = DT_ENTRY_V1_SIZE;
+	}
+
+	if (!plat || platlen < 0) {
+		log_err("qcom,msm-id not found\n");
+		return -1;
+	} else if (platlen % minplatlen) {
+		log_err("qcom,msm-id (%d) not a multiple of %d\n",
+			platlen, minplatlen);
+		return -1;
+	}
+
+	smem_pmic_info = ((void *)socinfo) + socinfo->pmic_array_offset;
+
+	for (i = 0; i < (boardlen / BOARD_ID_SIZE); i++)
+		for (j = 0; j < (platlen / PLAT_ID_SIZE); j++)
+			if (pmic) {
+				for (k = 0; k < (pmiclen / PMIC_ID_SIZE); k++) {
+					if ((socinfo->id & 0x0000ffff) ==
+					    fdt_plat_plat_id(plat, j) &&
+					    socinfo->hw_plat ==
+					    fdt_board_variant(board, i) &&
+					    socinfo->hw_plat_subtype ==
+					    fdt_board_sub_type(board, i) &&
+					    socinfo->plat_ver ==
+					    fdt_plat_soc_rev(plat, j) &&
+					    smem_pmic_info[0].model ==
+					    fdt_pmic_pmic_ver(pmic, k, 0) &&
+					    smem_pmic_info[1].model ==
+					    fdt_pmic_pmic_ver(pmic, k, 1) &&
+					    smem_pmic_info[2].model ==
+					    fdt_pmic_pmic_ver(pmic, k, 2) &&
+					    smem_pmic_info[3].model ==
+					    fdt_pmic_pmic_ver(pmic, k, 3)) {
+						*match = fdt;
+						log_info("%8x| %8x| %8x| %4d.%03d| %8x| %8x| %8x| %8x| %s\n",
+							 fdt_board_variant(board, i),
+							 fdt_board_sub_type(board, i),
+							 fdt_plat_plat_id(plat, j),
+							 SOCINFO_MAJOR(fdt_plat_soc_rev(plat, j)),
+							 SOCINFO_MINOR(fdt_plat_soc_rev(plat, j)),
+							 fdt_pmic_pmic_ver(pmic, k, 0),
+							 fdt_pmic_pmic_ver(pmic, k, 1),
+							 fdt_pmic_pmic_ver(pmic, k, 2),
+							 fdt_pmic_pmic_ver(pmic, k, 3), model);
+						return 0;
+					}
+				}
+			} else {
+				if ((socinfo->id & 0x0000ffff) ==
+				    fdt_plat_plat_id(plat, j) &&
+				    socinfo->hw_plat ==
+				    fdt_board_variant(board, i) &&
+				    socinfo->hw_plat_subtype ==
+				    fdt_board_sub_type(board, i) &&
+				    socinfo->plat_ver ==
+				    fdt_plat_soc_rev(plat, j)) {
+					*match = fdt;
+					log_info("%8x| %8x| %8x| %4d.%03d| %8s| %8s| %8s| %8s| %s\n",
+						 fdt_board_variant(board, i),
+						 fdt_board_sub_type(board, i),
+						 fdt_plat_plat_id(plat, j),
+						 SOCINFO_MAJOR(fdt_plat_soc_rev(plat, j)),
+						 SOCINFO_MINOR(fdt_plat_soc_rev(plat, j)),
+						 "--", "--", "--", "--", model);
+					return 0;
+				}
+			}
+
+	return 0;
+}
+
+static struct fdt_header *qcom_parse_combined_dtb(struct fdt_header *fdt)
+{
+	int fdt_count = 0;
+	struct udevice *dev;
+	size_t size;
+	struct socinfo *socinfo;
+	void *match;
+	struct fdt_header *fdt_blob = fdt;
+
+	if (!fdt_valid(&fdt)) {
+		log_err("%s: fdt not valid!\n", __func__);
+		return NULL;
+	}
+
+	uclass_get_device(UCLASS_SMEM, 0, &dev);
+
+	socinfo = smem_get(dev, 0, SMEM_HW_SW_BUILD_ID, &size);
+	log_debug("%s: socinfo: %p\n", __func__, socinfo);
+
+	log_info("%-8s| %-8s| %-8s| %-8s| %-8s| %-8s| %-8s| %-8s| %s\n"
+		 "--------+---------+---------+---------+---------+---------+---------+---------+------\n",
+		 "Variant", "Sub Type", "Plat Id", "SoC Rev.",
+		 "pmic[0]", "pmic[1]", "pmic[2]", "pmic[3]", "Model");
+
+	while (fdt_valid(&fdt)) {
+		qcom_parse_one_dtb(fdt, socinfo, &match);
+
+		if (match)
+			return match;
+
+		fdt = ((void *)fdt) + fdt_totalsize(fdt);
+		fdt_count++;
+	}
+
+	if (fdt_count == 1)
+		return fdt_blob;
+
+	return NULL;
+}
+
+static void efi_load_qcom_fdt(efi_handle_t handle, void **_fdt,
+			      efi_uintn_t *_fdt_size)
+{
+	u32 i;
+	efi_uintn_t count;
+	u64 fdt_addr, tmp_addr;
+	efi_status_t ret;
+	u16 *fdt_name = u"/combined-dtb.dtb";
+	struct efi_handler *handler;
+	efi_handle_t *volume_handles = NULL;
+	struct efi_simple_file_system_protocol *v;
+	struct efi_file_handle *f = NULL;
+	void *match;
+
+	*_fdt = NULL;
+	*_fdt_size = 0;
+
+	ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
+					   &efi_simple_file_system_protocol_guid,
+					   NULL, &count,
+					   (efi_handle_t **)&volume_handles);
+	if (ret != EFI_SUCCESS) {
+		log_err("%s: No block device found! (0x%lx)\n", __func__, ret);
+		return;
+	}
+
+	log_info("Using device tree: %ls\n", fdt_name);
+
+	/* Try to find combined-dtb.dtb on available volumes */
+	for (i = 0; i < count; i++) {
+		struct efi_file_handle *root;
+
+		ret = efi_search_protocol(volume_handles[i],
+					  &efi_simple_file_system_protocol_guid,
+					  &handler);
+		if (ret != EFI_SUCCESS)
+			continue;
+		ret = efi_protocol_open(handler, (void **)&v, efi_root, NULL,
+					EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+		if (ret != EFI_SUCCESS)
+			continue;
+
+		ret = EFI_CALL(v->open_volume(v, &root));
+		if (ret != EFI_SUCCESS)
+			goto out;
+
+		ret = EFI_CALL(root->open(root, &f, fdt_name,
+					  EFI_FILE_MODE_READ, 0));
+		if (ret != EFI_SUCCESS) {
+			log_warning("%s: Reading volume failed! (0x%lx)\n",
+				    __func__, ret);
+			continue;
+		} else {
+			log_debug("%s: %ls found!\n", __func__, fdt_name);
+			break;
+		}
+	}
+
+	if (!f)
+		goto out;
+
+	ret = efi_file_size(f, &count);
+	if (ret != EFI_SUCCESS)
+		goto out;
+
+	ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+				 EFI_BOOT_SERVICES_DATA,
+				 efi_size_in_pages(count), &fdt_addr);
+	if (ret != EFI_SUCCESS) {
+		log_err("%s: Out of memory! (0x%lx bytes) (0x%lx)\n",
+			__func__, count, ret);
+		goto out;
+	}
+	ret = EFI_CALL(f->read(f, &count, (void *)(uintptr_t)fdt_addr));
+	if (ret != EFI_SUCCESS) {
+		log_err("%s: Can't read fdt! (0x%lx)\n", __func__, ret);
+		goto out;
+	}
+
+	match = qcom_parse_combined_dtb((void *)(uintptr_t)fdt_addr);
+	if (match) {
+		*_fdt_size = fdt_totalsize(match);
+
+		ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+					 EFI_BOOT_SERVICES_DATA,
+					 efi_size_in_pages(*_fdt_size), &tmp_addr);
+		if (ret != EFI_SUCCESS) {
+			log_err("%s: Out of memory! (0x%lx bytes) (0x%lx)\n",
+				__func__, *_fdt_size, ret);
+			goto out;
+		}
+		/*
+		 * The memory allocated for reading the fdt is eventually freed
+		 * by the caller using the address we return. Hence copy it out
+		 */
+		memcpy((void *)(uintptr_t)tmp_addr, match, *_fdt_size);
+		*_fdt = (void *)(uintptr_t)tmp_addr;
+
+		log_debug("%s: fdt@0x%p %lu\n", __func__, *_fdt, *_fdt_size);
+	} else {
+		log_warning("%s: No FDT matched!!\n", __func__);
+	}
+out:
+	efi_free_pages(fdt_addr, efi_size_in_pages(count));
+
+	efi_free_pool(volume_handles);
+}
+
+/**
+ * efi_load_platform_fdt() - Platform-specific FDT loading (Qualcomm override)
+ *
+ * @handle:	handle of loaded image
+ * @fdt:	on return device-tree, must be freed via efi_free_pages()
+ * @fdt_size:	buffer size
+ *
+ * This function overrides the weak function in lib/efi_loader/efi_fdt.c
+ * to provide Qualcomm-specific multi-DTB selection based on SoC info.
+ */
+void efi_load_platform_fdt(efi_handle_t handle, void **fdt,
+			   efi_uintn_t *fdt_size)
+{
+	efi_load_qcom_fdt(handle, fdt, fdt_size);
+}
-- 
2.34.1

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

[Sumit Garg]

Hi Ashwin,

On Tue, Jan 06, 2026 at 05:51:31PM +0530, 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.

As pointed to by folks in the other thread, U-Boot allows to select a
DTB from all the DTBs bundled by the OS in EFI system partition. You can
see the Debian example here for DTBs packaging [1].

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

I think here you are presenting an incomplete picture to the U-Boot
community. You need to show firstly how the multi-DTB FIT image is
prepared first which is described here [2].

From U-Boot point of view, I think this DTB selection logic is useful
which can be used to configure: $fdtfile, see API: configure_env() in
arch/arm/mach-snapdragon/board.c.

However, does this solution also cover OEMs based boards alongside Qcom
reference boards?

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

[1] https://packages.debian.org/sid/u-boot-efi-dtb
[2] https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md

-Sumit

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

Re: [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
>

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

[Heinrich Schuchardt]

Am 10. Januar 2026 09:30:03 MEZ schrieb Aswin Murugan <aswin.murugan@oss.qualcomm.com>:
>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
>> 

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

[Casey Connolly]

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.

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)

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

[Sumit Garg]

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

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

[Sumit Garg]

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