Subject: RE: memory disk, evbarm - lubbock
To: 'Richard Earnshaw' <>
From: Stewart Heitmann <>
List: tech-kern
Date: 04/16/2003 18:35:32
thanks for the hints. I made some limited progress.

By upping KERNEL_PT_KERNEL_NUM to 8 I have managed to boot
a kernel with enough space for a 8192K memory disk, which
was better than before. But if I try for a bigger memory
disk then /sbin/init exits with signal 11,
although the kernel seems quite happy.
Further increasing KERNEL_PT_KERNEL_NUM doesnt help.

RedBoot> load -r -b 0xa0200000 netbsd.bin
Raw file loaded 0xa0200000-0xa136e3c0
RedBoot> go 0xa0200000
NetBSD/evbarm (lubbock) booting ...
initarm: Configuring system ...
physmemory: 16384 pages at 0xa0000000 -> 0xa3ffffff
Allocating page tables
freestart = 0xa0009000, free_pages = 503 (0x000001f7)
IRQ stack: p0xa01c5000 v0xc01c5000
ABT stack: p0xa01c4000 v0xc01c4000
UND stack: p0xa01c3000 v0xc01c3000
SVC stack: p0xa01c1000 v0xc01c1000
Creating L1 page table at 0xa01fc000
Mapping kernel
pmap_map_chunk: pa=0xa0200000 va=0xc0200000 size=0x165000 resid=0x165000
prot=0x3 cache=1
pmap_map_chunk: pa=0xa0365000 va=0xc0365000 size=0x102c000 resid=0x102c000
prot=0x3 cache=1
Constructing L2 page tables
pmap_map_chunk: pa=0xa01c5000 va=0xc01c5000 size=0x1000 resid=0x1000
prot=0x3 cache=1
pmap_map_chunk: pa=0xa01c4000 va=0xc01c4000 size=0x1000 resid=0x1000
prot=0x3 cache=1
pmap_map_chunk: pa=0xa01c3000 va=0xc01c3000 size=0x1000 resid=0x1000
prot=0x3 cache=1
pmap_map_chunk: pa=0xa01c1000 va=0xc01c1000 size=0x2000 resid=0x2000
prot=0x3 cache=1
pmap_map_chunk: pa=0xa01fc000 va=0xc01fc000 size=0x4000 resid=0x4000
prot=0x3 cache=1
freestart = 0xa1391000, free_pages = 11375 (0x2c6f)
switching to new L1 page table  @0xa01fc000...bootstrap done.
init subsystems: stacks vectors undefined page pmap Copyright (c) 1996,
1997, 1998, 1999, 2000, 2001, 2002, 2003
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.
NetBSD 1.6R (LUBBOCK) #26: Wed Apr 16 17:33:34 EST 2003
total memory = 65536 KB
avail memory = 39916 KB
using 844 buffers containing 3376 KB of memory
mainbus0 (root)
cpu0 at mainbus0: PXA250 step B-1 (XScale core)
cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled
cpu0: 32KB/32B 32-way Instruction cache
cpu0: 32KB/32B 32-way write-back-locking Data cache
pxaip0 at mainbus0 CPU clock = 99.331 MHz
com0 at pxaip0: FFUART: pxa2x0 integrate UART
com0: console
com1 at pxaip0: BTUART: pxa2x0 integrate UART
saost0 at pxaip0 addr 0x40a00000-0x40a0001f
saost0: SA-11x0 OS Timer
obio0 at pxaip0 intr 8 : baseboard=8 (DBPXA250(lubbock)), expansion card=15,
processor card=0 (Cotulla)
sm0 at obio0 addr 0xc000000 intr 3
sm0: SMC91C94/91C96, revision 9, buffer size: 6144
sm0: MAC address 00:02:b3:92:a7:f5, default media UTP
lcd0 at obio0
wsdisplay0 at lcd0 kbdmux 1
wsmux1: connecting to wsdisplay0
sacc0 at obio0 addr 0x10000000 intr 1
sacc0: SA1111 rev 1.1
sackbc0 at sacc0
pckbd0 at sackbc0
wskbd0 at pckbd0 mux 1
wskbd0: connecting to wsdisplay0
sackbc1 at sacc0
sacpcic0 at sacc0
pcmcia0 at sacpcic0
pcmcia1 at sacpcic0
clock: hz=100 stathz = 64
md0: internal 16384 KB image area
boot device: <unknown>
root device: sm0
dump device:
file system (default generic):
root on sm0
nfs_boot: trying BOOTP
nfs_boot: BOOTP next-server:
nfs_boot: my_name=dbpxa250
nfs_boot: my_domain=lake
nfs_boot: my_addr=
nfs_boot: my_mask=
nfs_boot: gateway=
root on
root file system type: nfs
init path (default /sbin/init):
Process (pid 1) got signal 11
Process (pid 1) got signal 11
Process (pid 1) got signal 11
Process (pid 1) got signal 11
Process (pid 1) got signal 11
Process (pid 1) got signal 11
Process (pid 1) got signal 11

I still dont know what is going on here.
I am guessing a stack somewhere got overwritten.
As far as I can figure the memory is mapped like this:

a0000000                start of ram
...                     ? (1796K)
a01c1000 - a01c2fff     SVC stack (8K)
a01c3000 - a01c3fff     UND stack (4K)
a01c4000 - a01c4fff     ABT stack (4K)
a01c5000 - a01c5fff     IRQ stack (4K)
...                     ? (35K+)
a01fc000 - a01fffff     L1 page table (16K)
a0200000 - a0365000     Kernel stuff (1428K)
a0365000 - a1390fff     Kernel Memory Disk (16560K)
a1391000 - a4000000     rest of ram (45500K)

I am not familar with the NetBSD memory layout,
but I cant see any obvious conflicts here.

Could it be the VM address space you mentioned?
I'm sorry but I didnt understand that part.
Can you please elaborate?

I tinkered around with the KERNEL_PT_VMDATA_NUM
setting in lubbock_machdep.c but it didnt seem to
have any effect other than to move the stacks 
down in memory a little.
I was just guessing at any rate.


> -----Original Message-----
> From: Richard Earnshaw []
> Sent: Tuesday, April 15, 2003 9:00 AM
> To: Stewart Heitmann
> Cc: '';
> Subject: Re: memory disk, evbarm - lubbock 
> > I am trying to create a memory disk within the kernel
> > for the evbarm port to the LUBBOCK (Intel XScale) eval board.
> > Ultimately I want to put the root filesystem on the memory disk,
> > but havent got that far yet because I cant make the memory
> > disk large enough.
> > 
> > I can compile a kernel with up to 4096K space set aside
> > for the memory disk, but when I try to make it larger I
> > get a kernel panic. 
> I think static data is part of the kernel image, so the 
> amount of space 
> reserved for it is governed by the definition of 
> evbarm/<board>/<board>_machdep.c.  This is the number of L2 tables to 
> allocate for mapping the kernel image (each page can manage 4MB of 
> memory).  The default seems to be about 2 for most boards.  
> You could try 
> increasing that number, you probably need to make it one or 
> two more than 
> is needed for your ram disk.
> > Oddly enough, when I make it much much larger (16384K or more)
> > the kernel boots ok, but /sbin/init seg faults.
> That's probably just a coincidence.
> > 
> > Is there a limit on the size of a memory disk?
> > I'd like to make one about 30MB, is that a silly thing to try???
> Well, you need kernel space VM for this.  There's a limit on 
> the amount of 
> virtual address space available for that, but how much you have will 
> depend on where your kernel is mapped and what other 
> addresses have to be 
> crammed into the available space.  All devices are mapped in there.
> R.