AM5706: How to Change Vendor ID or Device ID of PCIe in AM5706

Hi Sarath,

PCIe device ID and vendor ID are defined as read-only register and are fixed. These are only to determine what kind of device is connected, and cannot be used for differentiating between two devices of the same type. For reference, here is the register description from TRM (https://www.ti.com/lit/ug/spruhz7j/spruhz7j.pdf):

However, I am assuming the intention of wanting to change vendor/device ID is to be able to differentiate AM5706 #1 from AM5706 #2. If this is the case, then devices are usually differentiated by a combination of PCIe bus number, device number, and function number which are separate from device ID and vendor ID. For example, in Linux, there is the lspci tool which would print out something like the following:

root@j7-evm:~# /usr/sbin/lspci
0000:00:00.0 PCI bridge: Texas Instruments Device b00d
0000:01:00.0 Non-Volatile memory controller: Phison Electronics Corporation Device 5013 (rev 01)
0001:00:00.0 PCI bridge: Texas Instruments Device b00d
0001:01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd Device a809
0002:00:00.0 PCI bridge: Texas Instruments Device b00d
root@j7-evm:~#

The above lspci example has an extra domain number (which not all systems have) associated, but the format of the output is "([domain:]bus:device.function) device class: vendor name, device name". The vendor name and device name come from device ID and vendor ID, but the rest needs to be assigned through software by probing the PCIe slots. As you can see, there are multiple devices with the same vendor and device ID which is common to have for systems that use PCIe devices, but they are differentiated using domain number.

If developing a new driver for an OS other than Linux, my recommendation is to reference the Linux driver code in probe.c: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pci/probe.c?h=ti-linux-5.10.y#n2586. Otherwise, if Linux is being used, the best way to differentiate one device over another is to use the devfn variable instead of device ID and vendor ID variables.

I made a big assumption about the intention of the question, so let me know if what I described answered your question. On the other hand, if I misinterpreted the intention, I would need your clarification on the question and issue being faced.

Regards,

Takuma

Hi Takuma,

At first a big thanks for giving quick and very good response. we're using VxWorks not linux on the RC side. But what assumption which you've taken was really helpful and we'll try to do the things with the bus:device.function.

Now, here one more thing that bugging us, the two devices were enumerated properly and the bar sizes are reflecting in RC fine. We're using pci_sample_code.c which is available in PDK for both AM5706 #1 and AM5706 #2. The read/write operation from RC to AM5706 #1 Bar 0 happening at offset 0x2000_0000 which is pci config space 1 and read/write operation from RC to AM5706 #2 Bar 0 happening at offset 0xB000_0000 which is DDR region, which we're thinking some kind of weird behaviour since both are not common. Since both devices are same is this is happening?, please guide us to understand the situation. 

Regards,

Sarath

Hi Sarath,

Thanks for the clarification! I understand the situation better.

It does look strange that when writing to Bar 0 on both AM5706 #1 and #2 results in writing to different offsets. I assume the two devices are supposed to be configured the same, hence when writing to Bar 0 for both AM5706 devices we are expecting it to be written to the same location instead of pci config space on one and DDR region in the other. I am guessing one thing that we are suspecting is Bar not getting configured by RC due to not being able to differentiate the two AM5706.

To check if Bar 0 is being configured correctly by RC, can you check the PCIECTRL_EP_PCIEWIRE_BAR0 register on the two AM5706s and see if the values are different? For reference, the register description is on page 6180 of the TRM (https://www.ti.com/lit/ug/spruhz7j/spruhz7j.pdf):

If Bar 0 is different between the two, we can narrow down the issue to the portion of the code that does Bar initialization. This other old E2E is pretty good at pointing out which part of the TRM is relevant for configuring Bar, so I think this can be used to see if there is a step that is being missed: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/886777/am5718-about-pcie-controller-base-address-registers

Regards,

Takuma

Hi Takuma,

Thanks for sharing the information about the configuring BAR, we have got very good insight into the PCIE Config Registers via PCIE WIRE and DIF CS/CS2 registers.

Now, coming to the problem the values of two AM5706s are same, But the  Bar 0 is not being configured correctly by RC. Although we're configuring the BAR as Memory type, The value which reflected in PCIECTRL_EP_PCIEWIRE_BAR0 tells that is IO type, attached the images for reference of PCIE_WIRE region along with DBICS and DBICS2 regions. We're in a situation now that we're really confused that where we're heading. Hoping that the attached images will give some insight to our problem, please help us in understanding the situation.

Regards,

Sarath

Hi Sarath,

It looks like the DBICS and DBICS2 registers are being used instead of the PCIEWIRE registers, based on the device/vendor ID registers being 0x8888 and 0x104C respectively.

I will need to do some research on how PCIEWIRE, DBICS, and DBICS2 relate to each other. However, I have noticed in one of the screenshots shared that the DBICS2_BAR0_MASK register has BAR_ENABLED set to 0x0. If DBICS2 is being used to configure Bar, this might need to be set to 0x1.

For reference, here is the register field description from the TRM:

I also see BAR0 set to 0x0000_0008, but since this is different from 0x2000_0000, and 0xB000_0000, could I get clarification on where the intended base address location is?

Regards,

Takuma

Hi Takuma,

The Inbound Base Address location is 0x7000 0000 and the Outbound Base Address location is 0x9000 0000, These values we're are not setting intentionally, These values we found in header file called pci_sample.h. So far in our efforts to understand the example code we found that the prefetching is not used and DBICS2 registers are not being configure anywhere, Hope these inputs will helpful to understand the situation we're facing.

Regards,

Sarath

Hi Sarath,

Apologies for the delay. I am currently trying to reproduce the issue on an AM572x board that I was able to obtain from a colleague - although it is not the same as AM5706, the SDK should be shared and they both have the DBICS and PCIEWIRE registers, so the flow for initializing PCIe should be similar between the two devices. Setting up this system on my end should give me a better idea of what is going on with the BARs for inbound/outbound by getting a good baseline to compare differences in system/registers/and behavior.

To make sure I can get a system that is most similar to the system you currently have, could I get the following information:

1. Is the version of the SDK being used PROCESSOR-SDK-RTOS-AM57X version 8.1, or an earlier version?
2. Is there a documentation or instructions that is being followed to set up PCIe on your end? For example, like this one (which I plan to follow unless otherwise specified): https://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/08_01_00_09/exports/docs/rtos/index_device_drv.html#pcie.

While I try to set up some experiments on my end, there is a debug FAQ for PCIe. If this has not been referenced yet, my recommendation is going through this documentation as well: https://software-dl.ti.com/processor-sdk-rtos/esd/AM57X/08_01_00_09/exports/docs/rtos/index_device_drv.html#debug-faq. Along with common issues with BAR, there are other common issues that are common to PCIe in general that are listed in the FAQ, so if you see some common issue on this FAQ that looks familiar to the issue being seen, it will give us a lot more information and good directions for next steps.

Regards,

Takuma

Hi Takuma,

1. Yes we are using PROCESSOR-SDK-RTOS-AM57X version 8.1 only.
2. we are following this example project to bring up the PCIe interface -> PCIE_idkAM571x_wSoCFile_armExampleProject

And yes we will go through the link that you have mentioned.

Regards,

Sarath

Hi Sarath,

Understood. I will be setting up some experiments with that version of the SDK + example.

Regards,

Takuma

HI Sarath and Takuma,

I am also facing the similar issue. Using AM5748 PCIe(RC) is connected to FPGA(EP).

Linkup was happened.

But I am unable to send the data from RC to EP. Same example code I am using.

I tried to change Inbound address location(0x70000000) and outbound address(0x90000000). Still it is not working.

Can you please give some more info on these Inbound and outbound location.

Thanks and regards,

S. Venkateswara Reddy

Hi Venkateswara,

One location to look at for BAR configuration could be here: https://www.ti.com/lit/ug/sprugs6d/sprugs6d.pdf?ts=1694816719555

I work mainly with the current generation AM6x devices, so I am also learning how the AM57x devices work differently than AM6x. So unfortunately, I will need some more time to determine where this 0x70000000 and 0x90000000 are coming from, and how this should be configured differently.

Regards,

Takuma

Hi Takuma,

We are still stuck with that issue, have you got any clue

Hi Sarath,

Venkateswara made another post here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1278440/am5748-sysbios---pcie-driver-issue

Unfortunately, I will need a significant amount of time to experiment and give a more experienced answer, but my suggestion would be to see if trying out the changes I mentioned in the separate E2E will cause an effect on BAR address.

Regards,

Takuma