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

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907051503.44391.vapier at gentoo.org> you wrote:
>
> > 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.

Yes, it does. These GPIO lines are not part of the CPU's address
signals. If the CPU attempts to fetch data from 0x20300000 it will not
see the expected data from the midle of the second bank.

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

Agreed. That's the current status quo. There are for example a number
of MPC5200 systems that can access  (in  U-Boot)  only  half  of  the
physically available flash memory because of this.

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

I appreciate this.

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

See for example these threads:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26014
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27363/focus=27372
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/28528/focus=28754

and so on. Or search for "storage device" & "flash memory" :-)

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

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

Sounds like a plan.

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
If the odds are a million to one against something occuring,  chances
are 50-50 it will.