binman generator nodes break over read-back

[Simon Glass]

Hi Jan,

On Fri, 14 Jan 2022 at 02:40, Jan Kiszka <jan.kiszka at siemens.com> wrote:
>
> Hi Simon,
>
> something is fishy with generator nodes: We are playing with replacing
> fdts and configs in [1] with generator nodes, and that works so far -
> until we want to read-back the image:
>
> $ binman ls -i flash.bin
> binman: Node '/fit at 0x280000': Generator node requires 'of-list' entry
> argument
>
> Same for "binman extract". I suspect that the embedded fdtmap still
> contains the generator node, rather than the unrolled entries. Am I
> right? How to check and fix that?

You can check that by looking at the fdtmap in the resulting image.

I suspect the problem is that in fit.py ReadEntries() tries to expand
the entries when this has already been done. I think we need a
separate case here, when reading the fdtmap, to say that the
generation is already done and should not be attempted.

We have properties like orig-offset which get added to provide
information about the original state of the image description. Perhaps
we could add a property like 'generated' in the base Entry class that
we can check in entry types which do this sort of thing. When
generating, we add the property. When reading in an existing image,
the property would be present, so generation is skipped and the FIT is
used as is.

As always the way to start is by adding a test which fails the new
situation. , perhaps based on testListCmd...() ?

Regards,
Simon

>
> Jan
>
> [1]
> https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux