public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Baurzhan Ismagulov <ibr@radix50.net>
To: isar-users@googlegroups.com
Subject: Re: [PATCH v2 1/1] copy dtbs into a subdirectory based on image name
Date: Wed, 17 Apr 2024 10:25:21 +0200	[thread overview]
Message-ID: <Zh+HcZ03CXpK84d0@ilbers.de> (raw)
In-Reply-To: <3ca17e6f-d449-4a8c-b97e-026f31ae6e5b@siemens.com>

On 2024-04-16 17:36, 'Gylstorff Quirin' via isar-users wrote:
> On 4/16/24 12:07 PM, Nicusor Liviu Huhulea wrote:
> > There are cases when multiple images are build and because the same dtbs
> > are copied in deploydir we have a build failure. The build error is related
> > to files that are installed into a shared area where those files already exists.
> > 
> > To solve this situation we will copy each dtb in a subdirectory based on
> > image name thus avoiding the conflicts. Therefore the other areas needs to be
> > updated on the dtbs paths.
> 
> This is a special use case, which breaks all downstream layers which
> currently use devicetrees. Coping to the directory dtbs should be disabled
> by default as for most uses it is unnecessary.

The origin of the problem is bitbake QA with multiple images. The kernel recipe
builds the dtb which is deployed by the image. In case of multiple images, the
dtbs are considered as different from bitbake PoV and it complains about it --
this is the problem we are trying to address. In our experience, multiple
images are common -- and we would still need a solution for a supported feature
even if they weren't.

>From the user PoV, multiple directories with the same dtbs are not necessary at
all. So, I'm not a fan of the per-image dtb approach although we also have a
similar patch to address the immediate failures that we are experiencing. If we
go with this approach, I wouldn't welcome switching per-image dtb on and off --
we already have many variables and are missing coverage for untested
combinations; maybe some configurable deployment path at most.

That said, I think we should really try to bringe the bitbake model closer to
the reality and look at moving this to the kernel recipe as Uladzimir has
suggested. Maybe there are cases that need to be verified (like different
kernels building the same dtbs) and might still need further adjustments.

With kind regards,
Baurzhan

  parent reply	other threads:[~2024-04-17  8:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16 10:07 Nicusor Liviu Huhulea
2024-04-16 15:36 ` Gylstorff Quirin
2024-04-17  7:59   ` Uladzimir Bely
2024-04-17  9:30     ` nicusor.huhulea
2024-04-17  8:25   ` Baurzhan Ismagulov [this message]
2024-04-19  9:45     ` Gylstorff Quirin

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=Zh+HcZ03CXpK84d0@ilbers.de \
    --to=ibr@radix50.net \
    --cc=isar-users@googlegroups.com \
    /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