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

[Ladislav Michl <ladis@linux-mips.org>]

On Sat, May 26, 2007 at 12:53:31PM +0200, Ulf Samuelsson wrote:
> => 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.

Chunk by chunk?
But indeed, there is a little problem. It would be usefull to show
address which contains diferences from the beginning of dataflash
(or dataflash partition)...

>    We are *not* running on
>    PC's.

Perhaps it would help, if we could avoid ourselves to state the
obvious...

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

Anyone who copies whole file into RAM and then does compare has either a
lot of RAM or doesn't deserve to be called power user.

Lines 303-308 of common/cmd_mem.c reads (cmp command):
#ifdef CONFIG_HAS_DATAFLASH
        if (addr_dataflash(addr1) | addr_dataflash(addr2)){
                puts ("Comparison with DataFlash space not supported.\n\r");
                return 0;
        }
#endif

On my boards it leads to:
# cmp.l 10000000 C0000000 10
Comparison with DataFlash space not supported.

Therefore it seems I have to copy to RAM anyway and it doesn't seem to
be fixed by any patch at ftp 81.80.104.162.

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

Erm... This interface is finished, contains finite number of features
and certainly finite numbers of #ifdefs. This number could be reduced
even more by removing hacks for MMC.

>     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 have two AT91RM9200 based boards here. One boots from dataflash,
stores enviroment here and loads kernel from NAND. Sure I care about
dataflash support...

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

Could you please point exactly where I suggested such behaviour?

Best regards,
	ladis