On Feb 18, 2005, at 2:17 PM, Jochen Kunz wrote:

> 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.

Good.  I've wanted to kill the ofppc bus_space for awhile now.  (Sorry 
Jason).

> 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>

Does it timeout?  Is hardclock firing?  are you getting pcn interrupts? 
  did you tcpdump the network and see packets being transmitted?

> 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.)

What you are seeing is normal.  Remember that interrupts happen on 
their own stack and you seeing the transition to the interrupt stack 
there.  I should ddb about interrupts someday.

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

It's normal.

> 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?

Yes.  Though you really should make, if you can, that address range be 
a BAT.  mapiodev() will automatically see it's BAT mapped and return 
that instead.

> 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".

Really?  mapiodev shouldn't cause that to happen.  It locks up doing
the trace?  Or someplace else?

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this 
message.