TDA4VE-Q1: TDA4VE PCIE

Hi：

    The industrial computer is unable to obtain configuration space parameters。

I set:

cd /sys/kernel/config/pci_ep/
mkdir functions/pci_epf_test/func1
echo 0x104c > functions/pci_epf_test/func1/vendorid
echo 0xb00d > functions/pci_epf_test/func1/deviceid
echo 2 > functions/pci_epf_test/func1/msi_interrupts
echo 2 > functions/pci_epf_test/func1/msix_interrupts
echo 0x5 >functions/pci_epf_test/func1/baseclass_code
echo 0x80 >functions/pci_epf_test/func1/subclass_code
ln -s functions/pci_epf_test/func1 controllers/2910000.pcie-ep/
echo 1 > controllers/2910000.pcie-ep/start

Hi Kong,

I have two requests:

1. Can you make sure the defconfig file under <PSDK Linux installation>/board-support/linux-*/arch/arm64/configs for J721S2 is configured with the kernel configuration mentioned in the SDK doc: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/09_00_01_03/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html? If you can send the output from "zcat /proc/config.gz" on the EVM board, then we can also verify whether the correct Linux driver configuration is set.
2. On the industrial computer side, could you send the output from "lspci" assuming the industrial computer is running Linux? I assume that the TDA4VE is not being detected even from lspci since you mention that configuration space parameters cannot be obtained, but I would like to make sure if that is the case.

Regards,

Takuma

hi:

   the industrial computer is running Windows.

Hi Kong,

Could you try out 1 from my previous post?

Also, for 2, could you get the lspci equivalent for Windows? I assume there is a way to see if link training was completed for Windows to see if the PCIe device is linking up at a certain PCIe generation speed, and how many lanes are detected and such.

Regards,

Takuma

HI:

  Windows Unable to obtain configuration space。

#k3-j721s2-common-proc-board.dts
&pcie1_rc {
phys = <&serdes0_pcie_link>;
phy-names = "pcie-phy";
num-lanes = <1>;
status = "disabled";
};
&pcie1_ep {
phys = <&serdes0_pcie_link>;
phy-names = "pcie-phy";
num-lanes = <1>;
status = "okay";
};
#tisdk_j721s2-evm_defconfig
#
# PCI Endpoint
#
CONFIG_PCI_ENDPOINT=y
CONFIG_PCI_ENDPOINT_CONFIGFS=y
CONFIG_PCI_EPF_TEST=y
CONFIG_PCI_EPF_NTB=y
# end of PCI Endpoint
#!/bin/bash
cd /sys/kernel/config/pci_ep/
mkdir functions/pci_epf_test/func1
echo 0x104c > functions/pci_epf_test/func1/vendorid
echo 0xb00d > functions/pci_epf_test/func1/deviceid
echo 0x05 > functions/pci_epf_test/func1/baseclass_code
echo 0x80 > functions/pci_epf_test/func1/subclass_code
echo 2 > functions/pci_epf_test/func1/msi_interrupts
echo 8 > functions/pci_epf_test/func1/msix_interrupts
ln -s functions/pci_epf_test/func1 controllers/2910000.pcie-ep/
echo 1 > controllers/2910000.pcie-ep/start

Hi Kong,

It looks like device is detected, meaning link training was able to complete, and this is good. However, as you mentioned, configuration space is not configured.

One suspicion I have is that TDA4VE EP is getting reset. We mention in our SDK user guide that we take out the reset signal on the cable used in the EP example here: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j721s2/09_00_01_03/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html. The reasoning for this is that since we manually configure EP using command line, resetting EP will reset all of the command line configuration.

Can you see if you can connect to the EP after Windows tries to decode configuration space, and see if EP settings are still there? For example, is controllers/2910000.pcie-ep/start still "1"?

Regards,

Takuma

HI:

    controllers/2910000.pcie-ep/start still "1".

    but configuration space is not configured.

Can you see if you can connect to the EP after Windows tries to decode configuration space, and see if EP settings are still there? For example, is controllers/2910000.pcie-ep/start still "1"?

Hi Kong,

That is strange... just as a sanity check, can you also check vendorid, deviceid, and msi_interrupts/msix_interrupts are all configured after Windows decoding?

Regards,

Takuma

Hi：

    Vendor id, deviceid, and msi_ Interrupts/msix_ Enterrupts are all configured the same after Windows decoding.

Hi：

     Windows read the BAR space and found that the BAR space is discontinuous. The other BAR spaces are from small to large, and the printed ones are from large to small。The log is as follows

Hi Kong,

Do you have an extra TDA4VE, TDA4VM, or TDA4VH EVM? As an experiment, if you have another TI EVM, could you try doing the RC/EP demo between two TI EVM? I think as the first step, we should try to get the EVM to be configured as EP on a known working hardware setup, so that we can verify our initialization flow.

TI EVM<-> TI EVM setup should be tested as part of our SDK release, and I since am more familiar with this setup, I will be able to make some better comments on what could be wrong. I am a bit unfamiliar with how Windows will interact with our boards.

Regards,

Takuma

HI：

   Reading PCIE configuration space and discovering abnormal BAR space。

   0x10[BAR0]

Hi Kong,

If the two TI EVM experiment is hard to do, could you try to initialize more than 1 function? For example, initialize 6 functions and see if all 6 show up under Windows? It could be that we are not accessing the function that was created in command line, hence the abnormal BAR space.

Regards,

Takuma

HI：

   Initialize 6 functions, all 6 functions displayed under Windows. But the BAR space is still abnormal.

Hi Kong,

Understood. Let me see if I can reproduce this issue with a x86 PC. I expect about a week to conduct initial experiments and gather information, as this is a setup that I have not tried before, and I do not think we cover this in our SDK testing (aka, we only cover TI EVM <-> TI EVM testing).

One difference between the setup would be that I will be using a Linux PC instead of Windows, as setting up Windows would be additional time due to my current hardware setup.

Regards,

Takuma

Thanks

Do you have any results？

Hi Kong,

So far, I have not been able to recreate the issue on the x86 PC. My current setup is a x86 Ubuntu Linux PC configured as RC, connected by a PCIe cable to a TDA4VE configured as EP.

For example, here is what I can see from the x86 PC:

lspci_output_linux_x86_to_tda4ve.txt

From the above logs, the TDA4VE successfully enumerates 6 functions from 05:00.0 to 05:00.5 with non-zero BAR, and all of the configuration space can be read. As a note, this is when I run lspci -vvvx as superuser.

However, one thing I experienced that may be related to the issue is permissions. When running lspci -vvvx to get above logs, I could not print out capabilities saying <access denied> when I did not run the command as sudo (superuser). For example, a non-superuser running lspci -vvvx gets below:

05:00.5 Unassigned class [ff00]: Texas Instruments Device b00d
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 255
Region 0: Memory at 46ada900 (32-bit, non-prefetchable) [disabled] [size=256]
Region 1: Memory at 46ada200 (32-bit, non-prefetchable) [disabled] [size=512]
Region 2: Memory at 46ad9400 (32-bit, non-prefetchable) [disabled] [size=1K]
Region 3: Memory at 46ad4000 (32-bit, non-prefetchable) [disabled] [size=16K]
Region 4: Memory at 46aa0000 (32-bit, non-prefetchable) [disabled] [size=128K]
Region 5: Memory at 46900000 (32-bit, non-prefetchable) [disabled] [size=1M]
Capabilities: <access denied>
00: 4c 10 0d b0 00 00 10 00 00 00 00 ff 00 00 80 00
10: 00 a9 ad 46 00 a2 ad 46 00 94 ad 46 00 40 ad 46
20: 00 00 aa 46 00 00 90 46 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 01 00 00

Can you confirm that user or program used to read configuration space has admin privilege?

Regards,

Takuma