On Mon, May 28, 2007 at 04:08:50PM +0200, Ulf Samuelsson wrote:
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.
Not if you could run command in a loop.
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.
Sure. Point was that sane power user will compare chunk by chunk (6 MB file and 8 MB RAM case).
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.
Could you point me to it, please?
[snip]
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.
NOR interface is finished.
Parallel flash CANNOT be written in the same way as SDRAM. Why should then parallel flash be considered as memory.
Mapped into address space, CAN be written in the same way as SDRAM. Note that I'm not doing any advocacy here, I want acceptable solution without drawbacks.
I really do not advocate that this is changed, but I would like to see some consistency in arguments.
See below and try to imagine what would need to be done to support 64bit virtual address space.
[snip]
Wolfgang suggested byte writes should be implemented as
- Copy to SDRAM
- Modify SDRAM
- Write to Dataflash
which will result in above inefficiency.
That's only suggestion.
Personally, I would like to see an architecture where every memory registers itself in a common database.
And memory is even IDE disc as you suggested in your database example?
When a memory command is executed, the command should be split the memory areas involved into pages, and execute the command on each page.
So here you basicaly proposing something like u-boot virtual memory. What if I have storage greater than addresable area? NAND chips are pretty close to that for example (and even today it is quite easy to build such board using few more NAND chips) and consider design with 64MB of RAM, 2GB NAND and 1G SD card and 1G USB stick. Will you move to 64bit address space? In bootloader? Bootloader has always been something simple, usefull only to boot application which does the job. Perhaps it would help if you could express what you expect from a bootloader...
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. }
That's it... Above example needs 64bit virtual address space.
Principle described above has few serious drawbacks. Storage is no longer storage, but randomly mapped memory. As a u-boot programer you have to determine such memory map and as a u-boot user you have to remember it. If you are using partitions you probably want to pass such partitions mapping to linux. Curently it very easy and comfortale, you can copy kernel and rootfs image to partion refered by name, without even knowing where it is. And btw, where would you map OOB area of NAND chip?
Best regards, ladis