Am 02.02.2016 um 18:28 schrieb Tom Rini trini@konsulko.com:
On Tue, Feb 02, 2016 at 03:55:17PM +0000, Mark Rutland wrote:
On Tue, Feb 02, 2016 at 03:45:10AM +0100, Alexander Graf wrote: On arm64, boards can declare that they want to run with dcache disabled.
However, uEFI guarantees to payloads that they're running with the dcache enabled which on arm64 means that they can do unaligned accesses.
To not leave those systems out of the door, let's handle the unaligned traps. In the typical boot case, the OS will set up page tables and dcache itself early on anyway once it's done talking with uEFI.
This is not sufficient to emulate having caches enabled.
There are other things which operate differently with the caches on (e.g. exclusives and/or atomics, which a compiler might generate implicitly).
Likewise, cache-maintenance by Va (which you may require from the I-side) implicitly hazards against cacheable accesses, but not against non-cacheable accesses.
There are almsot certainly other differences.
Due to that, I don't think this is a good approach.
Why can we not map memory using cacheable attributes in all cases?
I have a simpiler question perhaps, why can we not just say that this support (in Kconfig that is) depends on !SYS_DACHE_OFF ? Yes, only ARC as moved that symbol over to Kconfig but that's a relatively easy thing to remedy. I assume that it being off on some systems is more of a debug / bringup thing that needs to be circled back to rather than a good hard requirement of the platform.
How about we just remove cache disabled mode for AArch64? I really don't understand why it's there in the first place.
Alex