[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <030501c79e4e$862cf740$0302a8c0 at atmel.com> you wrote:
>
> >  What exactly do you mean by "checksum write"?  The  currently  used
> >  "cp.b" interface doesn't do anything like this either, or does it?
> 
> No but a way to common error is that the kernel is too large to fit into
> its allocated area and when the file system is written it overwwrites
> the end
> of the kernel.
> In my branch, I can set an environment variable crccheck=1
> and if set, any cp.b to dataflash will add a checksum at the end.
> Any cp.b from dataflash will again compute the checksum
> and compare vs the checksum at the end.

Why would that be needed? The U-Boot image itself is protected  by  a
CRC32  checksum  (by  two,  actually), so any such corruption will be
detected automatically whenever you try to boot such an image.

> Saves me a lot of confusing linux boot errors.

Of course checksums are very useful - but we already have them?

> > * That would be a two step procedure, like currently used for other
> >  storage devices:
> > 
> >  - Copy from dataflash to memory
> >  - compare two memory areas
> 
> If I wanted to wear down my fingers by typing a lot of things,
> I would have choosen a career as a COBOL programmer.

U-Boot follows good old Unix philosophy here: prvode small and simple
tools that implemnt just one task, but this reliably and efficiently,
and provide ways to combine these tools easily to bigger  things.  Of
course  it  is  trivial to combine these steps into one "command" for
the user.

> Your suggestion has the unwanted side effect that you destroy the SDRAM
> in the process, and you have to keep in mind where you put intermediate
> copies.

Well, the same is stru for your current  implementation,  which  also
needs  some buffers in RAM. The only difference is size and locatioon
of the buffers.  U-Boot  usually  remembers  the  "last  used"  image
address,  you  normally you don't need to remember much. If in doubt,
use variables.

> Since dataflash sectors are 256 kB, and you should avoid putting
> linux/rootfs
> in the same sector as u-boot, code size is of much less importance than
> ease of use.

Primarily it's not a question of code size, but of interfaces.

> It is very important to reduce typing to a minimum.

This is not one of my primary targets. It's not even very high on  my
list.

> >> * list dataflash contents
> > 
> >  What exactly do you mean here? Do you have any such function
> >  currently?
> 
> yes

What exactly does it do?

> It should be possible to remove any code accessing parallel flash,
> so the memory commands only access SDRAM.

Agreed.

> Many boards do not have any parallel flash, and this code will just
> bloat the binary.

"Many" is probably not correct if you look at the total of nearly 400
board configurations in the public U-Boot  tree.  But  I  agree  that
support  for  NOR  flash  should be configurable like other features,
too.

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 believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.