[U-Boot-Users] embedding environment by hand

Mike Frysinger vapier at gentoo.org
Thu Oct 11 01:42:56 CEST 2007


On Wednesday 10 October 2007, Wolfgang Denk wrote:
> In message <200710101918.48152.vapier at gentoo.org> you wrote:
> > 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.
>
> But to do so, the "image" (= u-boot.bin ?) should not need to be
> touched, or why should it?

it isnt being touched.  the LDR image is being touched.  you can think of it 
as something like:
objcopy -O binary u-boot u-boot.bin
(
dd if=u-boot.bin count=10
./tools/envcrc --binary
dd if=u-boot.bin skip=10
) > u-boot.ldr

> I mean, I can convert U-Boot and download it as S-RECs or as an Intel
> Hex file or whatever - this changes just the format, but not the
> content.
>
> I'm afraid I don't understand what you're trying to say.

because u-boot.bin is not burned into the flash, the u-boot.ldr file is.  we 
want to embed the environment into u-boot.ldr because that is the file that 
gets burned into flash and because only the first few sectors of the flash 
are of the "small" variety.  so we cannot have the environment live in a 
different location in flash or it'd be a huge waste.

consider the layout of the flash:
first sector: 0x0 - 0x2000
second sector: 0x2000 - 0x4000
third sector: 0x4000 - 0x6000
...
n sector: 0x80000 - 0x90000
n+1 sector: 0x90000 - 0xa0000
...

we have to make sure that the environment lives at 0x2000 bytes into 
u-boot.ldr because u-boot.ldr is burned into the flash.  using the standard 
u-boot linker script will only make sure that the environment lives at 0x2000 
bytes into u-boot.bin.  but the process of converting u-boot.ldr into 
u-boot.bin adds a variable amount of overhead -- it cannot be precalculated 
and stored in the board header file so that the linker script makes sure that 
(0x2000 - ldr format overhead) into u-boot.bin lines up with the 0x2000 
offset into u-boot.ldr.

instead, we simply tell the utility that generates u-boot.ldr "create some 
space at offset 0x2000 of size 0x4000" so that when the u-boot.ldr is 
actually burned into flash, these offsets correspond to the small sector in 
the flash reserved for the environment.

however, we still need to populate that initial space we made in the 
u-boot.ldr, so the patch i proposed allows extracting the binary version of 
the environment and passing it to the utility which creates the u-boot.ldr.
-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/e2e6e8b2/attachment.pgp 


More information about the U-Boot mailing list