From: kavinaya@qti.qualcomm.com
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2] kernel-fitimage: add support for custom ITS file override
Date: Wed, 24 Sep 2025 02:46:03 -0700 [thread overview]
Message-ID: <29002.1758707163729683981@lists.openembedded.org> (raw)
In-Reply-To: <809c00d00ea6231c966cecd56a8dfca39f68a02c.camel@siemens.com>
On Tue, Sep 23, 2025 at 02:28 AM, Adrian Freihofer wrote:
>
> First, two simple findings from today's review meeting:
> * Squash Commits: Please consolidate the two patches into a single
> commit for better clarity and history.
> * Namespace Adherence: The new variable CUSTOM_ITS_FILE should align
> with our existing naming conventions. Please rename it to
> FIT_CUSTOM_ITS_FILE.
Sure. I will consolidate the two patches into a single patch and rename CUSTOM_ITS_FILE to FIT_CUSTOM_ITS_FILE.
>
> Now, I have a more fundamental question about the current
> implementation, which suggests we might need to explore a different
> approach for this functionality. My concern stems from how the
> do_compile() function handles the ITS file generation:
>
> do_compile () {
> root_node = 700 lines of Python code prepare the its data
> structure ready to be written into a file.
>
> # Then just ignore all this and use another (hard-coded?) its file
> 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)
>
> # Sign the FIT image if required
> root_node.run_mkimage_sign(fitimage)
> }
>
> As I understand it, the current logic (depending on FIT_* variable
> configurations) appears to execute a significant portion of the
> existing ITS data preparation code—potentially up to 700 lines—only to
> then overwrite the generated output with a custom, possibly hard-coded,
> ITS file. This pattern seems to bypass the intended use of the existing
> generation logic.
>
The existing logic is retained because it performs essential preparation steps beyond ITS generation, such as copying DTBs and other components into the FIT image assembly directory. These steps are required for successful image assembly even when a custom ITS file is used.
Thanks,
Kavinaya
next prev parent reply other threads:[~2025-09-24 9:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250919073335.2069114-1-kavinaya@qti.qualcomm.com>
2025-09-19 7:33 ` [PATCH 1/2] kernel-fitimage: add support for custom ITS file override Kavinaya S
2025-09-21 11:40 ` [OE-core] " Freihofer, Adrian
2025-09-22 8:41 ` kavinaya
2025-09-22 9:58 ` [OE-core] " Alexander Kanavin
[not found] ` <1867495AF42A64B8.23261@lists.openembedded.org>
2025-09-22 20:58 ` Freihofer, Adrian
2025-09-24 8:30 ` kavinaya
2025-09-24 9:46 ` kavinaya [this message]
2025-09-26 3:42 ` kavinaya
2025-09-26 7:31 ` [OE-core] " Alexander Kanavin
2025-09-29 14:26 ` kavinaya
2025-09-19 7:33 ` [PATCH 2/2] image-fitimage.conf: introduce CUSTOM_ITS_FILE variable Kavinaya S
2025-09-22 9:44 ` [OE-core] " Alexander Kanavin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29002.1758707163729683981@lists.openembedded.org \
--to=kavinaya@qti.qualcomm.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox