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