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

[Wolfgang Denk <wd@denx.de>]

Dear "J. William Campbell",

In message <4A9D99B1.1010707@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.

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.

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.