bus 2 is internal for the bridge, created implicitly for access to downstream ports

/ | \

BDF 2.0.0 BDF 2.1.0 BDF 2.2.0

| | |

| bus 3 | bus 4 | bus 5

| | |

BDF 3.0.* BDF 4.1.* (empty)

endpoint A endpoint B

For access to the bridge's configuration space at B:D:F 1.0.0, ATU must be programmed for CFG type 0 transaction (ATU[0].iATURC1.TYPE = 4)For access to all downstream ports on the bridge and beyond, ATU must be programmed for CFG type 1 transaction (ATU[0].iATURC1.TYPE = 5)

Neither devices, nor functions on any bus need to be compact; the numbers may be scattered within the range of devices or functions. Because of this the OAL layer must be able to handle exceptions when attempt to access non-existing PCIe configuration space is made.

Once OAL implementation is complete, a simple Microsoft-provided application can be used to travers the bus and the devices on it - is a little neat utility in the COMMON branch, named "pcienum"

...\WINCE700\public\common\oak\drivers\ceddk\test\pcienum\

Building it and running it will print out full information about the devices currently existing on the PCIe bus; this includes all bridges too.

The numbering of busses and devices should reflect the expected topology of the PCIe tree.

It is possible that OAL would not permit even read access to PCI Configuration space. This little addition may be required to OAL IOCTL support for the platform in OALPCICfgRead() function:

. . .

switch (dwIoControlCode) {

case IOCTL_HAL_DDK_CALL:

if (pInBuf != NULL && nInBufSize >= 4) {

// only peeking PCIe topology is allowed

if (IOCTL_OAL_READBUSDATA != *((DWORD*)pInBuf)) {

SetLastError(ERROR_ACCESS_DENIED);

break;

}

}

}

. . .

Once this is completed and working, then the BSP is ready to handle PCI resources -- MMIO, I/O and interrupts; and assign them accordingly to bridges and endpoints.