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

[Haavard Skinnemoen]

Wolfgang Denk <wd at denx.de> wrote:
> 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?

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