Dear Haavard Skinnemoen, In message <20090901134257.59961...@hskinnemoen-d830> you wrote: > > > > complexity (which can be kept to a minimum) localized to a handful of > > > drivers, and don't change the command line interface or the board > > > configuration interface. > > > > We're not doing this. At least not intentionally. > > Good. Then let's please put a stop to the madness of exposing virtual > addresses all over the place.
But that's what we've been doing all the time. You just did not notice it because of the usual 1:1 mapping. On a 32 bit system with 36 bit physical addresses you cannot use a physical address when running the "md" command, for example. we always assumed that the 32 bit VA we used matched 1:1 to a PA with the missing high bits set to 0, right? > > The discussion we had was based on our knowledge about existing > > systems, and needs to also handle more complex situations like for > > example 32 bit systems with 36 bit physical addresses. > > As far as I understand, the only difference for such systems is that > keeping 64-bit physical addresses around are a bit more costly than > passing around 32-bit virtual pointers. But presumably those systems > have enough memory to make it a non-issue... That's not true. There are 32 bit systems with bigger physical address spaces. And note that this is not a new thing. We have been doing this allt he time - just without ever explicitly mentioning it, because so far nobody ever complained about it. > > Agreed - assuming it is possible without hurting the majority of > > other existing configurations. > > Yes, that is indeed possible, as evidenced by the fact that it used to > work without hurting any other configurations. It took another "special > case" to break it. My understanding is that the special case is yours - using a non-1:1 mapping. > > discussions with Stefan Roese and Detlev Zundel it seems to me that > > map_physmem() is probably not the right approach (judging only from > > the name). We should not try to fix cache attributes by modifying > > addresses / address maps > > And why not? That's what Linux does, and it works wonderfully across 26 > different architectures. We do not want to implement a full-fledged OS with virtual memory and on-demand paging and all that stuff in U-Boot. > > Instead, we should really extend the CFI driver such that it does not > > matter if the addresses you are passing refer to cached or uncached > > memory, and then provide hooks in the CFI driver to allow for testing > > if cache is enabled, and switching cache off if it is. > > What's the advantage of such an approach? It sounds much more > complicated from the driver's point of view as well. The advantage is that other drivers with similar needs can use it as well. > > To me such an approach makes much more sense, as it is generic and > > can be used by other drivers and other architectures - even if it may > > come at the cost of more effort on your systems. > > In what way is it more generic? In what way can map/unmap_physmem() not > be used with other drivers and architectures? On other architectures it is not possible to map the same memory area multiple times with different attributes. Remapping addresses thus cannot help - you really have to switch the MMO resp. memory controller setinngs to turn data cache on or off. > > Well, but board/atmel/atstk1000/flash.c _is_ a proprietary driver for > > some flash chips that seem to be CFI conformant at first glance. You > > would not get such a driver into mailine any more. > > So I guess dropping support for ATNGW100 is the only remaining option? No, why? We're discussing ways to fix the problems, aren;t we? > At least STK1000 has a working flash driver. Only because it was added so long ago, before we were more consequent about using the generic driver. It would be a good idea to clean up this board support, remove the proprietary flash driver and use the CFI driver instead. Patches are welcome. 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: w...@denx.de I will also, for an appropriate fee, certify that your keyboard is object-oriented, and that the bits on your hard disk are template- compatible. - Jeffrey S. Haemer in <411akr$...@cygnus.com> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
