[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Hello All,
Grant Likely wrote:

>On 1/26/07, Wolfgang Denk <wd at denx.de> wrote:
>  
>
>>In message <528646bc0701261111i6f0dcb0i96f81259b3a4311d at mail.gmail.com> you wrote:
>>    
>>
>>>My vote is to treat DataFlash like a block device, and make sure that
>>>it supports byte-wide access.
>>>      
>>>
>>Treat DataFlash like a block device? That sounds wrong to me.
>>    
>>
>
>I've been thinking about this some more, and I'm not sure I agree.
>  
>
>Just for the moment; forget the term 'block device' and forget about
>the current implementation of u-boot.  How significant are the
>difference between the following devices? mmc, CF, IDE HD, SCSI HD,
>DataFlash, memmapped flash, NAND flash, i2c eeprom, USB storage.
>  
>
<snip>

>It's a well established abstraction, so why not here too?
>
>I think this is a reasonable approach to provide a common interface
>without making device specific side cases too complex to deal with.
>Adding new device support to all commands becomes pretty trivial this
>way.
>
>Thoughts?  Feel free to tell me if I'm flying too high in the
>stratosphere on this one.
>g.
>
>  
>
I think Grant has a good point. The discussion about abstractions used 
to read/write devices and memory is
really a discussion about a memory hierarchy. If we treat it this way, 
it is possible to optionally give everybody
what they want while still allowing a "minimal" u-boot configuration for 
people who do not desire a particular
feature of the "storage hierarchy". Suppose we have an abstraction that 
treats CF, IDE HD, DataFlash,
memmapped flash etc. as a device. We also have a set of commands that  
read/write to these devices. There
will be a protect command that does nothing on devices that do not 
understand this command. This way, it
is possible to read/write from any "device" to system ram. A driver to 
treat system ram as a device could also
be compiled into u-boot.
As Grant discussed in an earlier part of this thread, we can also modify 
the current memory commands such that
there is a table of what I will call "mmapped address". If the mmapped 
support is enabled, all memory commands
will pass through a routine that splits them up into sub-commands that 
operate on addresses in single parts of the
mmapped address table for both source and destination. This would 
include breaking the commands into "sector-sized"
operations based on an entry for the sector size in the table. 
Non-sectored devices can use all 1s for the sector size.
The memory commands now would consist of a seek/read from one "device" 
followed by seek and read or write
from another device. If necessary, buffering would be provided by two 
dedicated buffers in the memory command
subsystem.
This "mmapped"  table already basically exists in the current memory 
access system, with almost the right things in it.
Ram/Rom/Flash that has CPU memory  bus addresses appears at the 
"natural" addresses in this table that are
actually occupied by the "media". Unoccupied memory bus addresses are 
assigned to media that does not actually
appear on the bus. This is presently done manually  The memory commands 
would then be executed by calling routines
from the mmapped table to do the reads and writes. These routines should 
use the same I/O routines as are used for
device-mode access.
If the user wants to maintain the ability to operate with memory 
commands on bus-addressed memory of any kind,
it is simple to initialize the mmapped address table appropriately. 
u-boot can also add entries to this table at start-up
if some kind of flash is dynamically detected. This feature also 
provides a natural way to extend this type of support
to any device that can read/write/seek. The user can either build-in 
address ranges/device mappings at u-boot
compile time, they can be dynamically detected, and/or a console command 
(mmap?) could be optionally added to do
dynamically.  If the user does not want this type of support, it can be 
completely omitted from the u-boot build and all
memory type commands will be executed using the CPU ram read/write 
routines and addresses.
I think this approach gives everybody what they want. In cases where 
"normal" ram and device access to a few devices
is all that is desired, u-boot would probably be slightly smaller than 
it is now. If mmapped support is included, it might be very
slightly larger, but probably not by much. The mmapped table would 
contain more information than it does at present,
but only a "few" more items per entry.

Comments welcome. I don't think this is really a big change from the 
current system, it is just a formalization of what
has always been desired.

Best Regards,
Bill Campbell