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.
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.
the utility that generates the u-boot.ldr has the ability to reserve space inside of the final image. so in the board configuration file, we say the environment lives at an offset of 0x4000 (to correspond to one of the flash sectors) of size say 0x2000. the utility is then told to generate space at an offset in u-boot.ldr at offset 0x4000 of size 0x2000. now the u-boot.ldr can be burned into flash without a problem and saving of the environment is OK.
however, the initial u-boot.ldr is generated without the default environment programmed into it. so what i'd propose is to introduce a new define "ENV_IS_EMBEDDED_CUSTOM" and add a new flag to the envcrc helper. this would allow the environment.o linked into u-boot.bin to be empty and we can use envcrc helper to extract the environment blob so that the blob can be passed to extrenal utilities for embedding. the patch attached accomplishes both of these things. -mike