RE: [PATCH 0/7] Rebuild phyBOARD-Mira UBI image generation

["Schmidt, Adriaan" <adriaan.schmidt@siemens.com>]

Anton Mikanovich, Freitag, 18. Februar 2022 17:38:
> 10.02.2022 09:52, Schmidt, Adriaan wrote:
> > Anton Mikanovich, 9. Februar 2022 14:54:
> >> Rebuild UBI image generation implementation to support any count of
> >> targets with different settings. This also will allow to build the same
> >> isar-image-base image for both UBI and non-UBI targets.
> >> Add correct UBI and UBIFS layouts for phyBOARD-Mira after that.
> > I've just posted a proposal to generally rework image generation
> > ([PATCH 0/6] imagetypes), which overlaps with your patches 1..3.
> > I admit that I don't fully understand the ubi(-ubifs) process, so my series
> > might actually break something here. But I can imagine that your image
> > changes could also get simpler if you put them on top of my imagetypes
> > patches.
> >
> > Adriaan
> 
> The main "blocking" issue I've found is override implementation. We need to
> have a way to use image type related overrides outside recipes included by
> INHERIT variable.
> Moreover, current implementation of overrides for multiple image types looks
> incorrect, because only one type is actually used for override at one
> inherit.

Turns out that this is really hard to implement.
The actual list of image types is computed from IMAGE_FSTYPES:
- remove any conversions (e.g., "wic.xz" should set "wic" override)
- resolve dependencies (e.g., "ova" should set both "ova" and dependent "wic" overrides)

And it seems that the OVERRIDES variable is something so low-level, that
when I try to append a computed list like this, bitbake breaks in very strange ways.

The current implementation (inspired by OE) only sets the override inside
a local environment created for the single IMAGE_CMD. But that means it is
not available at "general recipe level", so in your concrete case (ubi/fit) you
can't use it to change SRC_URI.

I'm wondering if there is a better way to implement that ubi/fit case.
I notice that the wic class makes quite some effort to process the wks file
from a template, while never touching SRC_URI. Maybe appending to SRC_URI
based on image type is just something that should be avoided? I haven't
thought it through yet...

Adriaan