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

28 May 2007

      ...
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?
Yes, but not by doing that manually.
It was suggested that you do not need any command
to do that compare since you can copy from dataflash to SDRAM.
If you use 64 kB buffers, then you have to type in 96 U.boot commands
to do that single compare.
...
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.
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.
The amount of flash and ram is typically determined by the need of 
the application, and not by the qualifications of the person running U-boot.
...
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.
That is funny because I have done that patch.
...
...
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.
It is not finished, since people would like to "clean" up the memory commands
but you are avoiding the point, in favour of advocacy.
Parallel flash CANNOT be written in the same way as SDRAM.
Why should then parallel flash be considered as memory.
I really do not advocate that this is changed, but I would like to see
some consistency in arguments.
...
...
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?
Wolfgang suggested byte writes should be implemented as 
1) Copy to SDRAM
2) Modify SDRAM
3) Write to Dataflash
which will result in above inefficiency.
...
Best regards,
ladis
Personally, I would like to see an architecture where every memory
registers itself in a common database.
When a memory command is executed, the command should be split 
the memory areas involved into pages, and execute the command
on each page.
Each driver would, if neccessary copy its data into a SDRAM buffer before use.
cp.b
for each registred memory do
         if(src = parse(parameter 1)) != FAIL) 
                break;
         end if
     done
     if(src == FAIL) then
            src = SDRAM
    end if
for each registred memory do
         if(dst = parse(parameter 2)) != FAIL) 
                break;
         end if;
    done
     if(dst == FAIL) then
            dst = SDRAM
    end if
/*
         Now you have src pointing to a descriptor for the first parameter
         and dst pointing to a descriptor for the second parameter.
        - Without any ifdefs, and easily extendible.
    */
    pageesize = determine_pagesize(src,dst);
for(i = 0; i < size; i += pagesize) {
            Ensure that src is accessible using a memory pointer to SDRAM
                 * maybe by reading from storage to SDRAM
                 * if in SDRAM/par flash memory, just return pointer
            Copy page to destination, using access routine defined in storage driver.
    }
Best Regards
Ulf Samuelsson