Some PPC VM weirdness

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

Hi.

I am trying to bring NetBSB to the IBM RS/6000 43P-150 and B50. This is
done as a platform inside port-ofppc. I replaced the port-ofppc
speciffic bus_space(9) code with the generic code from
sys/arch/powerpc/powerpc/bus_space.c. I imported the whole interrupt
handling code from port-prep because this code is knowen to work. Some
PCI and ISA MD bits here and there... At the moment I am tyring to bring
all this to live and play nicely together.

Now I get to the point where the kernel asks for the root device. When I
enter "pcn0" it hangs. I can brake into ddb(4) and a traceback give some
interresting adresses:
root on pcn0
nfs_boot: trying DHCP/BOOTP
~[MrPomeroy]%b
Stopped at      netbsd:cpu_Debugger+0x10: lwz     r0, r1, 0x14
db> t
0x00425f00: at comintr+0x61c
0x00425f50: at ext_intr_openpic+0x23c
0x00425fa0: at trapstart+0x8f4
0xd999ed90: at spinlock_switchcheck+0x3c
0xd999eda0: at Idle+0x24
0xd999edb0: at mi_switch+0x198
0xd999edf0: at ltsleep+0x460
0xd999ee30: at start_init+0x80
0xd999ef40: at cpu_switchto+0x44
0xd999ef50: at chrp_configuration+0x80793b84
saved LR(0xfffffffb) is invalid.
db> 

Running nm(1) on the kernel image gives this addresses:
001002b8 T Idle
003dc67c B chrp_configuration
00173da4 T comintr
00100540 T cpu_switchto
00313150 t ext_intr_openpic
0025ed4c T ltsleep
0025f9b0 T mi_switch
0024b978 T spinlock_switchcheck
00236cd4 t start_init
003aad90 S start_init_exec
00100aec T trapstart

Is this eligible? I always thought kernel text/data/bss is mapped 1:1.
(I am no VM expert.)

Or is this a bug in ddb(4)? When I use e.g. "print/x start_init" I get
the correct adresses.

Also: The PPC VM stuff uses two 256 MB segments KERNEL_SR and KERNEL2_SR
for UVM-KVA mappings. port-ofppc uses segments 13 and 14 for this. AFAIK
(sys/arch/powerpc/include/oea/vmparam.h) So it is correct that a mapping
done by sys/arch/powerpc/oea/oea_machdep.c:mapiodev() via
uvm_km_valloc(9) ends in the rage 0xd0000000..0xdfffffff?

There is some other VM interaction with ddb(4). When I do a BAT mapping
for the PCI memory area where the pcn(4) resides bus_space_mapp(4) skips
the mapiodev() / uvm_km_valloc(9) part and just returns the pysical
address, as it is already mapped via BAT. In this case ddb(4) returns to
its prompt after a "trace" command. When I don't add a BAT mapping for
the PCI memory area of pcn(4), bus_space_mapp(4) uses mapiodev() /
uvm_km_valloc(9) to map it into KVA. If uvm_km_valloc(9) is used the
machines locks up hard and needs to be power cycled after "trace".

Any ideas?
-- 


tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/