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

[Alexander Graf]

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.


Alex