[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