Wolfgang Denk <w...@denx.de> wrote: > Dear Haavard Skinnemoen, > > In message <20090830224218.10f14...@siona> you wrote: > > > > > Well, VA==PA is the default setting for U-Boot that shall be used for > > > all systems, unless it is really impossible on a board to implement an > > > exception from that rule. > > > > While not impossible, following that rule on the NGW100 would require > > that I either disable the caches (which would result in a massive > > slowdown) or start using the MMU more actively to get the caching > > properties right. > > OK, so this would be the plan for a clean fix, then?
Possibly. But it means even more effort and even larger code, so I'm not exactly happy about it. > > > In almost all cases RAM and NOR flash fit easily in the physical > > > address space of the CPUs, and for the sake of this majority of > > > systems it must be possible to access memory on such systems assuming > > > a simple 1:1 mapping. > > > > You're ignoring cache issues. > > Indeed I am, and intentionally, because this is a different topic. If > your system requires to set up the MMU to enable caching, then you > are supposed to do it in a way compatible with the rest of the > software design, i. e. as transparently as possible. None of the > architectures I know resonably well have problems setting up a 1: 1 > address mapping even when the MMU is on (but I have to admit that > AVR32 is not among these architectures). I suspect quite a few other architectures run with caches disabled because it's not safe to run with caches enabled with the current software design. > > Technically, the addresses seen by the CPU are virtual. And I don't > > think systems with a cache should be considered 'very special' these > > days... > > Cache should not be relevant at all when defining a physcal or > virtual memory map. Physical, no, but it's very common that the MMU defines caching properties (enabled/disabled, writeback/writethrough, etc.) > > That PA==VA rule is pretty much the reason we're in this mess -- if > > Let's say, the fact that this rule has not been stricter enforced has > caused that teh appearant problems were not discovered earlier. > > > more platforms had broken this rule, perhaps more of the code would > > Heh. If more platforms had broken this rule we would probably have > become aware of these violations earlier, and stopped them doing such > naughty things ;-) Seems like you think it's more important to follow arbitrary rules than writing code that works well. > As it seems, this requires some more discussion, i. e. a clean fix > within the next couple of days is unlikely. To me that means that it > makes no sense to offer to delay the release of v2009.08 by a week or > so, as we'd still not be ready then. I will therefore proceed as > planned, putting up with the fact that some (two, IIRC?) AVR32 boards > are broken in this release. [we had a very long testing phase, and the > problem is not exactly new, so it should have been detected (and > fixed) long before.] Yes, I agree. Haavard _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
