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.

Best regards,
ali:)

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 
> <sys/arch/evbarm/tsarm/tsarm_machdep.c:181>.
>
> - 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 
> 64MB:
>
> :
> :
> 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:
>
> ----8<----8<----
> 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
> netbsd:panic+0x14
>        scp=0xc03674c0 rlv=0xc0362134 (netbsd:lockdebug_abort+0x5c)
>        rsp=0xc2d87d5c rfp=0xc2d87d7c
> netbsd:lockdebug_abort+0x10
>        scp=0xc03620e8 rlv=0xc0346960 (netbsd:mutex_abort+0x3c)
>        rsp=0xc2d87d80 rfp=0xc2d87d90
>        r5=0xc051ee0c r4=0xffffffff
> netbsd:mutex_abort+0x10
>        scp=0xc0346934 rlv=0xc0346ad8 (netbsd:mutex_vector_enter+0x110)
>        rsp=0xc2d87d94 rfp=0xc2d87db4
> netbsd:mutex_vector_enter+0x10
>        scp=0xc03469d8 rlv=0xc035a3a8 (netbsd:turnstile_lookup+0x28)
>        rsp=0xc2d87db8 rfp=0xc2d87dcc
>        r8=0xc2511c80 r7=0xc2da2f00
>        r6=0xc2da2f08 r5=0xc2da2f00 r4=0xc051f840
> netbsd:turnstile_lookup+0x10
>        scp=0xc035a390 rlv=0xc0346c2c (netbsd:mutex_vector_exit+0x8c)
>        rsp=0xc2d87dd0 rfp=0xc2d87de4
>        r5=0x00000000 r4=0xc2da2f00
> netbsd:mutex_vector_exit+0x10
>        scp=0xc0346bb0 rlv=0xc0337950 (netbsd:cv_wait_sig+0xa0)
>        rsp=0xc2d87de8 rfp=0xc2d87e14
>        r5=0x00000000 r4=0xc051e8f0
> netbsd:cv_wait_sig+0x10
>        scp=0xc03378c0 rlv=0xc036e780 (netbsd:pipe_read+0x348)
>        rsp=0xc2d87e18 rfp=0xc2d87e48
>        r8=0xc2d87e54 r7=0xc2da2f18
>        r6=0xc2da2f00 r5=0xc2da2f08 r4=0xc2519f00
> netbsd:pipe_read+0x10
>        scp=0xc036e448 rlv=0xc036b678 (netbsd:dofileread+0xb0)
>        rsp=0xc2d87e4c rfp=0xc2d87eac
>        r10=0xc2511c80 r9=0x00000003
>        r8=0x00000000 r7=0x00000080 r6=0xc251089c r5=0xbfffeaa8
>        r4=0xc2519f00
> netbsd:dofileread+0x10
>        scp=0xc036b5d8 rlv=0xc036b7dc (netbsd:sys_read+0x84)
>        rsp=0xc2d87eb0 rfp=0xc2d87edc
>        r10=0x0002fd28 r9=0x00000004
>        r8=0xc2511c80 r7=0xc2d87f30 r6=0xc2511c80 r5=0x00000003
>        r4=0xc2d87fb8
> netbsd:sys_read+0x10
>        scp=0xc036b768 rlv=0xc03ba244 (netbsd:syscall_plain+0x118)
>        rsp=0xc2d87ee0 rfp=0xc2d87f60
>        r7=0xc0463b38 r6=0xc2d87fb4
>        r5=0x00000003 r4=0xefa00003
> netbsd:syscall_plain+0x10
>        scp=0xc03ba13c rlv=0xc03ba710 (netbsd:swi_handler+0xa4)
>        rsp=0xc2d87f64 rfp=0xc2d87fb0
>        r10=0x0002fd28 r9=0x0002fdfe
>        r8=0x00000000 r7=0xc251089c r6=0xefa00003 r5=0xc2d87fb4
>        r4=0xc2511c80
> netbsd:swi_handler+0x10
>        scp=0xc03ba67c rlv=0xc03bd744 (netbsd:swi_entry+0x64)
>        rsp=0xc2d87fb4 rfp=0xbfffeb70
>        r7=0x0002fe20 r6=0x00000000
>        r5=0xffffffff r4=0x0002f76c
> ----8<----8<----
>
> Best regards,
> ali:)
>