Dear Mike Frysinger,
In message 200907051312.25031.vapier@gentoo.org you wrote:
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.
You are missing the point that we are talking about flash _memory_ here, which is accessed using an address in the CPU's address space. If you have N banks of flash _memory_, each of these banks must be assigned it's own, unique region in the CPU's address space.
What you are talking about is not flash _memory_ but a flash based storage _device_.
Memory is required to be directly adressable from the CPU; if you need to perform additional operations like toggeling GPIO pins to map the required bank in, this probably needs memory controller support. At least I cannot think of another solution.
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.
What you describe is a storage device, not much different from NAND flash or any other storage device.
If you had an implementation that supported 4 MiB of flash memory mapped at 0x20000000, then this flash memory would be accessable by driving the address lines to any address in the 0x20000000 ... 0x203FFFFF range. The fact that you need a driver (MTD) even to read the device is a clear indication that it is not memory.
Let me give you a different example - for flash memory it is possible to manually perform for example a sector erase by doing something like
mw.b 20200AAA AA mw.b 20200555 55 mw.b 20200AAA 80 mw.b 20200AAA AA mw.b 20200555 55
or similar - I guess this will not work as expected in your case, becuase what you implement is not a memory interface, but a storage device.
Please note that I do not say that support for such a configuration is not useful - it definitely _is_ useful. But then be honest to yourself and don't try to disguise this as memory - as suggested by you, it is a storage device, and I will not accept attempts to access storage devices of any kinds through a memory interface.
Please see the archive, we had similar discussions several times a long time ago. Ulf can tell you a thing or two about it. For me one important decision criterion is whether I can do the same actions in U-Boot and in a JTAG debugger; in your case, running "md 0x201FFF80" in U-Boot and at the BDI3000's telnet prompt would NOT show the very same results, which they have to if there is memory mapped at these addresses.
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
Gotcha. This is not the characteristics of memory, but a storage device. Use a storage device driver for such a setup.
Best regards,
Wolfgang Denk