Dear Robin,
in message 200710150059.20355.rgetz@blackfin.uclinux.org you wrote:
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?
Thanks for the explanations - it does.
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?
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.
Then just reserve the space for the environment sectors, adjust the U-Boot configuration to use these, and be done with it, i. .e leave the envrionment as a separate (not embedded within the image) aread and uninitializedz.
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.
OK.
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.
Indeed. Sounds OK.
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.
Situation is:
* Boards with an embedded environment have *initialized* environment sectors embedded within the image. This may be considered an advantage (because you have an initialized, valid environment in flash when you first install U-Boot on a board) or a disadvantage (because any update of the U-Boot image in flash will overwrite your current environment settings, unless you take spacial care to restore these after programming the U-Boot image to flash).
* Boards with separate envrionment work a bit differently: after intial installation on a virgin system the separate flash sectors are still empty (without valid checksum) and thus U-Boot prints a warning message and uses the compiled in environment. The external flash sectors get initialized only when you run a "saveenv" command. This may be considered an advantage (because your current environment will not be overwritten when you iuntsall a new version of U-Boot) or a disadvantage (because after initial installation of U-Boot no valid environment is found in flash so the warning gets printed).
Whether you prefer one or the other is mostly a matter of taste. In general, seaprate environments are easier to handle and somewhat moe robust.
Our proposal is to introduce:
- a new define "ENV_IS_EMBEDDED_CUSTOM" and
- add a new flag to the envcrc helper.
I see no need for this.
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.
[Maybe we could meet at #u-boot and discuss this online if you feel I'm too stubborn to understand the obvious..]
Best regards,
Wolfgang Denk