Host/PCI Bridge

Comments and questions related to the "Down to the TLP" pages

Host/PCI Bridge

Postby Guest »

Hi,

I have a question about enumeration and the distinction between the Host/PCI bridge and a P2P bridge in the Root Complex.
I understand that in the enumeration process you poll Bus 0, Device 0, Function 0 and verify a valid Vendor ID and in my case that the device is a bridge. You then update the Primary bus = 0, Secondary bus = 1, and the Subordinate bus = 1 in the configuration space for BDF 0,0,0. (I realize the subordinate bus can be updated at the end but this is part of the question.) In some explanations of the process that I've read, it says that you also need to update the subordinate bus number on the Host/PCI bridge. How does one do this? It seems to me that using the configuration address/data registers will just update the P2P bridge and not the Host/PCI bridge. Any explanation would be greatly appreciated.

Thanks in advance.
Guest
 

Re: Host/PCI Bridge

Postby support »

Hi,

Your question is a bit in the air. What platform are you using, and why are you in a need to enumerate anything?

For example, on my PC, I get

$ lspci
00:00.0 Host bridge: Intel Corporation Clarksfield/Lynnfield DMI (rev 11)
[ ... and it goes on ... ]

Clearly, if two devices on the bus would talk to each other, and the root complex is in the middle (i.e. no switch in the middle that could tell a shorter path), the packet would enter the host bridge, and then get routed back to the peer on the bus, instead of the host.

Where have you seen a distinct P2P bridge? As far as I know, the packets are just relayed following routing rules that are kept in either switch or bridge.

Eli
support
 
Posts: 802
Joined:

Re: Host/PCI Bridge

Postby Guest »

Sorry, I should have stated up front that I'm working on a bareboard system with no OS. We have an FPGA that implements the hardware portion of the PCIe, so it is up to our software to do the enumeration and configuration of the system. I have a development board currently that I am working with to get started. I am coding in C and using the debugger to find my way around. Using the PCIe config_addr and config_data registers I can trace my way down from the root complex to an ethernet card I'm using for testing purposes. I'm not sure yet what all will be on the actual PCIe network for our system.
The documentation I've been using is mostly from MindShare's PCI Express Technology book. Maybe this is the wrong forum for my question but I'm very new to PCIe. Most of the examples I've found searching on the Internet are based on using a Linux OS which don't really help me and finding forums to ask questions is difficult. Thanks.
Guest
 

Re: Host/PCI Bridge

Postby support »

Hi,

Unfortunately, I still can't understand what you're asking about. You're supposed to set the Ethernet card's register in the configuration space, and possibly your own root port's configuration space interface's registers as well. I've never done this myself (because I rely on Linux myself), but if I were you, I would just plug the card into a PC with Linux, do lspci with various verbosity levels (and some -x too), and copy whatever I found there, with adaptions. And use that to program the Ethernet card (or what I had).

Where have you found any bridges? Have you detected anything that identifies itself as a bridge? With those simple boards, I wouldn't expect it to be more complicated than setting the registers of one single device.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Host/PCI Bridge

Postby Guest »

Hi Eli,

Using the config_addr register, I read the configuration header at byte offset 0 for a device (starting at device 0) on bus 0 which is in the Root Complex. If I get back a valid Vendor ID, I then read the configuration header at byte offset 0xC which contains the header type. This tells me if this device is a bridge or an end point. If it's a bridge then I have to set the downstream bus number from this bridge to the next device on the bridge, and so on until I come to an end point (such as the ethernet port). As I go along I have to set the primary/secondary/subordinate bus numbers at each bridge in its configuration header space. So basically what I'm doing is what your Linux lspci returns. I'm essentially trying to code up some startup code similar to what the Linux OS would do on a reset, discover the PCIe network of devices installed.
The process is rather straight forward (although the logic can be a bit tricky), and I understand most of it so far, but the setting of the primary/secondary/subordinate bus numbers in the configuration header within the root complex has me baffled. If I could somehow add a figure into my posts that might help clear up the confusion.

Dan
Guest
 

Re: Host/PCI Bridge

Postby support »

Hi,

As far as I understand, you are the root complex. That means that if you want to set things in the configuration space, odds are that you'll do that with some PCIe-related registers in the host's address space. I'm can't be sure about this, but it doesn't sound very sensible to me to write to the configuration space of your own port. But the manual should explain this.

I would expect that you should only need to enumerate the endpoint that you have on the bus, so it knows what addresses to respond to (BAR), how to submit an interrupt + some other configurations (e.g. max payload).

Thinking about it, I can't see why the root complex needs to know anything about the bus' topology. Since there is only one PCIe port on the chip (right?), any packet with bus addressing should go out that specific port. How the switches handle this down the road is none of the root complex' business.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Host/PCI Bridge

Postby Guest »

I agree, it seems that the host should just pass along a message and let the downstream devices handle it. Thanks for the feedback. At this point, unless I come across some other information, I'm just going to set up the configuration spaces and see what happens once I've completed enumeration. Next up is setting addresses.

Thanks again.

Dan
Guest
 


Return to General PCIe