All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thibaut Girka <thib@sitedethib.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC][PATCH] mkimage: Add compatibility option for legacy Multi-File images
Date: Tue, 31 Aug 2010 08:50:21 +0200	[thread overview]
Message-ID: <1283237421.5338.8.camel@debian-thib> (raw)
In-Reply-To: <m2occkla8v.fsf@ohwell.denx.de>

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100831/a33e0a33/attachment.pgp 

  reply	other threads:[~2010-08-31  6:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-18 20:48 [U-Boot] [RFC][PATCH] mkimage: Add compatibility option for legacy Multi-File images Thibaut Girka
2010-08-30  9:29 ` Detlev Zundel
2010-08-31  6:50   ` Thibaut Girka [this message]
2010-09-01 15:04     ` Detlev Zundel
2010-09-02 15:05 ` Wolfgang Denk
2010-08-29 13:05 Per Andersson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1283237421.5338.8.camel@debian-thib \
    --to=thib@sitedethib.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.