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