Haavard Skinnemoen skrev:
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...
I have not seen a single customer complain about the fact that a serial flash is memory mapped. The customers are informed about the memory map of the board in the board documentation. If the interface is changed, then this board documentation will have to change.
Alternatively the board documentation will have to document two different command sets for handling dataflash, depending on which version of u-boot is on the board. I am convinced that this is going to cause all sorts of confusion at the customers.
This simple point is key to why I think that the interface to the dataflash should remain as it is.
If the internal implementation changes to something more maintainable I do not have a problem with that, as long as it is tested. I do have a problem with the approach: "let's change the interface, and leave the debugging to someone who cares about whether it works or not".
I know that Atmel's AT91 department does not want to spend any time on U-Boot right now so who will test the fixes for dataflash?
Extending the memory commands to take a prefix specifying which address space you're talking about would make a lot more sense, though.
If you only see dataflash as an extra storage device then you might have a point, in my world it is quite often the only device and I do not see any need to have any prefix.
Computers are good at computation and humans does not like typing. I am sure that noone wants to have a prefix for accessing their normal parallell flash memory and I think anyone that do not want to have such a prefix, should have respect for those that do not want to have a prefix for accessing their only (serial) flash.
On the memory map: I think this is up to the implementor. In AT91 U-Boot AT45/dataflash drivers you have the following mapping : * chip select 0 maps to 0xC000_0000 * chip select 1 maps to 0xD000_0000
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
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users