On Wed 10 Oct 2007 19:28, Wolfgang Denk pondered:
I'm afraid I don't understand what you're trying to say.
The LDR file format, is an ELF-like container that the Blackfin on-chip BootROM understands/requires on new chips. Rather than putting an ELF relocator into the bootrom, and forcing everyone to use ELF files, ADI (not me) made up their own file format. If you are interested, I can point you to the spec, but my guess is you don't really care.
The Blackfin (on newer devices) has no way to do execute in place, or load the u-boot.bin file from flash - I was told that this was done to enable/ensure secure boot. (The first instruction fetch on a reset is always the internal ROM), depending on the settings of external pins & internal registers (OTP), it can load a bootstream (from NAND, NOR, SPI Flash, I2C EEPROM, or UART), potentially validate a checksum, or signature, and either halt, or continue to run/load.
To boot from the newer parts - since we can't use the u-boot.bin file anymore, we are required to create the ADI made up LDR file format.
What Mike has done is to create a tool/utility that takes the standard u-boot (elf) file, and re-packages it into the LDR container. This is distributed with the Blackfin Toolchain rpm/deb/emerge/src under the GPL.
Does that make sense?
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.
If so, back to Mike's question:
We are having problems embedding the U-Boot environment into this ldr file.
The utility that repackages the u-boot (elf) into the u-boot.ldr has the ability to reserve space inside of the LDR image. For example - we can tell it to reserve/leave blank, the area from 0x4000 to 0x6000.
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.
This seems to work OK.
However, the initial u-boot (elf) is generated without the default environment programmed into it.
Our proposal 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/blank and we can use envcrc helper to extract the environment blob so that the blob can be passed to external utilities for embedding.