> Am 02.02.2016 um 18:28 schrieb Tom Rini <tr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
