From owner-freebsd-arm@FreeBSD.ORG Thu May 2 21:56:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECF18829; Thu, 2 May 2013 21:56:29 +0000 (UTC) (envelope-from awg@embtoolkit.org) Received: from duppyconqueror.embtoolkit.org (duppyconqueror.embtoolkit.org [188.165.227.169]) by mx1.freebsd.org (Postfix) with ESMTP id 872EE1744; Thu, 2 May 2013 21:56:29 +0000 (UTC) Received: from [192.168.1.100] (nogent.walsimou.com [82.67.240.252]) (AUTH: PLAIN awg@embtoolkit.org) by duppyconqueror.embtoolkit.org with ESMTPA; Thu, 02 May 2013 23:55:59 +0200 id 0298FAB3.000000005182E0EF.00003BF5 Message-ID: <5182E0FD.80300@embtoolkit.org> Date: Thu, 02 May 2013 23:56:13 +0200 From: Abdoulaye Walsimou Gaye User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ian Lepore Subject: Re: vm fault on OpenRD [was: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)'] References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> <5181AC1A.2020400@embtoolkit.org> <1367508111.1180.112.camel@revolution.hippie.lan> In-Reply-To: <1367508111.1180.112.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 21:56:30 -0000 On 05/02/2013 05:21 PM, Ian Lepore wrote: [....] > ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 > usbus0: EHCI version 1.0 > usbus0: stop timeout > usbus0: set host controller mode > > vm_fault(0xc0cc6674, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc0cfab68 > FSR=00000005, FAR=00000010, spsr=200000d3 > r0 =c36605c0, r1 =c0cc6390, r2 =600000d3, r3 =00000000 > r4 =c0a4e65c, r5 =80000003, r6 =c36640d0, r7 =c0c12278 > r8 =ffffffff, r9 =c350f280, r10=c3664080, r11=c0cfabf0 > r12=c0cc8aa0, ssp=c0cfabb4, slr=c0c26698, pc =c0a50964 > > [ thread pid 0 tid 100000 ] > Stopped at > While the error messages are similar, it appears that the cause is > completely different. Ian, Yes I realized that, sorry for the original thread hijack! > Given that it appears to have crashed while > initializing USB, I can think of two things to try... > > Add USB_HOST_ALIGN=32 to your kernel config file. This is required for > all armv4 and armv5 platforms, but isn't in most of our stock config > files right now. Making only this change on my KERNCONF file leads to kernel hang on, 'usbus0: set host controller mode', see here: miibus0: on mge0 e1000phy0: PHY 8 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-0xf103ffff irq 22 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode > Also, try the attached patch. It avoids unconditionally enabling the > cache "allocate on write" feature in the hardware, and instead leaves it > in whatever state the bootloader set it to (on the assumption that the > vendor-supplied bootloader knows best about when this feature is > problematic; I think it may depend somewhat on how the board is > designed). > Applying only your patch still leads to vm fault, see here: ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode vm_fault(0xc0cbe934, ff0000, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc0cf2b5c FSR=00000005, FAR=00ff0000, spsr=200000d3 r0 =00000000, r1 =00000000, r2 =00000000, r3 =00000000 r4 =c34f0260, r5 =c365c080, r6 =00000000, r7 =00000001 r8 =c355ca80, r9 =00000000, r10=00000000, r11=c0cf2bd4 r12=00ff0000, ssp=c0cf2ba8, slr=c0c96acc, pc =c0a4b0c4 Making the two changes (KERNCONF USB_HOST_ALIGN=32 and your patch) lead also to the same vm fault as above. The board's bootloader is a mainline u-boot, see here: Marvell>> version U-Boot 2013.04-00008-g500bccf (Apr 27 2013 - 01:08:22) OpenRD-Base armel-unknown-linux-gnueabi-gcc (embtoolkit-00143-g3687f38) 4.7.4 20130411 (prerelease) GNU ld (GNU Binutils) 2.23.2 Note that you are right, it is USB initialization the issue. If I completely disable USB, the kernel boots correctly and tries to mount nfs root filesystem. I will try to figure out what's going on, any suggestions are welcome. Thanks, AWG