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

Mike Frysinger vapier at gentoo.org
Sun Jul 5 05:07:26 CEST 2009


On Saturday 04 July 2009 19:39:45 Wolfgang Denk wrote:
> In message Mike Frysinger wrote:
> > From: Harald Krapfenbauer <Harald.Krapfenbauer at bluetechnix.at>
> >
> > 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.

i see the functions being useful in the same way we have mtd mapping drivers 
under Linux.

> > weak accessor functions, those work transparently.  But for reading from
> > the flash, the common memory function is still used and this does not go
> > through the weak accessor functions.  So we need a dedicated command to
> > make sure the weak accessor functions are used to do the actual reading.
>
> Nope. This ain't working.
>
> 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.

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.
-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/20090704/c5596014/attachment.pgp 


More information about the U-Boot mailing list