From owner-freebsd-arm@freebsd.org Fri Sep 9 15:31:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26CCCBD4AC2 for ; Fri, 9 Sep 2016 15:31:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC86E336 for ; Fri, 9 Sep 2016 15:31:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id i184so19783006itf.1 for ; Fri, 09 Sep 2016 08:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=ZyM28L9drY5SnbgNzm+BZZe2iqMz5rPA57/5i8rUgSA=; b=BuL5cTWNMbPKDoHVhSZj6CDHIkDChqql9JbMDk2nk/K6nOPsytK3IsLm6kUKUM+tFp lx7Z1EFuD3fNNPEW3c7LRIPZaz7R+fii0msgJYniTTzqRE420D+46OFnrn5KIrKMmPiE 0MsOw2uqcCimDUt5k8zF1GtBhCxOID2NE5UHrKubuXJWkLBDjSSePjPWV2km0n0D3dkN fdHmuEx20j4nv9LBtEVR3J1+/02GM5VRhNiySIjOix8sIu5UhXlsQrk5dsQCRH/B7T6j qsxu9ueR9yNNcUGEgklbgR68f03LDB5yUAr9i0n1Waw0EVWltMMm5B0FcYmwgdxFLyw0 UhLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=ZyM28L9drY5SnbgNzm+BZZe2iqMz5rPA57/5i8rUgSA=; b=Z+Jil+fdvsgyus82Z0DbFfiOHu0uq8R9qzhso/5zDyVlTqRGaI7uZKrVFm3bu8SSrN qp9DkXoFckfpFG2A6kB0eQdHJs01oEr+bjf6Xj8VXgtoESDvUEXMiRxxu1fSSQrztvFJ Nj9h0IoImFKJ3hxgNrzSyCb88layvoApVp7hexyQbHnCpj2s4EOEeHJFZHG5lV7WbZq5 VhehcM77Xv6fPknrq5ZEISB/99tN5ggyU8Dy3Epf3y04PhPDfcNb/stQ2Ppe1sdGr6Qj S+AubzRh5ZfUnIRkKUVARnyKCRgBkucpTdFhsazILpZMHSyEMgnyNhedXoPObk71Etn9 MkPA== X-Gm-Message-State: AE9vXwNSaAUZ8BK+tgH1N2VL5VDoqIMrIfZTdBpe+fwnwmml2/GyIw3MDGJgXZhj9R/RlsSxEWbgJ5yAvVY2zg== X-Received: by 10.157.2.10 with SMTP id 10mr5287859otb.11.1473435117003; Fri, 09 Sep 2016 08:31:57 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Fri, 9 Sep 2016 08:31:56 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: From: Warner Losh Date: Fri, 9 Sep 2016 09:31:56 -0600 X-Google-Sender-Auth: O2nVnMJIPa5ltgr9KVpW2KOxOxw Message-ID: Subject: Re: Unaligned access in ubldr.bin To: Erik Moe Cc: =?UTF-8?Q?Micha=C5=82_Stanek?= , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 15:31:58 -0000 On Thu, Sep 8, 2016 at 5:23 PM, Erik Moe wrote: > > On Sep 7, 2016, at 8:22 AM, Warner Losh wrote: > > On Wed, Sep 7, 2016 at 12:46 AM, Erik Moe wrote: > > Hello, > > I=E2=80=99ve been trying to bring up FreeBSD on the USB Armory based on t= he i.MX53. > I=E2=80=99ve made myself a u-boot patch that will load and start ubldr.bi= n but I=E2=80=99m > running into a issue with what I think is an unaligned access issue: > > > which version of u-boot are you using? > > > I was using 2016.07, but also tried u-boot from head (b615267). When forward porting the u-boot in the ports tree, I noticed that 2016.05 w= orked w/o changing anything in ubldr and 2016.07 and head from a week ago both gave me unaligned accesses. Maybe you could try it as an experiment? Failed in exactly the same way on the two boards I tried it on (pandaboard and BBB= ). > ## Starting application at 0x70800000 ... > data abort > pc : [<70824bac>] lr : [<7081846c>] > sp : 8f550c98 ip : 70835a00 fp : 8f550cb0 > r10: 00000002 r9 : 70838d58 r8 : 70833cd9 > r7 : 707fff08 r6 : 000054f0 r5 : 70833cd9 r4 : 00000000 > r3 : 70828fc4 r2 : 70833cd9 r1 : 00000001 r0 : 7083705c > Flags: Nzcv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > I=E2=80=99ve hand dissambled the code at pc=3D0x70824bac: > > 0x70824ba8: 0xe59f21d0 ldr r2, [pc, #464] > 0x70824bac: 0xe5825000 str r5, [r2] > 0x70824bb0: 0xe5d53000 ldrb r3, [r5] > 0x70824bb4: 0xe353002d cmp r3, #45 > 0x70824bb8: 0x1a00000b bne #+44 > > The offending instructions is "str r5, [r2]=E2=80=9D where r2 =3D 0x70833= cd9, which > sort of makes sense since it isn=E2=80=99t aligned on a 4 byte boundary. = I=E2=80=99m new to > arm ARM, so I=E2=80=99m not really sure. My questions are these: > > 1.) Doesn=E2=80=99t ARMv6 and higher architecture allow unaligned access?= Is there > something that u-boot needs be doing in initialization to allow unaligned > access? > > > It does, but usually that's configured later in boot. > > 2.) Does ubldr make the assumption that unaligned access is allowed and > maybe shouldn=E2=80=99t? I would think not since ubldr has been around f= or a while > and works on numerous ARM processors. > > > It may be that the compiler is generating bad code in this case? You > might check to see how we're building it and to see if that's causing > problems. > > > Per Michal Stanek=E2=80=99s suggestion I tried adding "-mno-unaligned-acc= ess=E2=80=9D to the > build of ubldr. It=E2=80=99s still failing in getopt, though not it the= same spot: How about adding it to the ubldr build? IIRC, it should be default in FreeBSD's clang though. > ## Starting application at 0x70800000 ... > data abort > pc : [<70824bd0>] lr : [<70818454>] > sp : 8f559a78 ip : 70835a90 fp : 8f559a90 > r10: 00000002 r9 : 70838df0 r8 : 70833d73 > r7 : 707fff08 r6 : 00005530 r5 : 70833d73 r4 : 00000000 > r3 : 70828fe8 r2 : 70833d73 r1 : 00000001 r0 : 708370ec > Flags: Nzcv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > 0x70824bcc 0xe59f21d0 ldr r2, [pc, #464] > 0x70824bd0 0xe5825000 str r5, [r2] > 0x70824bd4 0xe5d53000 ldrb r3, [r5] > 0x70824bd8 0xe353002d cmp r3, #45 > > 70833d72: 00 61 3a 00 55 42 6f 6f 74 41 50 49 00 49 44 .a:.UBootAPI= .ID > > r2 contains 70833d73 which points to =E2=80=9C0x61 0x3a 0x00=E2=80=9D, wh= ich is the literal > string =E2=80=9Ca:=E2=80=9D. Looking at the lr register the calling func= tion is > =E2=80=9Capi_parse_cmdline_sig=E2=80=9D. Looking at the code: > > api_parse_cmdline_sig(int argc, char **argv, struct api_signature **sig) > { > unsigned long api_address; > int c; > > api_address =3D 0; > opterr =3D 0; > optreset =3D 1; > optind =3D 1; > > while ((c =3D getopt (argc, argv, "a:")) !=3D -1) > switch (c) { > case 'a': > api_address =3D strtoul(optarg, NULL, 16); > break; > default: > break; > } > > It=E2=80=99s the third argument to getopt that seems to be on an odd addr= ess. As > for the SCTLR.A bit being enabled, that is definitely something u-boot do= es, > because the default state is for it to be cleared after reset. I see thi= s > in arch/arm/cpu/armv7/start.S: > > /* > * disable MMU stuff and caches > */ > mrc p15, 0, r0, c1, c0, 0 > bic r0, r0, #0x00002000 @ clear bits 13 (--V-) > bic r0, r0, #0x00000007 @ clear bits 2:0 (-CAM) > orr r0, r0, #0x00000002 @ set bit 1 (--A-) Align > orr r0, r0, #0x00000800 @ set bit 11 (Z---) BTB > #ifdef CONFIG_SYS_ICACHE_OFF > bic r0, r0, #0x00001000 @ clear bit 12 (I) I-cache > #else > orr r0, r0, #0x00001000 @ set bit 12 (I) I-cache > #endif > mcr p15, 0, r0, c1, c0, 0 > > I tried to clear that flag, but that didn=E2=80=99t work either, but I=E2= =80=99m not sure if > this is correct: > > mac p15, 0, r0, c1, c0, 0 > bic r0, r0, #0x00000002 > mar p15, 0, r0, c1, c0, 0 That looks like it should do the right thing. You could just remove the orr line that ors in bit 1 too. Have you tried that? Warner