Le lundi 30 août 2010 à 11:29 +0200, Detlev Zundel a écrit :
Hi Thibaut,
Hi,
generally I'm not a fan to include workarounds for bugs which we do not have anymore in mainline U-Boot.
Hm, yeah, I can understand that...
Isn't there any other alternative for this?
Well, for my use case, we have to workaround this bug. We can do that (adding a byte at the end of some files) outside of mkimage, but it's really a u-boot thing, so, it could really go in there.
If nobody objects to the genereal principle, then I have some requests below.
[...]
Hm, as I read it, you add 4 bytes (not one) in case the image is already padded correctly to 32-bit, correct? If so, then please correct the comment.
Yes, you add one byte to the end of the file itself, and it'll add 4 bytes to the resulting image file.
It's not really clean, but it shouldn't cause any problem. At least, I haven't encountered any using this patch.
[...]
@@ -586,6 +592,7 @@ usage () " -e ==> set entry point to 'ep' (hex)\n" " -n ==> set image name to 'name'\n" " -d ==> use image data from 'datafile'\n"
" -p ==> force padding in multi-file images\n"This is no real padding, so please don't make it look like it is. Maybe use "q"(uirk) as an option character and change the description to indicate that this is not a "forced padding" but a "incorrect additional 32-bit padding to work around an old bug (see man-page)". A fix to "doc/mkimage.1" which now exists is also mandatory.
Yeah, indeed, it's not really a padding, I'll rephrase the command option description and document it in mkimage.1.
Regards, Thibaut Girka.