Dear Jonas Gorski,
In message 20130503183128.00000900@unknown you wrote:
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.
Maybe these do - but these are a tiny, virtually invisible minority of the platforms supported in mainline.
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.
I explained this before: in U-Boot we have no way to figure out the total size (or "file size") as there is no such concept as files. For U-Boot, an image is only identified by it's start address in memory, but we have no length information available, so how could we check it?
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.
No, this was not exactly what we discussed. I wrote:
| I suggest you change mkimage such that it will display the (valid) | image data, but then bail out with a "NNN bytes excess data present" | error message. Note that mkimage must return an error code (EFAILURE) | in this case.
So no warning, but an error, please. And only for excess lenght.
If the length is too short, we are really in trouble, especially if the CRC still matches. This should never happen.
Best regards,
Wolfgang Denk