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

Hi Alper,

On Mon, 19 Oct 2020 at 15:29, Alper Nebi Yasak alpernebiyasak@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@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