Dear Haavard Skinnemoen,
In message 20090901134257.59961e79@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