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

[J. William Campbell]

Becky Bruce wrote:
>
> 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.
Unfortunately, more than one architecture that has  problems turning off 
cache in an arbitrary region of memory. If a system has a "global" cache 
disable, that would be the easiest option. Since u-boot is single 
threaded, we don't have to worry about the cache not being turned back 
on because we lost control of the CPU. Alternatively, one could change 
the cache enable bits in an appropriate "BAT" if such a thing exists, 
and then change them back. However, I think you have to be open to the 
idea of an "alternate address", as that may be the easiest way to go on 
many systems, and possibly the only way to go on others. In any case, 
Becky is quite correct in pointing out that flushing the cache for the 
appropriate VAs is necessary if you alter the contents of memory region 
that were previously cached.
>
>>
>> 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 understand what you are saying here Wolfgang. However, I would plead 
the following possible mitigating circumstances make this "not so bad". 
First, the rule will be that the usage will be very local, inside at 
most say 100 lines of C code, just enough to do the "I/O" access 
required to the memory block. Look at it as a "write_be32_array"  I/O 
accessor function. Second, when you have a situation where the 
sizeof(PA) > sizeof(VA), you are eventually going to require mappings 
inside of drivers in order to reach things that are not statically 
mapped in, both for reading and writing, independent of caching issues. 
The VA used to access the device will be "temporary". I know that this 
issue is being postponed a bit, but it will arise sooner than one hopes. 
Thinking about the problem now and establishing what is and is not 
necessary/permitted may result in an easier time of it later. (Speaking 
as an old PDP-11 programmer, KISAR6 will become your friend even in the 
boot loader!)

Best Regards,
Bill Campbell
> 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.
>
>
>