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

[Mike Frysinger <vapier@gentoo.org>]

On Sunday 05 July 2009 13:55:13 Wolfgang Denk wrote:
> Mike Frysinger 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_.

i dont see much point in distinguishing the two, but i understand what you're 
going for now

> 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.

i dont really know what you mean.  in my gpio flash example, there is 
literally no other software or hardware changes necessary.  the fact that one 
or two address lines is handled by GPIOs makes no difference at all to the 
rest of the hardware.

> 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.

the lower two megs that are physically mapped are fully usable today without 
any changes.  in other words, if i configured the board to lie and treat it as 
a 2 meg CFI flash at 0x20000000, it'd work the same way as any other CFI flash 
device.  all the commands you refer to work fine.

> 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.

my purpose is clear -- to maximize device support with as little 
changes/overhead as possible and get merged into mainline.

> Please see the archive, we had similar discussions  several  times  a
> long  time  ago. Ulf can tell you a thing or two about it.

i'll try searching ... any keywords to look for ?

> 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.

u-boot and jtag would always show the exact same results in this case.  they 
just may not do what you expect them.  i.e. if the GPIO line is high, then 
reading 0x20000000 - 0x20200000 will access the top half of the flash, not the 
bottom half.

> > 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.

i dont mind creating a dedicated command like "fl" that would act like "sf" in 
terms of reading/writing/erasing, but it still must be able to leverage the 
CFI code which means using the weak GPIO accessor functions.
-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/34ad569c/attachment-0001.pgp