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

[Ulf Samuelsson]

> We also have board with NAND FLASH only and the number of those boards will 
> grow in the near future. The NAND command interface of course need a little 
> more typing, but I always configure a few environment variables to update the 
> images in the NAND FLASH. Something like:
> 
> => setenv nload 'tftp 200000 board/u-boot.bin'
> => setenv nupdate 'nand erase 0 40000;nand write 200000 0 40000'
> => setenv nupd 'run nload nupdate'

Yes, yes :-) Here I agree with Wolfgand and Stefan. U-Boot should
provide commands which reflect principle of device without any
abstraction. Knowing principle means usually less bad surprises coming
out from some hidden abstraction implementation details. That's good for
power users.

=> OK, then tell me how
   to compare a 6 MB
   file in flash with a 6MB
   file in SDRAM when
   your SDRAM is 8 MB.

   We are *not* running on
   PC's.

   There is nothing that stops
   "power users" from copying
   from dataflash to SDRAM 
   and then doing a compare.
   Power Users are limited
   by implementations which
   waste enormous resources.

   I would have more respects
   for exhibited views if writes
   to parallel flash is removed
   from cp.b...
   Parallel flash is clearly not
   "memory" for write 
    purposes, only for read
    purposes.
    Its existence in cp.b will 
    force endless #ifdefs
    or support for parallel flash
    will have to remain and
   bloat code.
 
    You could then argue that 
    support for parallel flash 
    should be removed from
    all commands to remove
    inconsistencies...

   I do not think this will
   happen because it is
   *useful* and because
   this affects boards which
   people that makes 
   decisions works with
   this. They do not work
   with dataflash and do
   not care about people
   that wants this.

   I think that consistency
   in argumentation is a
   reasonable demand.
   
  

   * BYTE WRITE

   Why should you waste
   time on copying dataflash
   to SDRAM when you can 
   do operations inside the
   internal SRAM.

   It is not desirable to transfer
   20,000 bits between CPU
   and dataflash when 100-200
   are sufficient.
   Personally I would like 
   everyone that did not 
   bother to read and under
   stand the AT45 dataflash 
   datasheets to do so before
   sending comments about  
   how the internal 
   implementation should look
   like.


Best Regards
Ulf Samuelsson