[U-Boot-Users] embedding environment by hand

[Wolfgang Denk]

Dear Robin,

in message <200710150059.20355.rgetz at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_