[U-Boot] [PATCH 12/16] efi_loader: Add DCACHE_OFF support for arm64

Alexander Graf agraf at suse.de
Tue Feb 2 17:58:41 CET 2016



> Am 02.02.2016 um 18:28 schrieb Tom Rini <trini at 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



More information about the U-Boot mailing list