Hi Jan,

On Fri, 14 Jan 2022 at 06:40, Simon Glass sjg@chromium.org wrote:

Hi Jan,

On Fri, 14 Jan 2022 at 02:40, Jan Kiszka jan.kiszka@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@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...() ?

You probably figured this out already, but Image.FromFile() is called when the image is read in, and creates the Image with certain flags. So you can easily find out if the image was read in or is being generate, and probably don't need to add a property to the fdtmap.

Regards, Simon

Regards, Simon

...

Jan

[1] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/k3-am65-iot2050-bo...

-- Siemens AG, Technology Competence Center Embedded Linux