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

[Baurzhan Ismagulov <ibr@radix50.net>]

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.


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


> 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


With kind regards,
Baurzhan

-- 
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/aZXm9bM3vhRuQDE4%40abai.de.