Stamp9261
Daan Vreeken
Daan at vitsch.nl
Fri Feb 18 11:17:55 UTC 2011
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
More information about the freebsd-arm
mailing list