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

Becky Bruce
2009-08-31T20:05:10Z

On Aug 31, 2009, at 6:57 AM, Wolfgang Denk wrote:

> Dear Haavard Skinnemoen,
>
> In message <20090830224218.10f14dc4@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