Subject: Re: personal impression of issues on netbsd/macppc
To: Tim Kelly <hockey@dialectronics.com>
From: Nathan J. Williams <nathanw@wasabisystems.com>
List: port-macppc
Date: 11/19/2004 20:59:40
Tim Kelly <hockey@dialectronics.com> writes:

> 
> Earlier you referenced the iot. Using the code from bandit.c as an
> example, 
> 
>         struct ranges {
>                 u_int32_t pci_hi, pci_mid, pci_lo;
>                 u_int32_t host;
>                 u_int32_t size_hi, size_lo;
>         } ranges[6], *rp = ranges;
> 
>         /* find i/o tag */
>         len = OF_getprop(node, "ranges", ranges, sizeof(ranges));
>         if (len == -1)
>                 return;
>         while (len >= sizeof(ranges[0])) {
>                 if ((rp->pci_hi & OFW_PCI_PHYS_HI_SPACEMASK) ==
>                      OFW_PCI_PHYS_HI_SPACE_IO)
>                         pc->iot = (bus_space_tag_t)rp->host;
>                 len -= sizeof(ranges[0]);
>                 rp++;
>         }
> 
> indicates that the iot on a PCI-Host device comes from the host cell. In
> the case of /chaos, this is
> 
> ff83dcd0: /chaos@f0000000
> 
> name                    6368616f 7300.... ........ ........   "chaos"
> <snip>
> ranges            
>               02000000 00000000 f1000000 f1000000   00000000 01000000 
>               01000000 00000000 00000000 f0000000  00000000 00800000
>               02000000 00000000 90000000 90000000 00000000 10000000
> 
> or 0xf0000000. 

Note that what this code does is throw away everything except the
value of rp->host for the entry marked as OFW_PCI_PHYS_HI_SPACE_IO,
which is used as the I/O tag for the PCI universe behind this
bridge. That means that that's the offset of I/O space in the physical
memory map. PCI I/O address 0xaabb will appear to the CPU to be at
physical address 0xf000aabb.

        - Nathan