[U-Boot-Users] Atmel DataFlash hooks.

J. William Campbell
2007-01-28T01:47:05Z

Hello All,
Grant Likely wrote:

>On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
>
>
>>In message <528646bc0701261111i6f0dcb0i96f81259b3a4311d@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