Trying to get the 8641D to act as a PCIe endpoint

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Trying to get the 8641D to act as a PCIe endpoint

1,169 Views
cw_rick
Contributor I

We can get other endpoint products to respond correctly to our 8641D root complex but not an 8641D configured as an endpoint.

The setup we are trying to get working is to have two 8641s communicating with each other across a backplane, one as a PCIe root complex and the second as a PCIe end-point. We cannot seem to get the 8641 end-point to respond with its vendor and part ID even though the LTSSM register claims the link is trained up as a x4 connection and waiting in L0 state in both directions.

We have verified that the POR Boot Mode Status Register bits 13 and 14 do read the 00h which set the 8641D’s  SD1 controller to Endpoint (PEX) mode.

 

Examples of what does work:

Example 1 - From our 8641 root complex we can successfully communicate with a PLX PEX8532 PCIe switch and get it to return its ID. 

<S-A0>mw dff08000 80000018         //enable config access and set the register number to  18

<S-A0>mw dff08004 0001ff00          //write configuration data to setup bus structure

<S-A0>mw dff08000 80010000        //enable config access and set the register number to  00

<S-A0>md dff08000                             //read back device and vendor ID

DFF08000: 80010000 B5103285 00000000 00103F28

DFF08010: 00103F28 00000028 00000000 00000000

 

Example 2 - From our 8641 root complex we can successfully communicate with a Curtiss/Wright XMC-442 card with PCIe endpoint and get it to return its ID.

<S-B0>mw dff08000 80000018

<S-B0>mw dff08004 0001ff00

<S-B0>mw dff08000 80010000

<S-B0>md dff08000

DFF08000: 80010000 ECCC4204 00000000 0010FFFF

DFF08010: 0400FFFF 00000028 00000000 00000000

DFF08020: 00000000 00000000 00000000 00000000

DFF08030: 00000000 00000000 00000000 00000000

DFF08040: 00000000 00000000 00000000 00000000

 

 

Example of what does not work:

From our 8641 root complex we cannot get the 8641 end-point to return its ID.

<S-A0>mw dff08000 80000018

<S-A0>mw dff08004 0001ff00

<S-A0>mw dff08000 80010000

<S-A0>md dff08000

DFF08000: 80010000 FFFFFFFF 00000000 00103F28

DFF08010: 00103F28 00000028 00000000 00000000

DFF08020: 00000000 00000000 00000000 00000000

 

We have checked every register inside the 8641 that we can find and they all agree the part is setup as an end-point.

Any suggestions on what we might be doing wrong?

Thanks

Rick Collier

Curtiss-Wright Controls Embedded Computing

741-G Miller Drive

Leesburg, VA  20175

Office: +1 (703) 779-7800 ext. 326

Fax:    +1 (703) 779-7809

rick.collier@curtisswright.com

0 Kudos
1 Reply

426 Views
quintont
Contributor I

I ran into this same problem and finally stumbled on the solution. I wanted to make sure that the solution is available for other users who might run into the same thing, although I'm sure 'cw_rick' has long since made it past this stumbling point.

 

The solution is that the 8641D (or P2020, etc.) PCI Express endpoint must set the PEX_CFG_READY[CFG_READY] bit, where PEX_CFG_READY is an internal config space regsiter (0x4B0 on the P2020). Until this bit is set, all config space requests from external hosts will complete with the configuration request retry status (CRS), meaning that the read/write fails, usually after a timeout. The proper behavior is to set up the endpoint registers as required, then set the PEX_CFG_READY[CFG_READY] bit and from there, hosts will be able to enumerate the device.

 

Hope this helps someone out there!

0 Kudos