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

[Becky Bruce]

On Sep 2, 2009, at 2:59 AM, Wolfgang Denk wrote:

> Dear "J. William Campbell",
>
> In message <4A9D99B1.1010707 at comcast.net> you wrote:
>>
> ...
>>> Becky then posted the summary of this discussion here:
>>>
>>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/50705
> ...
>> In quick summary, for the next few years, we will require that all
>> "important" physical addresses have corresponding virtual addresses.
>
> ...unless there are good reasons to deviate from that rule, but these
> cases are expected to be rare exceptions from the rule.
>
>
>>> In any case, I think we should be careful not to mix things: what   
>>> we
>>> are  discussing here are address mappings. What we are not  
>>> discussing
>>> is specific memory properties like  being  cached/uncached,   
>>> guarded/
>>> non-guarded, etc.
>>>
>>> Such properties are important, too, but  they  need  to  get   
>>> handled
>>> through a separate interface.
>>>
>> Here is where I am quite sure you are going to have a problem. In  
>> very
>> many CPUs, cache control and memory management are joined at the hip.
>> Some systems have no easy way to enable and disable (D,I) cache
>> globally, it is only doable on a page or segment basis. The PPC  
>> hardware
>> has a relatively low cost way to do so, but not all architectures do.
>
> I am well aware of this problem, which is one of the reasons that the
> majority of systems is running  with  data  cache  turned  off.  Even
> PowerPC  has  DC off (at least after relocation to RAM), ARM does not
> implement cache support yet, etc.
>
> When we state that U-Boot is a boot loader and thus  should  be  kept
> simple,  this  more or less logically results in the consequence that
> if it's difficult to enable the DC (on some systems), then just don't
> do it, then.
>
> Nobody enforces you to enable caches when you find it hard to do.
>
>
>> Very True. I did forget about the read being just a memory  
>> reference. So
>> if we desire the flash to be cached, it would have to "normally" be
>> cached for reads to take advantage of the operation.
>
> ACK.
>
>> Thanks for looking at this. It therefore seems to me that adding an
>> "uncache(virtual address)" operation (that may return a substitute
>> address for the actual write to the flash) followed by a
>> "restore_cache()" operation inside the flash driver write routine  
>> should
>> work. The uncache routine would do nothing if the flash is not  
>> cached to
>
> 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.
>
>> begin with, would globally turn off data cache if that is easy to  
>> do, or
>> would provide an alternate virtual address to be used in the write.  
>> That
>
> This is where I disagree.
>
> I'm not really deep enough in the implementation details and thus
> would appreciate comments for example from Becky and Stefan. In my
> opinion, turning on or off the cache on an address range should be
> implemented as outlined above, i. e. as an operation changing the
> caching properties of the address range.

This makes sense to me.  The disable function would need to flush the  
range from the cache, but that's the only difficulty I forsee.   
However, I dug up some AVR32 docs, and it looks like the whole dual  
cacheable/CI mapping thing may be architectural.  The architecture  
seems to specify a virtual memory map for privileged state, and part  
of the VA range is not translated by the MMU, but has a default  
translation.  There appear to be segments in the untranslated VA space  
that map to the same PA, one cacheable and the other not.

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

Cheers,
Becky


>
> Becky, Stefan: please comment...
>
>
> 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
> Conscious is when you are aware of something, and conscience is  when
> you wish you weren't.