From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E967FCAC592 for ; Mon, 22 Sep 2025 08:41:27 +0000 (UTC) Subject: Re: [PATCH 1/2] kernel-fitimage: add support for custom ITS file override To: openembedded-core@lists.openembedded.org From: kavinaya@qti.qualcomm.com X-Originating-Location: Chennai, Tamil Nadu, IN (163.116.214.43) X-Originating-Platform: Windows Chrome 140 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 22 Sep 2025 01:41:23 -0700 References: In-Reply-To: Message-ID: <19647.1758530483327855783@lists.openembedded.org> Content-Type: multipart/alternative; boundary="sa9pfqG887tpA5iuW0S6" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Mon, 22 Sep 2025 08:41:27 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/223813 --sa9pfqG887tpA5iuW0S6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Sep 21, 2025 at 05:10 PM, Adrian Freihofer wrote: >=20 > Hi Kavinaya >=20 > Thank you for the patch. LGTM. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Kind regards, > Adrian Hi Adrian, This change proposes an enhancement to the kernel-FIT image generation proc= ess within OpenEmbedded=E2=80=94specifically, the ability to optionally pro= vide a manual.its file in place of the dynamically generated version from k= ernel-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 dyna= mic generation mechanism does not accommodate the level of specificity requ= ired for our deployment scenarios. Below are the key reasons for this propo= sal: *1. Variant-Specific Compatibility Strings* Our DTS files support multiple board variants, but the compatible string fo= rmat required by our UEFI implementation is more granular than what dynamic= generation allows. The format we rely on is: compatible =3D "qcom,[-][-]-[/][-][-]" This structure enables precise identification of the appropriate DTB for ea= ch 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 :=3D qcs6490-rb3gen2.dtb qcs6490-rb3g= en2-vision-mezzanine.dtbo =20 qcs6490-rb3gen2-industrial-mezzanine-dtbs :=3D qcs6490-rb3gen2.dtb qcs6490-= rb3gen2-industrial-mezzanine.dtbo In both cases, the base DTB remains the same, but the overlays differ. With= out manual.its file support, we cannot assign unique compatible strings to = these variants, which limits UEFI=E2=80=99s ability to distinguish between = them. *3. Scalability and Maintainability* As the number of supported variants grows, maintaining compatibility and co= nfiguration logic solely through dynamic generation becomes increasingly co= mplex and error-prone. Manual.its files offer a scalable and maintainable a= lternative. Therefore, we suggest introducing a conditional override mechanism in kerne= l-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 mini= mizing user frustration. To that end, we propose this enhancement as an *op= t-in mechanism* , with the intention of collaborating on upstream test cove= rage and documentation to ensure long-term stability. We believe this strik= es a balance between flexibility for advanced use cases and the robustness = expected from the Yocto Project. Thanks, Kavinaya --sa9pfqG887tpA5iuW0S6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
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
fl= exibility for advanced use cases,' it's vital to consider a common
pit= fall. Many existing BSPs have unfortunately led to user frustration.
T= his is predominantly due to vendors integrating considerable amounts
o= f 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 thes= e incompatibilities.

This problem not only impacts users directl= y but also casts a shadow on
the Yocto Project, which can be perceived= as culpable. In reality, such
extensions often bypass upstream mainta= iners entirely, lacking the
critical upstream test coverage necessary = for long-term stability.

My recommendation, therefore, is to pro= actively prevent such
frustration by officially supporting these 'adva= nced' use cases and
ensuring they have dedicated test coverage. This a= pproach is preferable
to merely contributing API extensions that might= enable all sorts of
potentially unexpected and untested downstream im= plementations.

Kind regards,
Adrian
Hi Adrian,
 

This change propose= s an enhancement to the kernel-FIT image generation process within OpenEmbe= dded—specifically, the ability to optionally provide a manual&n= bsp;.its file in plac= e of the dynamically generated version from kernel-fit-image.bbclass.

This request is mot= ivated by practical challenges encountered in supporting multiple SoC and b= oard variants using a unified DTS file. The current dynamic generation mech= anism does not accommodate the level of specificity required for our deploy= ment scenarios. Below are the key reasons for this proposal:

1. Variant-Specific Compatibility Strings
Ou= r DTS files support multiple board variants, but the compatible string form= at required by our UEFI implementation is more granular than what dynamic g= eneration allows. The format we rely on is:
comp= atible =3D "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 use= d to generate composite DTBs:

qcs6490-rb3gen2-vision-mezzanine-dtbs :=3D qcs6490-rb3gen2.dtb q=
cs6490-rb3gen2-vision-mezzanine.dtbo =20
qcs6490-rb3gen2-industrial-mezzanine-dtbs :=3D qcs6490-rb3gen2.dtb qcs6490-=
rb3gen2-industrial-mezzanine.dtbo

In both cases, the = base DTB remains the same, but the overlays differ. Without manual&nb= sp;.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 nu= mber of supported variants grows, maintaining compatibility and configurati= on logic solely through dynamic generation becomes increasingly complex and= error-prone. Manual .its files offer a scalable and maintainable alternative.

Therefore, we sugge= st introducing a conditional override mechanism in kernel-fit-image.bbclass that allo= ws developers to supply a manual .i= ts file when needed. This approach preserves exist= ing behavior while enabling advanced use cases.

We understand the i= mportance of maintaining upstream compatibility and minimizing user frustra= tion. To that end, we propose this enhancement as an opt-in mechanism, with the intenti= on of collaborating on upstream test coverage and documentation to ensure l= ong-term stability. We believe this strikes a balance between flexibility f= or advanced use cases and the robustness expected from the Yocto Project.&n= bsp;                     =                      = ;                     &nb= sp;                     &= nbsp;                    =                     &nbs= p;      

Thanks,

Kavinaya

--sa9pfqG887tpA5iuW0S6--