[U-Boot] [PATCH v3 2/2] arm: add initial support for Amlogic Meson and ODROID-C2

[Alexander Graf <agraf@suse.de>]

On 14.04.16 01:12, Marek Vasut wrote:
> On 04/14/2016 12:53 AM, Alexander Graf wrote:
>>
>>
>> On 14.04.16 00:51, Tom Rini wrote:
>>> On Thu, Apr 14, 2016 at 12:42:41AM +0200, Alexander Graf wrote:
>>>>
>>>>
>>>> On 14.04.16 00:34, Tom Rini wrote:
>>>>> On Wed, Apr 13, 2016 at 11:38:51PM +0200, Alexander Graf wrote:
>>>>>> On 13.04.16 13:52, Marek Vasut wrote:
>>>>>>> On 04/13/2016 01:22 PM, Beniamino Galvani wrote:
>>>>>>>> On Wed, Apr 13, 2016 at 12:26:43AM +0200, Marek Vasut wrote:
>>>>>>>>>> So, after some investigation, the reason is that the code runs when
>>>>>>>>>> caches are still disabled and thus all the memory is treated as
>>>>>>>>>> Device-nGnRnE, requiring aligned accesses.
>>>>>>>>>
>>>>>>>>> You mean 8-byte aligned accesses, correct ?
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>>> The return value of
>>>>>>>>>> fdt_getprop() is guaranteed to be aligned to a 4 byte boundary (but
>>>>>>>>>> not 8)
>>>>>>>>>
>>>>>>>>> The return value of fdt_getprop() is a pointer, thus 8byte long on
>>>>>>>>> aarch64 and thus aligned to 8 bytes on the stack unless there is
>>>>>>>>> some real problem.
>>>>>>>>
>>>>>>>> Right, however I'm not talking about the alignment of the pointer on
>>>>>>>> the stack, but about the value of the pointer, which depends on the
>>>>>>>> offset inside the device tree blob of the property. If I use this:
>>>>>>>>
>>>>>>>>     val = fdt_getprop(gd->fdt_blob, offset, "reg", &len)
>>>>>>>>     gd->ram_size = fdt64_to_cpu(*(fdt64_t *)val)
>>>>>>>>
>>>>>>>> when the CPU tries to dereference val (which is something like
>>>>>>>> 0x00000000010429e4) an alignment fault is generated for the reason
>>>>>>>> stated above.
>>>>>>>
>>>>>>> Oh, now it's clear what the problem is, thanks. But then, we'd need such
>>>>>>> fixups all over the place I'm afraid. Isn't there some way to enable
>>>>>>> support for "unaligned" accesses instead?
>>>>>>
>>>>>> Yes, and it's called "enable the MMU". You could probably do this in the
>>>>>> early dram init stage already, but I'm not sure it's worth it. The NXP
>>>>>> people are the only ones doing it really early today FWIW.
>>>>>>
>>>>>> Also, if you find it more readable, you could just use
>>>>>> get_unaligned_be64(). It gets you down to byte accesses rather than
>>>>>> 32bit fetches, but the function name makes it pretty obvious what we're
>>>>>> looking at.
>>>>>
>>>>> OK, now I'm starting to get nightmares back to our last unaligned access
>>>>> discussion.  Is ARMv8 doing something radically different from ARMv7
>>>>> here, wrt unaligned accesses?
>>>>
>>>> No, it does the same. To handle not naturally memory accesses you need
>>>> to have dcache enabled and to enable the dcache the MMU needs to be
>>>> turned on. ARMv7 is the same for all I'm aware of.
>>>
>>> Ah, OK, so we just need to get the MMU on for ARMv8, and that's more
>>> complex?  Or am I just flat out missing something?
>>>
>>
>> It's not terribly complex, but the code in question runs in very early
>> init (it initializes dram). I guess people usually like their caches off
>> that early.
> 
> Caches and MMU are two orthogonal things though.

The way I understood this is that the default cachability of non MMU
mapped pages is Device-nGnRnE. To have anything marked as cached, the
only chance you have is to set the caching mode in the page table. So
enabling the MMU is a requirement to get data accessed via the dcache
which is a requirement to allow unaligned accesses.


Alex