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

[Beniamino Galvani <b.galvani@gmail.com>]

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.

> > 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