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? > > 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). > 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. > But exactly what's wrong with hiding all this complexity inside > map_physmem()? It was designed _exactly_ for this purpose -- to allow > platforms with non-trivial mappings between VA and PA to do the > necessary mapping when the driver requests it. Sorry, I don't know that code and it's users well enough to coment. Maybe Becky and/or Stefan can shed some light on this... > 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 ;-) 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.] 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 1st Old Man: Gee, its windy today. 2nd Old Man: No it's not... it's Thursday. 3rd Old Man: Yeh, me too. Let's go for a beer. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
