On Fri, 03 May 2013 17:54:25 +0200 Wolfgang Denk <[email protected]> wrote:
> 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". Most images I have seen for kirkwood, ar71xx, ralink, and I'm sure there are more. > > 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. But that's what U-Boot does. The quoted code is taken straight from git. My impression was that if U-Boot accepts this image, then mkimage should, too. > > 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. Okay, after a bit of IRC discussion the following compromise: If the header is correct, and the crc is correct for the ih_size data, then assume everything is fine, but print out a warning if the file length does not match the header lengh + ih_size. My typical use case would be looking at vendor images or flashdumps and check if they have a valid uimage header. With this patch I can do it easily with the imagefile/flashdump, without it I would need to parse the header first manually, find the ih_size field, truncate the file to the expected size, and then hope the header is valid. Best regards, Jonas Gorski _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
