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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
