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

[Wolfgang Denk]

In message <01f401c79e40$5e938450$0302a8c0 at atmel.com> you wrote:
>
> Any interface to dataflash would need the following operations:

Good. We're back on a technical level and can discuss potential
implementations.

Let me try to reformulate yur suggestions a bit, trying  tomap  these
into  my  idea  of  a  possible  interface  (just  as base for future
discussion):

> * move from sdram to dataflash (with optional checksum write & byte
> granularity)

* Copy from memory to dataflash

  I see no reason why we should restrict the source of  the  copy  to
  RAM.  Also,  we should use the term "copy" as "move" to me includes
  the operation of removing/erasing the source of the data.

  What exactly do you mean by "checksum write"?  The  currently  used
  "cp.b" interface doesn't do anything like this either, or does it?

> * move from dataflash to sdram (with optional checksum check & byte
> granularity)

* Copy from dataflash to memory.

  Same remars as above.

> * compare dataflash to sdram

* That would be a two step procedure, like currently used for other
  storage devices:

  - Copy from dataflash to memory
  - compare two memory areas

  No new command needed.

> * list dataflash contents

  What exactly do you mean here? Do you have any such function
  currently?

> * fill dataflash

* That would be a two step procedure:
  - fill memory area (RAM)
  - copy from memory to dataflash

  No new command needed.

> * modify dataflash (with byte granularity)

* That would be a three step procedure:

  - Copy from dataflash to memory
  - modify memory
  - copy from memory to dataflash

  No new command needed.

> * erase dataflash (byte and partition)

  OK.

> * enable/disable write protection of dataflash partition

  OK.

> * print dataflash chip info

  OK.

> I see no reason to compare two dataflash areas and to compare two
> dataflash areas.

Neither do I, as it boild down to the elementary functions listed
above: copy to memory and compare in memory.

> It should be possible to stored the environment in dataflash

Agreed.

> It would be good to be able to change the partition information
> dynamically
> so you can grow/shrink the linux-kernel size.

The mtdparts command should support dataflash devices, too.

> Possibly the pagesize should be migrated into the environment

What do you mean by that?

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
Randal said it would be tough to do in sed. He didn't say  he  didn't
understand  sed.  Randal  understands sed quite well. Which is why he
uses Perl. :-)         - Larry Wall in <7874 at jpl-devvax.JPL.NASA.GOV>