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

[Haavard Skinnemoen]

Becky Bruce <becky.bruce at freescale.com> wrote:
> > 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.

Yes, that is correct. As Andrew pointed out, MIPS does essentially the
same thing, and I _think_ some versions of SH have a similar setup as
well. This makes it easy to set up uncached access on certain physical
addresses without wasting any TLB entries.

On the other hand, turning off the cache entirely is a quite
complicated operation which involves accessing the memory-mapped dcache
tag memory and marking everything as allocated and invalid. So I'd
rather not do that, especially when there's a much easier way.

Another alternative is to enable paging, which will allow fine-grained
control over caching properties. It's probably not all that difficult
to do, but it just seems so _pointless_.

Also, what I don't get is that your architecture _also_ needs to remap
physical to virtual addresses, but for a different reason, so what is
wrong with having an API that can do both?

In other words, the map_physmem() API can support the following three
classes of architectures:
  - Architectures which don't need address remapping but do need to
    change caching properties: Just update the caching properties and
    return the physical address unchanged.
  - Architectures like AVR32 which change caching properties through
    the MMU: Return a new virtual address with the desired properties.
  - Architectures with PA>VA: Update the caching properties if
    necessary and return a temporary virtual address corresponding to
    the given physical address, allowing the entire physical address
    range of the CPU to be made available to drivers utilizing this API.

What is wrong with this API? Why are everyone so hell-bent on making it
difficult for the last two classes of architectures? Did I get any or
all of the scenarios above wrong?

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

I've said what I intend to say about this. I find it really hard to
argue about "opinions" which are not backed by facts. The "alternate
addresses" are there whether we decide use them or not, but not using
them makes what should be a trivial operation really hard to do.

Oh, and I'm really sorry about the tone I used a couple of days ago. I
deliberately stopped posting for a few days after that...but I'm hoping
we can all continue working towards a solution now.

Btw, I do have a few suggestions on how to resolve this, but I'm not
going to come forward with them as long as I'm being stonewalled on the
VA/PA mapping issue.

Haavard