[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

Mike Frysinger
2009-07-05T17:12:23Z

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090705/2ae8d0f1/attachment.pgp