On Fri, Oct 16, 2026 at 05:45:56PM +0530, Sumit Garg wrote: > Hi Tom, > > On Tue, 13 Oct 2026 at 09:03:07 -0600, Tom Rini wrote: > > On Tue, Oct 13, 2026 at 12:50:42PM +0530, Aswin Murugan wrote: > > > > > > On 10/12/2026 11:20 PM, Tom Rini wrote: > > > Hi Tom, > > > > On Mon, Oct 12, 2026 at 10:37:49PM +0530, Aswin Murugan wrote: > > > > > This series adds dynamic device tree selection from FIT images for > > > > > Qualcomm Snapdragon platforms, enabling U-Boot to select the > > > > > appropriate DTB based on hardware parameters detected at boot. > > > > > > > > > > Qualcomm FIT-based DTB format is documented in [1]. > > > > > > > > > > The FIT image contains only DTBs, while the kernel is provided > > > > > separately as part of a UKI image. > > > > > > > > > > The implementation consists of: > > > > > > > > > > 1. Hardware detection infrastructure: Introduces the qcom,hwinfo > > > > > driver and qcom_hwdetect helper to collect hardware identification > > > > > data from SMEM, IMEM and TCSR into a single qcom_hw_params > > > > > structure for consumers such as FIT multi-DTB selection. > > > > > > > > > > 2. FIT multi-DTB selection: Implements DTB selection based on the > > > > > aggregated hardware information. The code parses metadata DTBs, > > > > > matches FIT configurations against detected hardware attributes, > > > > > applies overlays, and loads the selected DTB for EFI boot. > > > > > > > > > > [1] https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/ > > > > > Documentation.md > > > > > > > > > > --- > > > > > > > > > > Changes in v4: > > > > ... which was sent as v5, and this is a re-send of? > > > Yes, this is a resend of v4, which was sent as v5 > > > > > 1. Drop the SMEM cache infrastructure. > > > > > > > > > > 2. misc: qcom: add qcom,hwinfo driver to provide a common interface > > > > > for reading IMEM boot cookie and TCSR SOC version information. > > > > > > > > > > 3. arm: snapdragon: add qcom_hwdetect helper to aggregate hardware > > > > > information from SMEM, IMEM and TCSR into a single > > > > > struct qcom_hw_params. > > > > > > > > > > 4. Refactor FIT multi-DTB selection to consume qcom_hw_params instead > > > > > of accessing SMEM, IMEM and TCSR data directly. > > > > > > > > > > 5. Separate hardware discovery from FIT parsing and DTB matching > > > > > logic, reducing complexity and improving code organization. > > > > > > > > > > 6. Load FIT images directly from a raw GPT partition and remove the > > > > > FAT filesystem image based loading approach. > > > > > > > > > > 7. Drop IH_TYPE_FATFS, mkimage FAT image generation support and > > > > > related documentation updates. > > > > > > > > > > 8. arm: dts: enable qcom,hwinfo on qcs9100-ride-r3, qcs615-ride and > > > > > qcs6490-rb3gen2 by adding the required qcom,hwinfo DT nodes and > > > > > board-specific offsets. > > > > > > > > > > Link to v3: > > > > > https://lore.kernel.org/u-boot/[email protected]/ > > > > The FAT comments in v3 were addressed. I'm not really sure the > > > > discussion about if > > > > this approach makes sense as really was addressed however? > > > > > > Yes, the FAT-related comments from v3 were addressed in this > > > revision by dropping the FAT filesystem image-based loading > > > approach and loading FIT image directly from a raw GPT > > > partition. > > > > Right, thanks. > > > > > Regarding the broader design, the reasoning for using a > > > DTB-only FIT was discussed in the v3 thread [1]. The intention > > > is to support firmware-side DT selection while keeping DTB > > > management independent of kernel packaging, matching existing > > > Qualcomm deployment models. This is intended to coexist with, > > > rather than replace, approaches such as UKI DT bundling. > > > > > > [1]: https://lore.kernel.org/u-boot/afSXa7q7hJC_ZW07@sumit-xelite/ > > > > Yes, and I'd appreciate some of the people that were discussing things > > in that thread chiming in and saying they're happy enough, as it wasn't > > clear to me in re-reading the thread yesterday that the discussion ended > > with agreement and instead just stopped. > > > > As of now the Qualcomm subsystem maintenence is in really inactive state > as you can see from the list of patchsets even carrying review tags are > missing custodian attention here [1]. If you remember it from our earlier > private thread with Casey and Neil many months ago, the maintainence > situation hasn't improved at all. > > Even as a reviewer for the Qcom subsystem, I have tried earlier with all > the reviews but patches were still floating on the list, which just > demotivated me from doing further reviews. > > I would really like to get this maintainence situation fixed. Would it > be fine with you to accept me as a Qcom subsystem custodian with more > people from Qualcomm contributing as reviewers? > > In the meantime why we decide on that, can you help with picking patches > which have been reviewed directly for the Qualcomm subsystem? > > [1] > https://patchwork.ozlabs.org/project/uboot/list/?delegate=151538¶m=4&page=1
I don't have a problem with (and a number of our SoCs do this now) have co-custodians, so I've reached out to Casey. Since you brought it up in this thread, you were in the original v3 with questions / concerns about the approach that I wasn't sure if were resolved. -- Tom
signature.asc
Description: PGP signature
