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

[Mike Frysinger]

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