On Sat, 19 Feb 2005 01:20:29 -0800
Matt Thomas <matt@3am-software.com> wrote:

> Good.  I've wanted to kill the ofppc bus_space for awhile now.=20
Yes. It is obsolete since we have your generic PPC bus_space(9). With
the current ofppc bus_space(9) code we need the whole bus_space(9)
implementation per platform. With the generic code we need only one
implementation that can be parametricised by variables.

In addition he current ofppc bus_space(9) code is simply to inflexible
for the things we need for ofppc. The great, final goal is generic
support for all (many, well, at least some) CHRP / RPA style RS/6000
machines by a "chrp" platform of port-ofppc. (And similar generic suport
for PReP machines with OFW like the Motorola PowerStack II.) To do this
we must read the address ranges of PCI/ISA IO / memory mappings of the
PCI host bridges (there may be multiple...) through the "ranges"
property in the OFW device tree and configure the bus space code
dynamicly at boot time. The current code can't do this as the ranges are
compiled into the code.

> (Sorry Jason).
AOL. ;-)

> Does it timeout?  Is hardclock firing?  are you getting pcn
> interrupts?=20
This is exactly the stage where I am: See if interrupts are working, if
they get delivered, if the clock works (callout(9) etc.), if pcn(4) can
emit packets... I am sure the interrupt stuff doen't work well at the
moment. I am now trying to get bus_space(9) and bus_dma(9) problems out
of the way to concentrate on the interrupt code.

>   did you tcpdump the network and see packets being transmitted?
Yes, I tcpdumed, no packets.

> Yes.  Though you really should make, if you can, that address range be
> a BAT.=20
Well. The PCI memory range on that machine covers the entire space from
0x80000000 to 0xfcffffff. In theory any PCI device can be maped by the
firmware anywhere in that range. So we would need to BAT map all of
this. But then the BAT mapping collides with USER_SR, KERNEL_SR and
KERNEL2_SR. (Been there on port-prep, did BAT mapping, didn't work,
didn't get a T-shirt. ;-) )

> mapiodev() will automatically see it's BAT mapped and return that
> instead.
I already know that bus_space_map(9) looks at existing BAT mappings
first. I need this functionality to get things like serial console going
while UVM isn't initialized and thus mapiodev() can't be used.

> Really?  mapiodev shouldn't cause that to happen.  It locks up doing
> the trace?  Or someplace else?
With a BAT mapping for the area where pcn(4) resides ddb(4) works as
expected:
0xd999ef50: at chrp_configuration+0x80793b84
saved LR(0xfffffffb) is invalid.
db>=20

Without BAT mapping, i.e. mapping through mapiodev(), it hangs here:
0xd999ef50: at chrp_configuration+0x80793b84
(I.e. it goes to nirvana instead printing the line about the LR.)
--=20


tsch=FC=DF,
       Jochen

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