On Sep 2, 2009, at 2:59 AM, Wolfgang Denk wrote: > Dear "J. William Campbell", > > In message <4a9d99b1.1010...@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: w...@denx.de > Conscious is when you are aware of something, and conscience is when > you wish you weren't. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot