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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot