Re: [PATCH v6 4/4] meta: Deploy DTBs once per kernel

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 18.02.26 17:21, Baurzhan Ismagulov wrote:
> On 2026-02-16 18:51, 'Jan Kiszka' via isar-users wrote:
>>> Our use case is:
>>> 1. Two images, same dtb name, same dtb contents.
>>
>> Which is just the tip of this issue. Other layers deploy bootloader
>> files or firmware binaries under the same name, overwriting things right
>> now if two images are built under different names. And that overwriting
>> sometimes triggers the infamous bitbake deployment errors.
> 
> Thanks for the detailed elaboration. If the contents are the same, v6 patch 4
> would handle it. The "same name, different contents" case we couldn't identify
> from the past threads and the downstreams we see, so we had left it for later
> when it would actually occur (often the real cases are different from what one
> anticipates).
> 
> If "same name, different contents" is already the case today, duplicating is
> the only option.
> 
> I'm a bit surprised that the errors occur only sometimes -- we can reproduce
> them reliably given the right mix of build targets.
> 

The massive scale of multiconfig targets that isar has is not
representative. I know the error primarily from reconfigured rebuilds.

> 
>>> 2. Downstream already has many deliverables.
>>>
>>> My underlying question: Should we always duplicate, or should we at least try
>>> to identify cases where we can avoid duplication? "Same file -- single
>>> deployment".
>>
>> How would you switch between de-duplicated and different artifacts by
>> name then? How would imagers or other users find deployed artifacts in
>> both cases?
> 
> Yes, that would depend on the contents and might be counter-intuitive at times.
> Maybe duplicating and having the complete sets for every machine would be the
> easiest to understand for the end users. We need to see how it works in
> practice.
> 
> 
>>> Patch 4 "deploy dtb once per kernel" associates the dtb with the recipe
>>> producing it, reducing shuffling around in the image recipe. Yes, the kernel is
>>> still deployed in the image which is inconsistent at this step; I'd be fine
>>> doing that later.
>>>
>>> We'll try playing with splitting by image. Even if we end up doing it at this
>>> time, I'd still propose to explore the other options step by step.
>>
>> Please not so many user-visible changes "step by step". We need a design
>> that holds now, and we need one step to get there, at least when that
>> step implies path changes that downstream layers need to adjust to.
> 
> I agree -- this was the goal of v6 patch 4 -- it doesn't change the path if it
> is not necessary, and a similar kernel consolidation also wouldn't change the
> path.

Having inconsistent paths would be highly counterintuitive. Better have
stable ones and live with duplications. We may already duplicate kernels
and initramfs images, and both are much larger some normal DTBs.

> 
> 
>> I guess we should rather introduce the pattern of creating a subfolder
>> ${IMAGE_FULLNAME} and put all those potentially colliding artifacts there.
> 
> We'll send v7 with duplication.
> 
> 
> Currently, some artifacts are duplicated via file names. Since we already break
> the API, we could touch them as well. Opinions welcome.
> 
> 1. Before the change:
> 
>    mc:phyboard-mira-bookworm:isar-image-base
> 
>    phyboard-mira/imx6q-phytec-mira-rdk-nand.dtb                                  # bitbake conflict
>    phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira-initrd.img
>    phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira-vmlinuz
> 
>    mc:phyboard-mira-bookworm:isar-image-ci
> 
>    phyboard-mira/imx6q-phytec-mira-rdk-nand.dtb                                  # bitbake conflict
>    phyboard-mira/isar-image-ci-debian-bookworm-phyboard-mira-initrd.img
>    phyboard-mira/isar-image-ci-debian-bookworm-phyboard-mira-vmlinuz
> 
> 2. After the duplication e.g.:
> 
>    phyboard-mira/debian-bookworm-isar-image-base/imx6q-phytec-mira-rdk-nand.dtb  # Same contents in our testcase
>    phyboard-mira/debian-bookworm-isar-image-ci/imx6q-phytec-mira-rdk-nand.dtb    # Same contents in our testcase
>    phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira-initrd.img        # Currently not in the subdir
>    phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira-vmlinuz           # Currently not in the subdir
>    phyboard-mira/isar-image-ci-debian-bookworm-phyboard-mira-initrd.img          # Currently not in the subdir
>    phyboard-mira/isar-image-ci-debian-bookworm-phyboard-mira-vmlinuz             # Currently not in the subdir
> 
>    Or we could move the kernels and initrds into the subdir as well:
> 
>    phyboard-mira/debian-bookworm-isar-image-base/imx6q-phytec-mira-rdk-nand.dtb
>    phyboard-mira/debian-bookworm-isar-image-base/initrd.img
>    phyboard-mira/debian-bookworm-isar-image-base/vmlinuz
>    phyboard-mira/debian-bookworm-isar-image-ci/imx6q-phytec-mira-rdk-nand.dtb
>    phyboard-mira/debian-bookworm-isar-image-ci/initrd.img
>    phyboard-mira/debian-bookworm-isar-image-ci/vmlinuz

Moving kernel and initramfs would make things more consistent, indeed.

Only thing to double-check first would be if we are already completely
off compared to how OE deploys or if we can follow a pattern there. If
are off, I would go for this consistent relocation. If not, we should
check if (re-)aligning would both solve our issues and make things
simpler for people coming from that world.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/a217047e-5200-4283-8a22-25cfe2c931db%40siemens.com.