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

[Marek Vasut <marex@denx.de>]

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?

>>> and therefore a 32-bit type must be used to avoid alignment
>>> faults. Probably the comment should be updated to explain this better.
>>
>> Take a look at what uniphier does : arch/arm/mach-uniphier/dram_init.c
>> Does that approach with fdt64_t work for you?
> 
> Nope, that's the first thing I've tried :(
> 
> Beniamino
> 


-- 
Best regards,
Marek Vasut