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