Dear Mike Frysinger, In message <[email protected]> you 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. > 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 ;-) > > 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. > 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. 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: [email protected] In general, if you think something isn't in Perl, try it out, because it usually is :-) - Larry Wall in <[email protected]> _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
