From owner-freebsd-arm@FreeBSD.ORG Fri Feb 18 11:17:55 2011 Return-Path: Delivered-To: FreeBSD-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0854C106564A for ; Fri, 18 Feb 2011 11:17:55 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 94F3B8FC15 for ; Fri, 18 Feb 2011 11:17:54 +0000 (UTC) Received: from [192.168.72.11] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p1IBHsj3006518; Fri, 18 Feb 2011 12:17:54 +0100 (CET) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Vitsch Electronics To: Olivier Houchard Date: Fri, 18 Feb 2011 12:17:51 +0100 User-Agent: KMail/1.9.10 References: <201102180028.34539.Daan@vitsch.nl> <20110218101425.GA52167@ci0.org> In-Reply-To: <20110218101425.GA52167@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102181217.51577.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl Cc: FreeBSD-arm@freebsd.org Subject: Re: Stamp9261 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 11:17:55 -0000 Hi Olivier, Thanks for the quick reply! On Friday 18 February 2011 11:14:25 Olivier Houchard wrote: > Hi Dean, > > On Fri, Feb 18, 2011 at 12:28:34AM +0100, Daan Vreeken wrote: > > The board's (64MB of) SDRAM is located at 0x20000000. After tftp-ing the > > kernel.bin image to 0x20000000 with u-boot and starting it the board > > seems to hang. By printing bytes to the DBGU serial port I've been able > > to trace the execution through "arm/locore.S" up to the point where the > > MMU is enabled with the following code: > > > > /* Enable MMU */ > > mrc p15, 0, r0, c1, c0, 0 > > orr r0, r0, #CPU_CONTROL_MMU_ENABLE > > mcr p15, 0, r0, c1, c0, 0 > > nop > > nop > > nop > > CPWAIT(r0) > > > > Either the CPU halts somewhere in this piece of code, or my DBGU printing > > macro doesn't work after enabling the MMU and the code halts somewhere > > else. ;-) > > Well nothing maps the DBGU at this points, so trying to access to it won't > work :) D'oh. Of course. > That said, there were an issue which I fixed on 02/13 with rev 218666, > which would make any board freezing at boot, so I'd suggest trying to > update your sources :) I've just rebased the code base to today's -CURRENT and that indeed fixes the freeze. The board now gets past : subsystem 2100000 makectx(0)... CPU: ARM926EJ-S rev 5 (ARM9EJ-S core) DC enabled IC enabled WB enabled LABT 16KB/32B 4-way Instruction cache 16KB/32B 4-way write-back-locking-C Data cache real memory = 33554432 (32 MB) avail memory = 29298688 (27 MB) .. and ends somewhere just after printing : Timecounters tick every 10.000 msec .. in a functional debugger after the following fault : subsystem 8600000 pf_proto_unregister(0)... done. subsystem 8800000 domain_add(0xc02843d4)... done. domain_add(0xc0281340)... done. domain_add(0xc0285554)... done. domain_init(0xc02843d4)... done. domain_init(0xc0285554)... vm_fault(0xc029157c, 31003000, 2, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc02c5e10 FSR=00000005, FAR=31003100, spsr=600000d3 r0 =c02945bc, r1 =00000001, r2 =c1f38980, r3 =31003100 r4 =c02a3ddc, r5 =c02945c0, r6 =00000000, r7 =00000000 r8 =00000001, r9 =c0162890, r10=00000000, r11=c02c5e84 r12=c0291b2c, ssp=c02c5e5c, slr=c01e4608, pc =c00ca6e8 [ thread pid 0 tid 100000 ] Stopped at callout_reset_on+0x190: str r4, [r3] db> bt Tracing pid 0 tid 100000 td 0xc02912b0 callout_reset_on() at callout_reset_on+0x10 scp=0xc00ca568 rlv=0xc0168b64 (ip_init+0x210) rsp=0xc02c5e88 rfp=0xc02c5ea8 r10=0x23ebfcf4 r9=0x23ebfe46 r8=0x23ebffdc r7=0x20000050 r6=0x00000001 r5=0xc0285554 r4=0xc02a3ddc ip_init() at ip_init+0x10 scp=0xc0168964 rlv=0xc0106190 (accept_filt_generic_mod_event+0x10f4) rsp=0xc02c5eac rfp=0xc02c5eb8 r4=0xc0285110 accept_filt_generic_mod_event() at accept_filt_generic_mod_event+0xfe0 scp=0xc010607c rlv=0xc0106ac8 (domain_init+0x38) rsp=0xc02c5ebc rfp=0xc02c5ed0 domain_init() at domain_init+0x10 scp=0xc0106aa0 rlv=0xc007d368 (mi_startup+0x214) rsp=0xc02c5ed4 rfp=0xc02c5ef4 r5=0x08800000 r4=0xc023270c mi_startup() at mi_startup+0x10 scp=0xc007d164 rlv=0xc00000f4 (btext+0xf4) rsp=0xc02c5ef8 rfp=0x00000000 r6=0x00000002 r5=0x2000005c r4=0x20000134 db> The amount of RAM is incorrectly reported (the board should have 64MB), the debug console runs at 57Kbaud instead of 115K, but at least it's looking more hopefull than what I had yesterday :) Thanks, -- Daan Vreeken Vitsch Electronics http://Vitsch.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380