On Wed, May 23, 2007 at 06:19:21PM +0200, Ulf Samuelsson wrote:
In message 007301c79d3a$37b63320$f22ab10a@atmel.com you wrote:
I tried to resubmit, but since Grant and Wolfgang has come to the conclusion that sometimes memory is not memory I see no possibility to overcome difference.
Memory is always memory. Serially attached devices are NOT memory.
That is _your_ definition of memory, others like "Webster Dictionary" say:
"Memory: a device (as a chip) or a component of a device in which information especially for a computer can be inserted and stored and from which it may be extracted when wanted; especially : RAM"
You add an extra requirement that memory must be randomly addressable over a parallel bus. This view is uncompatible with Websters dictionary which does not pose such restrictions. Furthermore, everyone designing flash memories, believe that serial flash memories are memories.
That belive has nothing to do with software interface design. While you pretend serial flash memory is somehow mapped into procesor address space, others have different ideas. "Webster Dictionary" uses largest common denominator so its definition applies to hard discs as well. Do we pretend hard disc content is mapped over IDE or SCSI bus into CPU address space?
You have made your decision here, and I have to accept that, but you are then trying to get *me* to make the changes you want, and I really have no incentive to do that and will leave that to others.
Then I'm voluntering to do that work. There is one issue left. The interface. I remember few almost endless debates about this topic, but no conclusion.
Lets dive into archives.
In this thread most of possible solutions were developed. Without conclusion. Subject: Atmel DataFlash hooks. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/25983
And this is another very interesting thread: Subject: [PATCH] DataFlash for AT91RM9200DK board http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/9175 It contains quite interesting part which is worth to repeat there (by Wolfgang Denk, 2003-06-04)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In our case, we use it to store and boot an image of linux(the dataflash contains the linux zImage and the ramdisk). This dataflash can be used also for a filesystem.
In this case I think we should offer an interface which looks\ to the user like mmeory.
Instead of providing separate commands to read and write from such "memory" I think we should integrate this into the existing code.
For example, writing to "normal" flash memory is an implicit operation to the "cp" (copy) command when it detects that the target address is in flash memory.
The same should be done for dataflash.
OK, with "normal" flash memory we don't have to special-case read accesses like used by "md" or "bootm" commands - where in case of dataflash such handling will be necessary.
But especially if you boot Linux from dataflash it seems more logical to me to use "bootm" directly instead of using "dataflash read" + "bootm" in separate steps.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
That makes clear reasons behind Ulf's statement and also shows that not all decisions are good ones.
If anyone feels need to fix u-boot's dataflash support, then please either lets continue in more than 16 weeks old debate in 'Atmel DataFlash hooks' thread or spawn new one.
Best regards, ladis