On Sunday 05 July 2009 11:15:42 Wolfgang Denk wrote:
Mike Frysinger wrote:
The current flash framework generally assumes that the flash in question is completely directly addressable. With the new weak accessor functions, that is no longer always the case. These allow us to hook up flashes whose pins are only partially directly addressable while the rest are connected to GPIOs. Since all the erase/write commands go through the
Either you or me misunderstand the purpose of these weak accessor functions.
the original purpose of the weak accessor functions did not include this functionality, but there was no way previously to do this -- transparently access parallel flashes that do not have all address lines hooked up to the normal address bus.
You cannot do it transparently with these functions either. Simple memory accesses like "cp", "md", "mm" etc. will still not be available. Reading or writing an image to a partition that crosses banks is not available. Accessing files from a file system that crosses banks does not work. And so on.
erasing/writing does work transparently as the CFI layer grabs the addresses before they're put onto the bus, and the weak accessors do the setup. same goes for file system commands.
i see the functions being useful in the same way we have mtd mapping drivers under Linux.
They _would_ be useful if they could be used like in Linux, but this requires at least a memory controller setup that traps of accesses to certain address ranges - but we don't have virtual memory or the linke in U-Boot. At least not yet ;-)
the mapping drivers dont have any direct dependency on the memory controller in any way. the input to the mapping driver is the mtd and desired offset to access. here you can do any crazy magic you want, including but not limited to, memory controller tricks. in the case of gpio flashes, the gpio pins are taken from the address and the real address is accessed.
Either we have flash memory; then it is a mandatory requirent that we can access the flash memory using all memory accessing commands, including "cp", "md" etc. This is not the case on any devices that require additional address switching, like on processors that use things like bank switching signals in addition to the normal address lines.
Otherwise we have some form of storage device, which cannot be accessed with commands like "cp", "md", or "erase".
yes, the current flash subsystem is limited in this area. it lacks something akin to the Linux mtd mapping drivers. but this is something to be fixed, not something to say "well that hardware doesnt make sense and anyone who wants to do that is not supported". saying "no" to flread is one thing, but saying no to the entire idea of supporting these types of devices is wrong imo.
I did not say that. I just NAKed the flread patch.
OK
previously these boards had to replicate the CFI drivers entirely just to do the bank switching. the weak accessor functions means now they need all of ~50 lines of board specific code and they can use all of the common CFI code for free.
Use it for what? See above - none of the frequently used commands to access flash memory is working as is. Yes, you can hack a set of new commands - flread, flwrite, flcopy, flmd and whatever you like. But don't expect these to do into mainline.
but they do work because of how the flash subsystem interacts with the rest of the system. it just may inadvertently overlay other things in the physical memory map if it follows too closely to the flash.
as an actual example, the cm-bf537e has a 4 meg flash hooked up to 0x20000000 but the highest address line is handled with a GPIO (meaning 2 megs is physically mapped). using the weak accessor functions, the GPIO is toggled transparently and the address in question is munged such that it stays in the 2 meg boundary. that means the CFI layer sees: flash 0: 0x20000000 + 0x400000 so any access from the command line between 0x20000000 and 0x20400000 that requires assistance from the CFI layer goes through the accessor functions. that means erasing/writing as well as filesystem accesses. since the read command is the only one to not do checking of the flash_info structure, we need the dedicated flread command.
the downside here is that anything between 0x20200000 and 0x20400000 is not actually physically mapped to the flash device, but any flash related command will think it is. so it'd be a problem if you tried to hook up two flashes back to back. that hasnt been a use case that ive seen thus far. after all, it's generally cheaper to buy a larger memory than to try and buy two smaller ones as is connecting/testing/etc... -mike