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

Update kernel-fitimage.bbclass to use CUSTOM_ITS_FILE when provided.
If the file exists, it will be used instead of generating an ITS file.
This improves flexibility for advanced use cases while maintaining
backward compatibility.

Signed-off-by: Kavinaya S <kavinaya@qti.qualcomm.com>
---
 meta/classes-recipe/kernel-fit-image.bbclass | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

On Fri, 2025-09-19 at 13:03 +0530, Kavinaya S via
lists.openembedded.org wrote:
> Update kernel-fitimage.bbclass to use CUSTOM_ITS_FILE when provided.
> If the file exists, it will be used instead of generating an ITS
> file.
> This improves flexibility for advanced use cases while maintaining
> backward compatibility.

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

> 
> Signed-off-by: Kavinaya S <kavinaya@qti.qualcomm.com>
> ---
>  meta/classes-recipe/kernel-fit-image.bbclass | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes-recipe/kernel-fit-image.bbclass
> b/meta/classes-recipe/kernel-fit-image.bbclass
> index f04aee1807..9258af938c 100644
> --- a/meta/classes-recipe/kernel-fit-image.bbclass
> +++ b/meta/classes-recipe/kernel-fit-image.bbclass
> @@ -139,8 +139,15 @@ python do_compile() {
>      # Generate the configuration section
>     
> root_node.fitimage_emit_section_config(d.getVar("FIT_CONF_DEFAULT_DTB
> "))
>  
> -    # Write the its file
> -    root_node.write_its_file(itsfile)
> +    # Resolve the full path to the custom ITS file if one is
> specified.
> +    # If CUSTOM_ITS_FILE is not set, the ITS file will be generated
> dynamically
> +    custom_its_file = d.getVar('CUSTOM_ITS_FILE')
> +    if custom_its_file:
> +        custom_its_file = os.path.join(kernel_deploydir,
> custom_its_file)
> +        bb.note(f"Using custom ITS file: {custom_its_file}")
> +        shutil.copyfile(custom_its_file, itsfile)
> +    else:
> +        root_node.write_its_file(itsfile)
>  
>      # Assemble the FIT image
>      root_node.run_mkimage_assemble(itsfile, fitname)
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#223768):
> https://lists.openembedded.org/g/openembedded-core/message/223768
> Mute This Topic: https://lists.openembedded.org/mt/115333710/3616858
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [
> adrian.freihofer@siemens.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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

On Mon, 22 Sept 2025 at 10:41, kavinaya via lists.openembedded.org
<kavinaya=qti.qualcomm.com@lists.openembedded.org> wrote:
> 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.
I have no idea about this .its stuff, but adding hooks for replacing
existing, not-quite-perfect solutions with proprietary magic is not
particularly welcome in open source projects. You should work towards
improving what already exists.

Alex