On Sat, Mar 6, 1999, William O Ferry <woferry@iname.com> wrote:

>	"boot enet:0" seems to work just fine for these machines, though it seems
>to grab the file in quick bursts, with long delays in between, and the latest
>GENERIC kernel I built gets about half-way through the PCI device
probing and 
>dies
>with a trap in the pci_conf_read() function.

All your problems with PCI i/os and config access seems logical: since
most chips are on the second PCI bus, you need to implement code for
handling config and i/o access thru the second bridge.

>	The next problem was that it detected the Paddington chip, but did not
>configure it.  This is because the path of the device in OFW is different, 
>since
>it's on the other side of the PCI-PCI bridge.  Adding the code:
>	case 0x10:
>	case 0x17:
>		node = OF_finddevice("/pci/mac-io");
>+		if (node == -1) {
>+		  node = OF_finddevice("/pci/pci-bridge/mac-io");
>+		}
>		break;
>in obio.c seems to have done the trick, obio0 listed it's children.  It
seems 
>-1
>indicates an error in OF_finddevice, so I think this is the right thing
to do.
>It definitely works on my machine.

I don't know how registry probing is done in NetBSD (I have more linux
experience), but theorically, you should not find devices by pathname,
but by device-type and compatible properties, and eventually name.

>	Additionally, the Paddington IDE controller has yet another new name
>in OFW (do any two machines have the same name?!?!?  =), this time it's
>"ata-3".  Adding this to the list of names in wdc_obio.c got it to see the
>secondary IDE bus (that the CD and Zip drives are connected to).

There are several IDE channels on Paddignton, Heathrow and OHare and they
have various names, again you should identify them using the type rather
than the name.

>	I tried to get pciide up and running, to access the CMD0604.  I
>just couldn't get it to work.  It seemed that the iot and ioh addresses it
>wound up with were wrong, though for the most part it seemed to "just work".
>I suspect the information coming into pciide from the start was wrong, I
>will probably look into this more tomorrow.

Look like a similar problem to get i/o accesses working on the second bus.

Hope this helps,
Benjamin.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>