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