On Wednesday 10 October 2007, Wolfgang Denk wrote:
In message 200710101918.48152.vapier@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