On 1/29/07, Ulf Samuelsson ulf@atmel.com wrote:
I'm not sure if I understand. U-boot pretends mmc and DataFlash are memory mapped? That sounds completely insane, especially for MMC. What happens if you insert an 8GB SD card on a 32-bit host?
There is nothing to stop U-Boot memory commands from implementing a 64 bit virtual address space.
Except that for most (all?) CPUs supported by u-boot, the virtual address space _isn't_ 64 bit.
(The day that you have an 8GB Dataflash, Champagne corks will fly.Largest one today is 8 MB)
Yeah, that's why I said it makes slightly more sense to do this with DataFlash than with MMC. But I'm guessing that whoever implemented the memory mapped MMC thing didn't expect MMC cards to reach 8 GB any time soon either.
I haven't actually used DataFlash on any avr32 boards yet, but I have written an MMC driver for it and I didn't even know it could be accessed as a memory-mapped device. In fact, I can't even understand why anyone would want that --
The reason to memory map is that then it is easy to do memory commands like copy, compare etc, which you do want to do on dataflash, even though it is not fully implemented in the current mainstream. I have implemented additional functions, because they are really needed. I wrote them because it is such a pain to copy to RAM before you can compare, and I definitely do not like to have to start doing that again.
I agree that the functionality is needed. I just disagree with the interface.
It is perfectly possible to memory map the dataflash without having a lot of ifdefs, by letting the memory commands call a driver. I believe this is the way forward.
It is easier for a user to learn a single command set to handle flash regardless of type.
How do you teach the user that the DataFlash is mapped at some obscure address that has absolutely nothing to do with reality? What address is it mapped at anyway? I can't find any information about this in the README...
Extending the memory commands to take a prefix specifying which address space you're talking about would make a lot more sense, though. Then it might make sense to use 64-bit offsets too since we're not really talking about the CPU's address space anymore, although it could be difficult to support offsets of different size with a single command.
Maybe it would be better to create a different set of commands for manipulating any kind of raw storage (including flash) and let the memory commands deal with memory.
MMC/SD/USB Memories have the advantage of beeing able to be read/written by the host, and this advantage makes it more natural to use a real file system.
Exactly. It's just absurd to pretend removable storage devices reside in physical memory.
Haavard