[U-Boot-Users] embedding environment by hand

[Robin Getz]

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.