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

[Marek Vasut <marex@denx.de>]

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.


-- 
Best regards,
Marek Vasut