[U-Boot] Virtual addresses, u-boot, and the MMU

[Mark Jackson <mpfj-list@mimc.co.uk>]

Becky Bruce wrote:

<snip>

>> This is where Detlev's comment about using the chance to define a
>> cache API comes into play.
>>
>> Yes, we probably should create a set of functions like
>>
>>     enable_data_cache(address, size);
>> and
>>     disable_data_cache(address, size);
>>
>> which would turn on resp. off the caching attributes on the given
>> memory range.

<snip>

>> Using a completely different address range instead is a different
>> thing, and not what I have in mind. I really dislike the idea of
>> supporting "alternate addresses" in this context - even if this is
>> what would be easiest to implement on some architectures.
> 
> I agree, but, then, I'm coming from an architecture where doing this is
> bad joo-joo.  Again, it looks like AVR may actually need this -
> hopefully someone who knows more about AVR will speak up here.

Although I wouldn't consider myself an AVR32 "expert", I am following
this thread closely.  It seems to me that the above 2 functions could be
used to support Detlev's idea as well as Haavard's map_physmem() idea.

The functions could also return (architecture dependant) a "remapped"
address to be used, then we could support:-

(1) AVR32-type cache which is based on different address ranges

Here the xxx_data_cache() functions would flush the cache, and return
a new address that points to the relevant cached / uncached section of
memory.

(2) Platforms with "single address" ranges but finer cache control

These would flush the cache, adjust the caching for the memory range as
required, and then just return the *same* address (since no address
re-mapping is required).

The functions using xxx_data_cache() would then code up as follows:-

void foo(address, size) {
	uncached_address = disable_data_cache(address, size);
	/*
	 * ... do some code using only uncached_address ...
	 */
	cached_address = enable_data_cache(address, size);
}

Regards
Mark