[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

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.
Here's my short list:
- different block sizes; DataFlash can be written byte at a time;
while other devices have minimum write sizes.  Some devices need
blocks to be specifically erased before rewriting.
- memmapped flash can be be read directly on the memory bus; but
writing requires a special routine
- Large variation of size, from a few kbytes up to thousands of gigabytes.
- Some devices are typically partitioned for convenience
- speed differences
- large number of

The technology varies wildly, but they are all storage devices which
store of an ordered sequence of bytes.  In every device, the address
of a single item of data can be boiled down to a single integer.

Take a look at the following interface.  For *most* commands; how well
does this is this api encapsulate those differences for common
commands?  Assume that device specific commands still exist for things
that don't fit well into the model.  ie. block erase and protect
commands.

open(device) # Prepare for read/write operation
seek(distance, abs_flag)  # Relative or absolute seek
read(buffer, count)
write(buffer, count)
close() # Operation finished; sync any pending buffers back to disk.
Notes:
   - assume device can only be opened once.  ie. it's a bug to call open() twice
   - this could be used by commands like mm, md, bootm, etc.  I'm not
trying to design a full control interface (protect, erase, etc).
   - common commands would typically call open(), seek(),
read/write(), read/write(), ..., close() before returning to user.
ie. device would *not* be left open after command completes.
   - should be suitable for partition access too
   - read/write commands are expected to transparently handle block
boundaries.  ie. if one byte is written to the middle of a block; the
write hook should read the block, modify the byte, and keep it
buffered until it either a read/write/seek() moves to another sector,
or close() is called.
   - and yes, I'm just using the each device as a file perspective.
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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195