On Monday 15 October 2007, Wolfgang Denk wrote:
in message 200710150059.20355.rgetz@blackfin.uclinux.org you wrote:
Things are complicated by the fact that this LDR format is not static - and continues to evolve with every new part that comes out, as the person who writes the BootROM decides to add new features, that require new switches and bit fields in the LDR stream.
But it doesn't rip a binary image apart, or does it? If it does - then how do you actually link U-Boot?
it doesnt. the .bin -> .ldr conversion happens after everything. we already have a utility in u-boot mainline that does this (bin2ldr), ive just implemented a more generic version in our svn tree since.
We are having problems embedding the U-Boot environment into this ldr file.
Well, then don't embed it - this is not necessary. There are many board configurations without embedded environment. Embedding the environment makes only sense on certain boards which use boot sector type flash chips where you (1) have to write the U-Boot image to a specific location to match the hardware-defined reset entry point, and (2) you want to use one or more of the smaller boot sectors for the environment, but these are now located right within the U-Boot image.
As far as I understand your decription, you also have small boot sectors you want to use for the environment, but no specific requirement for the location of U-Boot.
there is a specific requirement for the location of U-Boot. it *must* be at the very beginning of flash (where all the boot sectors are). the bootrom on the Blackfin does not support starting at anywhere else, it will only start reading from the very beginning.
However, the initial u-boot (elf) is generated without the default environment programmed into it.
Stop. There is probably some confusion here.
U-Boot always has a default envrionment compiled in. This is somewhere in the data section and only U-Boot knows where to find it. It gets used if none of the coinfigured environment sectors has a valid checksum.
Note that the default environment has *nothing* to do with the environment stored in the configured flash sector(s). It is an *additional* copy.
i am fully aware of this, but that does not change what i want to do. by this argument, there's no reason to have the tools/envcrc utility in the first place. if it isnt designed specifically for embedding the proper crc-ed version into the u-boot image, then it's a useless utility.
this would allow the environment.o linked into u-boot.bin to be empty/blank and we can use envcrc helper to extract the environment blob so that the blob can be passed to external utilities for embedding.
If you don't want to embed the environment (or cannot do it), then just don't do it. Configure as described above, and use it as a separate, detached environment like all the other boards using such a configuration.
except that we *do* want to do it and we *can* as outlined already. -mike