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