[U-Boot-Users] embedding environment by hand

[Mike Frysinger]

On Wednesday 10 October 2007, Wolfgang Denk wrote:
> In message <200710101825.30341.vapier at gentoo.org> you wrote:
> > first a little background ... the Blackfin processor has a custom object
> > format for booting code (called a "loader file" or "LDR" for short). 
> > this custom object format is what actually gets burned into say parallel
> > or spi or nand flash.  i have to hope that the Blackfin processor isnt
> > alone in having a custom object format ;), so hopefully the changes i
> > propose here will be> useful to others.
>
> Never heard about such a thing. All the rest of the  world  is  using
> ELF  as  long  as images need a structure that must be processable by
> tools, and raw binary blobs for anything else.

we're talking about the format below that ... "u-boot" is a perfectly standard 
ELF.  however, the processor itself does not understand ELF.  so at power on, 
a few pins tell the processor where to start executing ... parallel, spi, 
uart, whatever.  the processor will start fetching data from the defined 
place and load up the image into memory.

> Don't you use any GNU toolchain there? Isn't there  any  support  for
> the GNU linker? Can't you use standard tools?

the Blackfin port is fully integrated into the GNU toolchain and doing 
everything the "correct" way.

> > the exact object format is irrelevant here, but the point is that while
> > the environment is actually embedded inside of the LDR image, it cannot
> > be embedded with the standard method of creating the data array
> > "environment" in environment.c and making sure the environment.o object
> > gets linked at an exact offset.  this is because we take the u-boot.bin
> > and run it through another utility to get u-boot.ldr.  the offsets in
> > u-boot.bin do not correlate in any way to the offsets in u-boot.ldr nor
> > can they as the LDR format may different drastically by processor.
>
> Ummm... this sounds like linking to  me,  and  if  your  linker  tool
> performs such shifting and reordering, it also has to adjust the code
> that  references  such  shifted or reordered memory. If it doesn't, I
> don't understand what it does at all except from corrupting perfectly
> good images ;-)

i could update BFD and define a new object format so that we could do:
objcopy -O LDR u-boot u-boot.ldr
but the end result would be exactly the same -- the offset into the binary 
blow "u-boot.ldr" would not correspond to the offset into the binary 
blow "u-boot.bin".

with these comments in mind, i think you can re-evaluate the previous 
e-mail ;)

> > --- common/environment.c	(revision 950)
> > +++ common/environment.c	(working copy)
>
> This makes no sense to me.

./tools/envcrc --binary > environment.bin

and then this bin file can be given to any other tool so that it can be 
embedded as need be
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071010/b62af489/attachment.pgp