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