From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 14 Apr 2016 01:12:28 +0200 Subject: [U-Boot] [PATCH v3 2/2] arm: add initial support for Amlogic Meson and ODROID-C2 In-Reply-To: <570ECDE5.8040304@suse.de> References: <570AEB18.5010901@denx.de> <20160411210211.GB22294@gmail.com> <570C1232.1070908@denx.de> <20160412214945.GA3006@gmail.com> <570D7623.8020603@denx.de> <20160413112210.GA5798@gmail.com> <570E3312.3020702@denx.de> <570EBC6B.3020507@suse.de> <20160413223457.GP13577@bill-the-cat> <570ECB61.5050604@suse.de> <20160413225127.GR13577@bill-the-cat> <570ECDE5.8040304@suse.de> Message-ID: <570ED25C.60505@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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