The Windows CE shared knowledge base

Debugging PCI bus with Windows CE

This time I will write about something I don't understand :-( Or at least not completely.

Some time ago I was debugging a new Intel hardware platform (Adlink ETX-BT, Celeron J1900) and I experienced unexpected hangups during boot of the DEBUG version of my WINCE800 image. The RELEASE version never gave problems and started properly. After narrowing down the problem, I came across this piece of code inside PCIBUS.DLL (pcicfg.c line ±800)

... // Set the bus numbers & secondary latency // Need to set the subordinate bus as max for now, then write // actual number after found all downstream busses (*pSubordinateBus)++; Info.SecondaryLatency = (Info.SecondaryLatency > 0) ? Info.SecondaryLatency : pBusInfo->SecondaryLatency; // use global bus value if not defined for bridge BusReg = PCIConfig_Read(Bus, Device, Function, PCIBRIDGE_BUS_NUMBER); ((PBRIDGE_BUS)(&BusReg))->PrimaryBusNumber = (BYTE)Bus; ((PBRIDGE_BUS)(&BusReg))->SecondaryBusNumber = (BYTE)(*pSubordinateBus); ((PBRIDGE_BUS)(&BusReg))->SubordinateBusNumber = 0xFF; if (Info.SecondaryLatency) ((PBRIDGE_BUS)(&BusReg))->SecondaryLatencyTimer = (BYTE)Info.SecondaryLatency; PCIConfig_Write(Bus, Device, Function, PCIBRIDGE_BUS_NUMBER, BusReg); ...

While enumerating the PCI bridges, stepping over the yellow-marked source code line on the 2nd PCI bridge instance (Bus 00, Dev 1C, Fun 01, 8086 0F4A), the device "hangs". If you, however, skip this yellow-marked source code line (i.e. do NOT execute, Set Next Statement on the next source code line), there is no problem and you can continue debugging.

What is this code doing?
The BIOS already executed the PCI bridge enumeration and had filled in the SecondaryBusNumber and SubordinateBusNumber. PCIBUS.DLL in Windows CE actually re-executes the bus enumeration during startup (and finds the same enumeration order). While recursively enumerating the PCI busses, it needs to pass-through all PCI Configuration accesses to the secondary bus "under investigation". Therefore it needs to write - temporarily - SubordinateBusNumber = 0xFF, allowing all accesses to flow downwards the secondary bus. So you might expect this is not a problem. We are just filling in the same numbers. But it isn't in this particular case.

I admit that I do not fully understand the problem. My closest guess is that when SubordinateBusNumber == 0xFF is filled in, the PCI configuration accesses to the PCI based KITL NIC (Bus 04, Dev 05, Fun 00, 10EC 8139) get lost (redirected) through this bridge (Bus 00, Dev 1C, Fun 01, 8086 0F4A). Failing KITL, hence the "hang" of the device during debugging. Actually the device is still alive, but the VisualStudio Platform Debugger lost its connection with the NIC. It can also explain why there is no problem on a RELEASE build.
But why aren't the PCI configuration accesses lost when enumerating the first bridge (Bus 00, Dev 1C, Fun 00, 8086 0F48) instance then? And why haven't I seen this problem on other hardware platforms before? And does the KITL NIC driver need to access the PCI configuration registers in running condition? Puzzling...

At least skipping this line of code (during boot, but annoying) brought back my debugging possibilities on this hardware.

If anyone has a better explanation for this problem, or a solution how to fix it, feel free to let me know...

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/hfm

Print | posted on Wednesday, October 21, 2015 9:56 AM | Filed Under [ Windows CE Windows Embedded Compact Microsoft Visual Studio 2012 Visual Studio 2013 Intel PCI Debugging ]