[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/27/07, J. William Campbell <jwilliamcampbell at comcast.net> wrote:
> Grant Likely wrote:
> >On 1/26/07, Wolfgang Denk <wd at denx.de> wrote:
> >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.

Yes, a device driver exports a table of ops and it is free to omit any
operations it does not support.

BTW, for this iteration, I'm only looking at device read/write.  I
plan to leave the protect/erase/etc commands alone (use existing
commands)

> This way, it
> is possible to read/write from any "device" to system ram.

yes

> A driver to
> treat system ram as a device could also
> be compiled into u-boot.

Hmmm, I think that goes too far.  Memory mapped ram is always
available and doesn't need any special operations to access it.  I
don't see any value in wrapping it with a device driver.

> 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.

Yes.  I'm not fond of this behavior, but it can be easily implemented.
 I don't like the idea of pretending non memmapped devices have real
bus addresses.  I would prefer a namespace which defines the device
you want to talk to.  For example:

Instead of: "cp 200000 cf004000 200"  (copy from 0x200 bytes from mem
address 200000 to address 0x4000 on MMC card)
I'd prefer: "cp 200000 mmc0:4000"

But, I don't want to debate this issue just yet.  For the time being,
I'll stick with using virtual memmapping (status quo for MMC and
DataFlash).

> 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.

Yes, mostly, as long as regular memcpy is used wherever possible.  For
copy operations, I see four possible cases:
1. memory to memory
2. memory to device
3. device to memory
4. device to device

1. is trivial; it's just memcpy.
2 & 3 are mostly trivial; a call to the device read/write hook can
operate directly on memory
3. this is not trivial (but not hard either).  It  requires the copy
routine to buffer all data to be transfered, and also to reconcile
between differing block sizes.  I'm tempted to say this is either not
supported; or is an optional feature.

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