Dear Jonas Gorski,
In message 20130503174205.00000070@unknown you wrote:
Sorry, I don't know how you create your image files, but you must be doing something fundamentally wrong. If mkimage reports a bug here, it is probably right. If the actual payload size is different from the content of the ih_size field, then your image _is_ broken.
That what else for is the ih_size field then except to say what the actual datasize is? mkuimage also sets this fields to the correct size.
It's exactly for this very purpose, and allows for consistency checking. You run into errors, becuase your images are not correct. For plain legacy image format (i. e. we are not talking about multi-file image format here), header size (= 64 bytes) plus the content of the ih_size field will give the total file size of the image. If this condition is not met, then your image is broken.
And this isn't from me, but this is how most firmware images are
Define "most".
created for devices using U-Boot, i.e. uImage packed kernel + appended rootfs. Also U-Boot itself only cares for the first ih_size bytes of the image and not for any "garbage" that might be behind it:
Yes, because in U-Boot we have no notion of "files" and thus no indication where an image ends. Otherwise such a check would be there.
It checks the crc of the first ih_size bytes after the image_header - and my change changes mkimage to mirror that behaviour.
But this is wrong.
It still reports data errors if the checksum is wrong for the data actually specified by the image header, but now it actually respects the length of the data field.
Let me repeat: a valid image will have sizeof(struct image_header) plus ih_size == file size. If this condition is not true, then your image is broken.
Best regards,
Wolfgang Denk