[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