Porting OpenBSD to the Solbourne S4000

[ Index ] [ Prev: Every PMAP Goes to Heaven ] [ Next: El jardín de senderos que se bifurcan ]


Mapping Games

It was time to test my shiny new pmap. Needless to say, booting the kernel didn't get me very far:

ok boot aoutbsd
rarp: using IP address 10.0.1.164 = A0001A4
rarp: server at IP address 10.0.1.101 = A000165
Boot:  tftp.ei()/aoutbsd
Entry: 0xfd084000
Size:  0xc8000+0x1f980+0x328a8
pmap_bootstrap: 16 MB (2048 pages)
kernel spans fd080000-fd19e228, etext fd14c000, esym 0
needs 3 page tables, adjusted ekern fd1a8000
final tabidx 2
setting up range fd080000-fd1a8000; pde fd1a4fd0 (f01a8000,fd1a8000),
initial pte fd1a8100
[ bsd ELF symbol table not valid: bad magic ]
[ bsd a.out symbol table not valid ]
[ no symbol table formats found ]
Z
consinit(), oldtab = 0xfd169ea4, cn_tab = 0xfd169ea4
consinit done.
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2005 OpenBSD. All rights reserved.  http://www.OpenBSD.org

panic: uvm_pageboot_alloc: out of memory
Stopped at      0xfd1494a0:     jmpl            [%o7 + 0x8], %g0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
My debugging messages aside (including the Z letter alone on its line), the kernel did not print much. From the ddb interface, I could trace the panic to the early steps of the virtual memory system initialization: although I had correctly detected 16MB of physical memory, the system would exhaust it (although OpenBSD/sparc systems have no problems running in 16MB).

I was a bit puzzled at this point, but thinking about the problem for some time was enough to understand what went wrong. You might remember that, compared to the sparc port, the value of KERNBASE is much higher on the solbourne. And the code assumes that KERNBASE is at the very beginning of the virtual address space reserved for the kernel, i.e. the space in which the kernel will put all of its internal data structures.

By having KERNBASE at window fd and VM_MAX_KERNEL_ADDRESS at window fe, I would only leave 16MB, minus the kernels size, of virtual memory available to the kernel, and this was not enough to satisfy the hunger of the virtual memory system itself.

The only solution was to lower KERNBASE. It was time for the first kernel remapping in this ports history. By then, I did not know how many times I would have to do this...

What I call remapping the kernel, basically means changing the virtual memory layout of the whole system, mainly by changing the values in <machine/vmparam.h>.

For the time being, I chose to load the kernel 1:1, i.e. with virtual address matching the physical address. So I changed KERNBASE to 0xf0080000 instead of 0xfd080000. This would give us an even larger virtual memory range than on sparc! And to compensate for this, since the PROM would still want to load us at 0xfd080000 onwards, I tweaked the ELF to a.out conversion sequence to change all the load addresses.

The kernel would compensate by immediately reprogramming PTW2 (which was mapping the kernel 16MB window, uncached) to map the f0 window (physical memory) at the f0 virtual window, and jump there.

This trick indeed allowed the kernel to go further:

ok boot aoutbsd
rarp: using IP address 10.0.1.164 = A0001A4
rarp: server at IP address 10.0.1.101 = A000165
Boot:  tftp.ei()/aoutbsd
Entry: 0xfd084000
Size:  0xca000+0x1f948+0x328a8
[ bsd ELF symbol table not valid: bad magic ]
[ bsd a.out symbol table not valid ]
[ no symbol table formats found ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2005 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 3.7-current (GENERIC) #180: Wed Apr  6 16:26:33 GMT 2005
    miod@credogne.gentiane.org:/usr/src/sys/arch/solbourne/compile/GENERIC
real mem = 16777216
avail mem = 9641984
using 102 buffers containing 835584 bytes of memory
bootpath: 
mainbus0 (root) 
and it would hang on the mainbus0 line.

[ Index ] [ Prev: Every PMAP Goes to Heaven ] [ Next: El jardín de senderos que se bifurcan ]


miod@online.fr