Date: Fri, 18 Feb 2011 12:17:51 +0100 From: Daan Vreeken <Daan@vitsch.nl> To: Olivier Houchard <mlfbsd@ci0.org> Cc: FreeBSD-arm@freebsd.org Subject: Re: Stamp9261 Message-ID: <201102181217.51577.Daan@vitsch.nl> In-Reply-To: <20110218101425.GA52167@ci0.org> References: <201102180028.34539.Daan@vitsch.nl> <20110218101425.GA52167@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102181217.51577.Daan>