From owner-freebsd-arm@FreeBSD.ORG Fri May 15 08:18:54 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 270BC932 for ; Fri, 15 May 2015 08:18:54 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 E3C361868 for ; Fri, 15 May 2015 08:18:53 +0000 (UTC) Received: by igbsb11 with SMTP id sb11so112853094igb.0 for ; Fri, 15 May 2015 01:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PPER8eOy7NaXV9gWef58aAEgrrmsv8WQPznO5zNJBJM=; b=soA6w2ofwQH/AbDri3x7QZxbrbS4jgv0r6Fo0s3327vwbQG4dsGjCwlMg0Fg12lKY0 lzh8adpiJt8ofalx2BywsWP9csiYrOLGTk5M0K8zjWdJc7/yCDVoL5S9QJcGnfoCDz5C 3KYCiKlzH1BOTSelm8v1twtLTRELJDdb+dR6suOYBfehZU5Z756n9gvp2knezbJcPRIB Bwwwuugj7VuQdLTCSDQGIbxmSZ1q+qMHzWheRTxoyvf3zaOV0bleu1CsOOfg13rQRDTb 6B60rQJY0CSAzy/G/79Ss2N2IDF7Rt6GqSY2Iux/UdxrBy+cHIgKIfHzp/Dz+VmrmTgY kwfA== MIME-Version: 1.0 X-Received: by 10.42.206.9 with SMTP id fs9mr19178483icb.19.1431677933220; Fri, 15 May 2015 01:18:53 -0700 (PDT) Received: by 10.64.228.199 with HTTP; Fri, 15 May 2015 01:18:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 May 2015 10:18:53 +0200 Message-ID: Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] From: Svatopluk Kraus To: Keith White Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 08:18:54 -0000 On Fri, May 15, 2015 at 2:13 AM, Keith White wrote: > On Thu, 14 May 2015, Svatopluk Kraus wrote: > >> On Thu, May 14, 2015 at 2:03 AM, Keith White >> wrote: >>> >>> I get the following panic when trying to load an mfs_root on a >>> reasonably current BBB image: >>> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> trapframe: 0xdd43fd50 >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >>> >>> [ thread pid 4 tid 100054 ] >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >>> db> >>> >>> Hints, suggestions? >>> >>> ...keith >>> >>> --------------------------------- >>> More (trimmed) details from boot: >>> >>> ... >>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) >>> ... >>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 >>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) >>> ... >>> Found U-Boot device: disk >>> Checking unit=1 slice= partition=... good. >>> /boot/kernel/kernel data=0x505c2c+0x923d4 syms=[0x4+0x606a0+0x4+0x65ed4] >>> /boot/kernel/snd_uaudio.ko text=0xed3c data=0x620+0x10 >>> syms=[0x4+0x1ec0+0x4+0x1a2f] >>> ... >>> Type '?' for a list of commands, 'help' for more detailed help. >>> loader> load -t mfs_root /rootfs >>> /rootfs size=0x858000 >>> loader> boot -asv >>> Booting... >>> /boot/dtb/beaglebone-black.dtb size=0x24b4 >>> Loaded DTB from file 'beaglebone-black.dtb'. >>> Kernel entry at 0x80200100... >>> Kernel args: -asv >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> Copyright (c) 1992-2015 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 >>> >>> kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL >>> arm >>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 >>> WARNING: WITNESS option enabled, expect reduced performance. >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. >>> ... >>> mmc0: Probing bus >>> usbus0: 480Mbps High Speed USB v2.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> md0: Preloaded image 8749056 bytes at 0x9b9f00 >>> ugen1.1: at usbus1 >>> uhub0: >>> on >>> usbus1 >>> ugen0.1: at usbus0 >>> uhub1: >>> on >>> usbus0 >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> trapframe: 0xdd43fd50 >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >>> >>> [ thread pid 4 tid 100054 ] >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >> >> >> >> Well, FAR (fault address) points to user address space. System is >> still in boot process and no user address should be used. The first >> thing is to find out if arguments pushed to bcopy() in >> mdstart_preload() are correct. Can you print them out? >> ... > > > Thanks for the hint! After a little digging with ddb, it appears > that the fault address is missing an offset of KERNBASE (0xc0000000). > The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") + > KERNBASE (0xc0000000). The following patch fixes the symptom, and > allows a boot to successfully complete. The resulting md is also > usable as /. > > I'm sure there's a more correct patch? > > Index: sys/dev/md/md.c > =================================================================== > --- sys/dev/md/md.c (revision 282672) > +++ sys/dev/md/md.c (working copy) > @@ -1590,7 +1590,11 @@ > len = preload_fetch_size(mod); > if (ptr != NULL && len != 0) { > sx_xlock(&md_sx); > +#ifdef __arm__ > + md_preloaded(KERNBASE + ptr, len, name); > +#else > md_preloaded(ptr, len, name); > +#endif > sx_xunlock(&md_sx); > } > } Thanks for debugging it. The preload_fetch_addr() already uses preload_addr_relocate to adjust returned address. IMO, a patch should either deal with preload_addr_relocate and init it correctly or fix MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is set only when FREEBSD_BOOT_LOADER is defined. In this moment, I know nothing about how MODINFO_ADDR info is generated. BTW, physical address space starts at 0x80000000 on BBB and KERNBASE is 0xC0000000, so I would be expecting that preload_addr_relocate should be set to 0x40000000. The FAR is 0x01211ef0, so it's not physical address. And as your patch helps, it's an offset to either physical or virtual address space. So it looks more like MODINFO_ADDR info problem. > > ...keith