PCIE gen 4 RX cannot enter compliance mode

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

Hi Nvidia:

I do compliance test for PCIE recently.
The PCIE gen3 TX, RX and gen4 TX are all pass.
But PCIE gen4 RX can not be test.
It’s seem to can not enter compliance mode.
I follow step of tuning guide and use these patch files in the figure below, it still can not do PCIE gen4 RX SI test.

image
image1194×353 53 KB

What do I do to check PCIE enter compliance mode or not?
Is there other way to let PCIE gen4 enter compliance mode?

Best regards,
Ben

3

Is this jeptack5 or jetpack6? Which patch you are talking about?

4

Hi Wayne:

We use jeptack6.
The patch files are show below table from tuning guide.

image
image1125×356 52.5 KB

Best regards,
Ben

5

please attach your so-called patch file here for me to double check.

6

Hi Wayne:

Please refer to the attachment, thank you.

Best regards,
Ben

PCIE PATCH A_B.zip (986 Bytes)

7

The power down patch is out of date. Please use this one for rel36. The one you are using is for rel-35.

diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index a44b477cee27..937d7019fbb1 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -2193,10 +2193,12 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)

        pcie->link_state = tegra_pcie_dw_link_up(&pcie->pci);
        if (!pcie->link_state) {
-               ret = -ENOMEDIUM;
-               goto fail_host_init;
+               dev_err(dev, "Disabling PCIe power down\n");
+               ret = 0;
        }
 
+       pcie->link_state = true;
+
        name = devm_kasprintf(dev, GFP_KERNEL, "%pOFP", dev->of_node);
        if (!name) {
                ret = -ENOMEM;
8

Hi NV:

We use this codes you supply, and do compliance test again.
But the situation is still the same.
Is there anything else we can confirm?
Thank you for your opinion.

Best regards,
Ben

9

Are you sure the patch is applied correctly?

Did you see every pcie controller shown in your lspci even when no device is connected?

10

Hi NV:
Please refer to PIC as below.

image
image1534×237 15.5 KB

Best regards,
Ben

11

please share me the full dmesg.

12

Hi NV:

Please refer to attachment, thank you.

lspci-1729049392.txt (31.4 KB)
dmesg-1729049366.txt (60.0 KB)

Best regards,
Ben

13

please check command.

busybox devmem 0x20041000

If bit 12 is 1, then it means SSC is disabled on PLLE. Which means all the patches are applied correctly.

12|PLLE_SSCBYP : → 0 enables spreading, 1 disables spreading.

14

Hi NV:

The value read back from devmem shows that bit 12 is 0, which is not as expected. I have attached the bpmp-dtb-file generated based on the document. Please help to check where the problem is or if it’s possible to disable spreading directly on-site through devmem.

Best regards,
Ben

15

looks like attachment is missing.

16

Sorry, please refer to attachment.
tegra234-bpmp-3767-0000-a02-3509-a02-PCIe_Compliance.zip (23.1 KB)

17

Hi Ben,

Sorry that the register for your case are below.

0x211f0000 CLK_RST_CONTROLLER_PLLNVHS_SS_CNTL_0

0x21350000 CLK_RST_CONTROLLER_PLLGBE_SS_CNTL_0

Please check the bit 12 from these register. They indicate the SSC is enabled/disable.

Also, one question here. What is the exact PCIe controller that cannot enter compliance mode here? I mean which one do you want to test?

21

Hi NV:
We want to test this port.(PCIE0)

image
image1575×604 143 KB

Best regards,
Ben

22

Hi Wayne
The value of bit 12 from both of these registers is read as 1.
$ sudo busybox devmem 0x211f0000
0x1F011025

$ sudo busybox devmem 0x21350000
0x1F011C25

23

Hi Wayne

Is there any follow-up update for this issue?

24

All the setting is correct. Seems not software side patch missing problem.