Re: [PATCH 1/2] kernel-fitimage: add support for custom ITS file override

[kavinaya@qti.qualcomm.com]

[-- Attachment #1: Type: text/plain, Size: 4007 bytes --]

On Sun, Sep 21, 2025 at 05:10 PM, Adrian Freihofer wrote:

> 
> Hi Kavinaya
> 
> Thank you for the patch. LGTM.
> 
> But, there is a but. While I acknowledge the concept of 'improved
> flexibility for advanced use cases,' it's vital to consider a common
> pitfall. Many existing BSPs have unfortunately led to user frustration.
> This is predominantly due to vendors integrating considerable amounts
> of downstream code that, despite intentions, often proves incompatible
> with future Yocto updates.
> 
> The direct consequence is that users face significant hurdles in
> updating their products, leading to either stagnation or high costs
> associated with fixing or circumventing these incompatibilities.
> 
> This problem not only impacts users directly but also casts a shadow on
> the Yocto Project, which can be perceived as culpable. In reality, such
> extensions often bypass upstream maintainers entirely, lacking the
> critical upstream test coverage necessary for long-term stability.
> 
> My recommendation, therefore, is to proactively prevent such
> frustration by officially supporting these 'advanced' use cases and
> ensuring they have dedicated test coverage. This approach is preferable
> to merely contributing API extensions that might enable all sorts of
> potentially unexpected and untested downstream implementations.
> 
> Kind regards,
> Adrian

Hi Adrian,

This change proposes an enhancement to the kernel-FIT image generation process within OpenEmbedded—specifically, the ability to optionally provide a manual.its file in place of the dynamically generated version from kernel-fit-image.bbclass.

This request is motivated by practical challenges encountered in supporting multiple SoC and board variants using a unified DTS file. The current dynamic generation mechanism does not accommodate the level of specificity required for our deployment scenarios. Below are the key reasons for this proposal:

*1. Variant-Specific Compatibility Strings*
Our DTS files support multiple board variants, but the compatible string format required by our UEFI implementation is more granular than what dynamic generation allows. The format we rely on is:
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<pmic>][-<board_version>]"
This structure enables precise identification of the appropriate DTB for each board variant, which is critical for correct boot behavior.

*2. Overlay DTBO Integration*
As demonstrated in the upstream kernel Makefile for QCOM platforms (link), overlays are used to generate composite DTBs:

qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vision-mezzanine.dtbo  
qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo

In both cases, the base DTB remains the same, but the overlays differ. Without manual.its file support, we cannot assign unique compatible strings to these variants, which limits UEFI’s ability to distinguish between them.

*3. Scalability and Maintainability*
As the number of supported variants grows, maintaining compatibility and configuration logic solely through dynamic generation becomes increasingly complex and error-prone. Manual.its files offer a scalable and maintainable alternative.

Therefore, we suggest introducing a conditional override mechanism in kernel-fit-image.bbclass that allows developers to supply a manual.its file when needed. This approach preserves existing behavior while enabling advanced use cases.

We understand the importance of maintaining upstream compatibility and minimizing user frustration. To that end, we propose this enhancement as an *opt-in mechanism* , with the intention of collaborating on upstream test coverage and documentation to ensure long-term stability. We believe this strikes a balance between flexibility for advanced use cases and the robustness expected from the Yocto Project.

Thanks,

Kavinaya

[-- Attachment #2: Type: text/html, Size: 13044 bytes --]