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

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907051312.25031.vapier at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There's an old story about the person who wished his computer were as
easy to use as his telephone. That wish has come  true,  since  I  no
longer know how to use my telephone.