On 5/28/07, Ladislav Michl ladis@linux-mips.org wrote:
Principle described above has few serious drawbacks. Storage is no longer storage, but randomly mapped memory. As a u-boot programer you have to determine such memory map and as a u-boot user you have to remember it.
Exactly. Giving storage devices which aren't memory mapped a "virtual" address is a bad idea. And the database example is crap because it depends on hardware paging, which isn't being proposed here (how many architectures supported by u-boot can do 64-bit virtual address in hardware?)
That said, I do think Ulf has a point -- being able to compare a block of data in nand- or dataflash with something in memory (or other kinds of storage) is a pretty neat feature. But it should not be done by using "virtual" addresses (due to the problems described above), and it should be implemented in a generic way. Pouring #ifdefs all over cmd_mem.c is short-sighted and selfish.
My proposal removes all #ifdefs from memory commands.
I'm not sure if anyone's suggested this before, or whether it was well-received or not, but why don't we generalize the cmd_mem syntax a little? For example, let every memory address can be prefixed by an optional "storage specifier" and a ':' character. The default "storage specifier" is "mem", so that if it is omitted everything will work as before, but you can also do things like
cp.b df0:0x4200 0x85000000 cmp.l 0x24000000 nand1.1:0x123456789
Which is 100% compatible with my proposal.
"cp.b df0:0x4200 0x85000000 ${size}"
is decoded by the command parser and the "cp" command is selected.
"cp" sends "df0:0x4200" down the chain of registred memory/storage devices. The NAND flash driver will not understand "df0" so it ignores the parameter. The dataflash driver detects that this is a dataflash and decides it is a success and returns a pointer to a descriptor allowing the "cp" command to read/write dataflash.
Then "cp" sends down the "0x85000000" parameter, and it is decided that this is located in SDRAM.
"cp" then calls the dataflash specific copy to sdram routine (from the descriptor) using 0x85000000 and ${size} as parameters.
The dataflash copy routine will (in the AT91 case) just set up the initial address and copy chunks of 64 kB using the DMA controller (PDC).
No need for any #ifdefs to handle this as far as I see.
and so on. Whatever comes after ':' is passed to the storage handler as a string, so if some storage types need 64-bit offsets, the handler can support it without disturbing anything else.
What do you think about something like that? The actual syntax probably needs some work to get right, and we need to take care to ensure backwards compatibility of course.
This does actually come quite close to Ulf's proposal, but instead of requiring the user to remember a "virtual address", we instead require him to enter a logical device and an offset, ie.. kind of a simple VFS without any actual files involved...
I never said that you need to supply an address, you need to supply a parameter, but the syntax of this can be driver specific.
Haavard
Best Regards Ulf Samuelsson