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?
Not in U-boot but in very efficient databases, the virtual memory is used to directly map to hard disks since this is much more efficient than file access. This is one of the main reasons to move to 64 bit virtual addressing
my primary concern is ease of use, and I am pretty sure that any new interface will result in more typing than the old interface.
Just the thought of having to type "spi write" or "dataflash write"
instead of
"cp.b"
sends shudder down my spine...
If people agreed that we change the memory interface from "cp.b" to
"memory write"
then I would have more sympathy for the change.
Any interface to dataflash would need the following operations:
* move from sdram to dataflash (with optional checksum write & byte granularity) * move from dataflash to sdram (with optional checksum check & byte granularity) * compare dataflash to sdram * list dataflash contents * fill dataflash * modify dataflash (with byte granularity) * erase dataflash (byte and partition) * enable/disable write protection of dataflash partition * print dataflash chip info
I see no reason to compare two dataflash areas and to compare two dataflash areas.
It should be possible to stored the environment in dataflash
The partitioning of the flash needs to take into account that the dataflash pages are not 2^n, they are 2^n + some small amount. The 256 page sectors should also be taken into account. The current partitioning is totally screwed for a linux-2.6 kernel. It would be good to be able to change the partition information dynamically so you can grow/shrink the linux-kernel size.
Possibly the pagesize should be migrated into the environment
[snip]
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com AVR32 Applications Group mailto:avr32@atmel.com http://www.avrfreaks.net/; http://avr32linux.org/ http://www.at91.com/ ; ftp://at91dist:distrib@81.80.104.162/