[U-Boot-Users] embedding environment by hand

[Wolfgang Denk]

In message <200710101825.30341.vapier at gentoo.org> you wrote:
>
> 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.

Never heard about such a thing. All the rest of the  world  is  using
ELF  as  long  as images need a structure that must be processable by
tools, and raw binary blobs for anything else.

Don't you use any GNU toolchain there? Isn't there  any  support  for
the GNU linker? Can't you use standard tools?

> 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.

Ummm... this sounds like linking to  me,  and  if  your  linker  tool
performs such shifting and reordering, it also has to adjust the code
that  references  such  shifted or reordered memory. If it doesn't, I
don't understand what it does at all except from corrupting perfectly
good images ;-)

> 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.

That's what we normally do in the linker scripts. Can't you use a
normal linker, then?

> 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 

Why is this the case?

> 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.

I cannot see why that would be necessary. If  you  cannot  initialize
the  embedded  environment,  just handle it like anybody else who not
uses an  initialized  embedded  (i.  e.  for  exampole  a  separated)
environment. Why would you need extra code?

> --- common/environment.c	(revision 950)
> +++ common/environment.c	(working copy)

This makes no sense to me.

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 you're not part of the solution, then you're part of the  precipi-
tate.