[U-Boot] [PATCH] tools/envcrc: add --binary option to export embedded env

[Mike Frysinger]

On Tuesday 28 April 2009 03:13:05 Wolfgang Denk wrote:
> In message Mike Frysinger wrote:
> > > Should we not rather use 0xFF for padding - given that the envrionment
> > > is frequently stored in NOR flash?
> >
> > i would love to (and with the Blackfin stuff, i do just that), but the
> > problem is that there is no way of forcing the embedded environment to
> > 0xff pad that i know of ...
>
> You mean in the code? Well, if you're using a separate section for it
> (like the ppcenv section) this should be  straightforward  using  the
> `=FILLEXP' output section attribute for the linker.

hmm, a quick grep shows that almost no one has a dedicated section.  the 
majority of people (Blackfin boards included) insert it into the middle of 
their .text section.  this is the use case i was thinking of when i said "no 
way" because i hadnt seen anyone using a dedicated section before.

> > so, to keep the most common behavior from changing (the char[] env is
> > embedded in the .data section padded with 0x00), the padding defaults to
> > 0x00.  this way `envcrc` outputs the right value (see common/Makefile).
> >
> > for people (like me) who are using --binary to extract the env blob, we
> > can do --binary=0xff and get what you're talking about.
> >
> > i could extend the behavior so that using plain "--binary" is the same
> > thing as "--binary=0xff" ...
>
> OK.
>
> I guess you want to suggest that I accept this patch as is, and we
> address the gap filling with 0xFF in a separate patch? ;-)

if you want the "--binary" thing, i can post a new patch.  otherwise yes, i 
dont see any changes to be made for now.
-mike
-------------- 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/20090428/ae1bc0ef/attachment.pgp