[PATCH 16/25] binman: Avoid reporting image-pos with compression

[Simon Glass]

Hi Alper,

On Mon, 19 Oct 2020 at 15:29, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>
> On 19/10/2020 05:41, Simon Glass wrote:
> > When a section is compressed, all entries within it are grouped together
> > into a compressed block of data. This obscures the start of each
> > individual child entry.
> >
> > Avoid reporting bogus 'image-pos' properties in this case, since it is
> > not possible to access the entry at the location provided. The entire
> > section must be decompressed first.
> >
> > CBFS does not support compressing whole sections, only individual files,
> > so needs no special handling here.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
>
> Maybe instead of this, 'image-pos' could be overloaded to a list of
> recursive relative positions within compressed archives? Something like:
>
>     section {
>         offset = <1000>;
>         compress = "lz4";
>         /* image-pos = <1000>; */
>
>         blob {
>             filename = "foo";
>             offset = <100>;
>             /* image-pos = <1000>, <100>; */
>         };
>     };
>
>     cbfs {
>         offset = <2000>;
>         /* image-pos = <2000>; */
>
>         blob {
>             filename = "bar";
>             cbfs-compress = "lz4";
>             cbfs-offset = <200>;
>             /* image-pos = <2200>, <0>; */
>         };
>
>         blob2 {
>             filename = "baz";
>             cbfs-offset = <800>;
>             /* image-pos = <2800>; */
>         };
>     };
>

What do these values actually mean though? What would we use them for?

Note that CBFS compresses its data on a per-entry basis so the
image-pos is actually supported.

[..]

Regards,
Simon