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
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