Re: panic trying to add missing SDRAM to tsarm kernel.
Anders Lindgren <ali <at> df.lth.se>
2007-04-09 14:38:16 GMT
Some more tidbits of information.
This is insane; I now reliably get the same Mutex error booting an
*unmodified* kernel. The unmodified kernel worked before I started playing
with the startup code, but now I consistently get a "locking against
myself" panic, despite having reverted all my changes and rebuilt the
kernel from scratch.
Before reverting my changes, I had some weird results; In an attempt to
verify that the SDRAM behaves as expected, I tried to add a second mapping
for the first nSDCE2 bank in tsarm_start.S; VA 0xc0800000..c0ffffff => PA
0xe0000000..0xe07fffff, by entering it into the bootstrap page table just
after the lowest 8MB gets mapped.
I then did some printfs right after consinit() in initarm to verify I
could read and write to the memory, which succeeded. To make sure I wasn't
just seeing D$ data, I moved my test to right after set_cpufuncs and did a
cpu_dcache_wbinv_range on the address after the write, to make sure it was
cleaned out, and after that I get 0xe59fe59f back instead of the pattern I
wrote (one unsigned long).
Anyone else tried -current on TS72xx boards?
Fumbling pretty much in blind here, so any help is appreciated.
On Sat, 7 Apr 2007, Anders Lindgren wrote:
> As mentioned in my previous post, I am trying to make my TS7250 board utilise
> all its 64MB SDRAM. The current NetBSD code has a physical memory size of
> 32MB hardcoded in.
> I've successfully booted NetBSD 4.99.16 (TS7200) on it and now I am trying to
> change its opinion on the amount of available SDRAM.
> The first 32MB show up at PA 0x0, 0x16MB, 0x64MB and 0x80MB. The banks I am
> trying to add are located on the EP9302 nSDCE2 starting at PA 0xE0000000,
> with the same bank layout.
> I made the following changes:
> - Added additional banks to the bootconfig.dram array at
> <sys/arch/evbarm/tsarm/tsarm_machdep.c:454>, changing dramblocks to 8 and
> adding the additional ranges.
> - Updated the size of the tsarm_dma_ranges array from 4 to 8 at
> - Added uvm_page_physload() calls for the additional banks at
> <sys/arch/evbarm/tsarm/tsarm_machdep.c:777>, and updated physmem accordingly.
> This looked like it should be pretty much it; it's just some more RAM, after
> all. Rebuild kernel and reboot. It looks promising, the kernel boots, finding
> total memory = 65536 KB
> avail memory = 60156 KB
> ..but shortly after mounting the NFS root filesystem, I get a "locking
> against myself" kernel panic from a pipe_read syscall. Obviously I'm missing
> something, since the default kernel works fine, but this is my first venture
> into NetBSD kernel programming so I am pretty much fumbling in the dark here.
> Any ideas?
> This is the backtrace I get from ddb:
> root on 192.168.1.6:/export/tsarm
> Sat Apr 7 15:52:51 CEST 2007
> Mutex error: mutex_vector_enter: locking against myself
> lock address : 0x00000000c051ee0c
> current cpu : 0
> current lwp : 0x00000000c2511c80
> owner field : 0x0000000000010c00 wait/spin: 0/1
> panic: lock error
> Stopped in pid 13.1 (sh) at netbsd:cpu_Debugger+0x4: mov r15, r14
> db> bt
> scp=0xc03674c0 rlv=0xc0362134 (netbsd:lockdebug_abort+0x5c)
> rsp=0xc2d87d5c rfp=0xc2d87d7c
> scp=0xc03620e8 rlv=0xc0346960 (netbsd:mutex_abort+0x3c)
> rsp=0xc2d87d80 rfp=0xc2d87d90
> r5=0xc051ee0c r4=0xffffffff
> scp=0xc0346934 rlv=0xc0346ad8 (netbsd:mutex_vector_enter+0x110)
> rsp=0xc2d87d94 rfp=0xc2d87db4
> scp=0xc03469d8 rlv=0xc035a3a8 (netbsd:turnstile_lookup+0x28)
> rsp=0xc2d87db8 rfp=0xc2d87dcc
> r8=0xc2511c80 r7=0xc2da2f00
> r6=0xc2da2f08 r5=0xc2da2f00 r4=0xc051f840
> scp=0xc035a390 rlv=0xc0346c2c (netbsd:mutex_vector_exit+0x8c)
> rsp=0xc2d87dd0 rfp=0xc2d87de4
> r5=0x00000000 r4=0xc2da2f00
> scp=0xc0346bb0 rlv=0xc0337950 (netbsd:cv_wait_sig+0xa0)
> rsp=0xc2d87de8 rfp=0xc2d87e14
> r5=0x00000000 r4=0xc051e8f0
> scp=0xc03378c0 rlv=0xc036e780 (netbsd:pipe_read+0x348)
> rsp=0xc2d87e18 rfp=0xc2d87e48
> r8=0xc2d87e54 r7=0xc2da2f18
> r6=0xc2da2f00 r5=0xc2da2f08 r4=0xc2519f00
> scp=0xc036e448 rlv=0xc036b678 (netbsd:dofileread+0xb0)
> rsp=0xc2d87e4c rfp=0xc2d87eac
> r10=0xc2511c80 r9=0x00000003
> r8=0x00000000 r7=0x00000080 r6=0xc251089c r5=0xbfffeaa8
> scp=0xc036b5d8 rlv=0xc036b7dc (netbsd:sys_read+0x84)
> rsp=0xc2d87eb0 rfp=0xc2d87edc
> r10=0x0002fd28 r9=0x00000004
> r8=0xc2511c80 r7=0xc2d87f30 r6=0xc2511c80 r5=0x00000003
> scp=0xc036b768 rlv=0xc03ba244 (netbsd:syscall_plain+0x118)
> rsp=0xc2d87ee0 rfp=0xc2d87f60
> r7=0xc0463b38 r6=0xc2d87fb4
> r5=0x00000003 r4=0xefa00003
> scp=0xc03ba13c rlv=0xc03ba710 (netbsd:swi_handler+0xa4)
> rsp=0xc2d87f64 rfp=0xc2d87fb0
> r10=0x0002fd28 r9=0x0002fdfe
> r8=0x00000000 r7=0xc251089c r6=0xefa00003 r5=0xc2d87fb4
> scp=0xc03ba67c rlv=0xc03bd744 (netbsd:swi_entry+0x64)
> rsp=0xc2d87fb4 rfp=0xbfffeb70
> r7=0x0002fe20 r6=0x00000000
> r5=0xffffffff r4=0x0002f76c
> Best regards,