[U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090830224218.10f14dc4 at 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: wd at 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.