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

[Becky Bruce]

On Aug 31, 2009, at 6:57 AM, Wolfgang Denk 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?

Sorry, guys, I'm still not clear on what's going on. Haavard, did you  
expect each call to flash_map to return a different VA each time (i.e.  
you're trying to do some sort of dynamic mapping), or are you just  
calling it to get the VA that corresponds to some PA, since VA != PA  
on these 2 boards?


>
>>> 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...

The problem is that would mean the CFI driver would be treating start  
as a PA, while every other flash driver that I looked at treats it as  
a VA.  That kind of inconsistency would be bad. Plus, Wolfgang,  
Stefan, Kumar, and I discussed this on the list/IRC last november and  
agreed that it made sense for command-line foo (including the flash  
commands)  to take a virtual address as the argument.  Platforms that  
have a non-fixed memory map would need to provide a command-line  
interface to get a VA to use (since that's highly unusual and expected  
to remain so).

>
>
>> 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 ;-)

Well, u-boot was supposed to be simple, and a VA=PA assumption ended  
up built into a lot of the code.  Which isn't a problem until you need  
something different....  I had a lot of fun standing on my head trying  
to get 36-bit physical addressing on PowerPC working as a result of  
this.   I suspect the next big u-boot problem will be the need for  
dynamic mappings, because we're assuming for the most part now that  
the board memory map is static.

>
>
> 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.]

SGTM.  But then, it isn't my board that's broken..... We do need a  
solution here, but I think we have time to work it out.

Cheers,
Becky

>
> 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.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot