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