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