Xavier NX and PCIE0 lane allocations, pinmux script inconsistency

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
,
1

Hi,
I’m trying to get ASM3142 chip working on Xavier NX. The chip is wired to USBSS and lanes 1 and 2 of PCIE0. Lanes 3 and 4 are unused. Otherwise the configuration is similar to the reference design. It appears that the PCIE0_RST remains pulled low (cannot yet verify what pulls it low, though) and dmesg says “tegra-pcie-dw 141a0000.pcie: PCIe link is not up…!”.

If the PCIE0 bus only occupies two lanes, does it need to be explicitly configured to that if other lanes are simply not used, and what is the correct way to do this on Xavier NX?

Some documents tell to set uphy-lane values and set UPHY_CONFIG to point to that file, but only such example config seems to be for p2972. There are num-lanes -values for the buses in devicetree, and those have been changed to 2 in the config. Anything else need to be configured?

One inconcistency got my attention in dts2cfg -script:
The excel pinmux-sheet exports the reset-pin as “pex_l5_rst_n” in pinmux DTSI file. However, the dts2cfg configuration (Linux_for_Tegra/kernel/pinmux/t19x/addr_info.txt) contains name “pex_l5_rst_n_pgg1” and therefore the script does not export this pin to pinmux.cfg. The similar applies to pin pex_l5_clkreq_n (pex_l5_clkreq_n_pgg0). Is this correct and does the pin really get initialized ok? I tried renaming pins in the excel exported file to get the configuration created, but it breaks the flashing procedure.

Does the pad voltage dtsi file (and corresponding dtb) have any role in actual initialization the hardware or is it just an intermediate file for .cfg file? Including the dtsi in the kernel device tree causes an error if any IO_PAD_VOLTAGE_OFF values exist.

3

It is not clear if a custom-designed baseboard is being used here. Could you please confirm?

I didn’t understand the following part. It looks like the connection is there for 3 lanes (USBSS and Lanes 1,2). PCIe usually uses an even number of lanes.

Could you please specify the exact configuration of lanes?

4

The chip utilizes both USB and PCIe interfaces:

  • USBSS configured as USB3 interface (pins RX_P, RX_N, TX_P, TX_N)
  • PCIE0, lanes 1 and 2 (PCIE0_RX0_P, PCIE0_RX0_N, PCIE0_TX0_P, PCIE0_TX0_N, PCIE0_RX1_P, PCIE0_RX1_N, PCIE0_TX1_P, PCIE0_TX1_N).

And yes, it’s a custom carrier-board.

My main concern is the PCIE0_RST initialization. The voltage level of PCIE0_RST remains at 180mV and it is driven to that by Xavier NX (confirmed by disconnecting the line to the other chip). It changes a few times to 0 and 1.82V during system reset. It is configured as PE5_RST_L Output in pinmux config excel-sheet.

The absence of pin configuration can be reproduced as follows:

  1. Export the DTSI files from unmodified Jetson_Xavier_NX_Pinmux_Configuration_Template_v1.06.xlsm
  2. Modify the template by changing the PCIE0_RST customer usage to “unused_PEX_L5_RST_N” (and change direction, 3.3V tolerance and LPDR Enable to comply with the configuration). Export the modified data to DTSI files.
  3. Create pinmux config files with kernel/pinmux/t19x/pinmux-dts2cfg.py (from R32.4.4) from both DTSI sets
    → the pinmux configuration files are identical. This correct?
5

Any info yet? It would be good to know at least if there is a bug in the conversion script data, even if the solution was not yet provided.

6

Sorry, there was a misunderstanding about the usb: it only utilizes the two lanes of PCIE0, not USB.

The problem still remains.

7

Hi,

I am also not sure what is the exact problem now.

Do you mean you want to wire out pcie0 and and use 2 lanes here?

If so, what is your problem with USBSS?

And what have you changed in pinmux?

8

The USBSS -issue was just a misunderstanding, not related to the issue (it was incorrectly documented as being used by the chip, but actually not used at all).

The problem I am working on, is that I am unable to get a ASM3142 chip (wired to the lanes 0 and 1 of PCIe controller 5) to be detected in Linux. What made me wondering during the process, was related to the pinmux-dts2cfg.py, or more closely, to addr_info.txt for t19x platform:

The version 32.4.4 pinmux conversion script seems to be expecting different names for at least two certain pins than what the pinmux excel sheet generates, and therefore those lines never get to the generated cfg file:

  1. look at the file Linux_for_Tegra/kernel/pinmux/t19x/addr_info.txt lines 141 and 142:
    expected pin names are pex_l5_clkreq_n_pgg0 and pex_l5_rst_n_pgg1
  2. generate dtsi files from the latest Xavier NX pinmux excel sheet, and look at the pin names in pinmux dtsi file:
    pex_l5_clkreq_n and pex_l5_rst_n

Because the names mismatch, the generated pinmux cfg file does not get those pin configs. Is this a mismatch in the pinmux excel-sheet and addr_info.txt, or are those pins intentionally left out from the boot config?

If I modify either the addr_info.txt or the dtsi file to match those names, the config lines do get included to the config file, but the flashing process fails.

Resulting misconfiguration of those pins could explain the problems that I am facing. Could you check the correctness of those two files so I can rule out this possibility for the list of possible causes? The instructions to reproduce the error is described my earlier message in this thread.

9

Hi,

I don’t quite understand what is wrong here.

Do you mean the ball name in spreadsheet is “pex_l5_clkreq_n” but the addr_info.txt gives you “pex_l5_clkreq_n_pgg0”?]

But every pin here is using the same way, isn’t it?

10

The configuration for pins PCIE0_CLKREQ and PCIE0_RST does not get created in the pinmux.cfg file.
(by pinmux.cfg file I mean the pinmux output created by the script pinmux-dts2cfg.py)
I have checked this several times.

If you read the pyhon script, it appears that the first column of addr_info.txt contains the names that it expects the dtsi file to contain. And only if the pin names match, it creates a config line for that pin. To me, it looks like it’s meant to create those configs because the addr_info.txt contains a rows pex_l5_clkreq_n_pgg0 and pex_l5_rst_n_pgg1.

If those pins are not needed to be configured at all in the bootloader pinmux, it’s OK, but can you confirm this? Or if the config is needed in the bootloader, please check the excel sheet and addr_info.txt.

Are we looking at the same files, because in my data, most of the pins are named the same way in both files, with few exceptions.
I refer to these files:

  • Jetson_Xavier_NX_Pinmux_Configuration_Template_v1.06.xlsm
  • pinmux script and config in Linux_for_Tegra/kernel/pinmux/t19x
    of package Tegra186_Linux_R32.4.4_aarch64.tbz2

Are these the correct ones for Jetson Xavier NX?

11

Hi,

This is a snippet from my addr_info.txt. Every of them is using ball name + GPIO pin name.

  touch_clk_pcc4,         GP,             TOUCH,          RSVD2,          RSVD3,          0x2000,         1
  uart3_rx_pcc6,          UARTC,          RSVD1,          RSVD2,          RSVD3,          0x2008,         1
   uart3_tx_pcc5,          UARTC,          RSVD1,          RSVD2,          RSVD3,          0x2010,         1
   gen8_i2c_sda_pdd2,      I2C8,           RSVD1,          RSVD2,          RSVD3,          0x2018,         1
   gen8_i2c_scl_pdd1,      I2C8,           RSVD1,          RSVD2,          RSVD3,          0x2020,         1
   spi2_mosi_pcc2,         SPI2,           UARTG,          RSVD2,          RSVD3,          0x2028,         1
   gen2_i2c_scl_pcc7,      I2C2,           RSVD1,          RSVD2,          RSVD3,          0x2030,         1
   spi2_cs0_pcc3,          SPI2,           UARTG,          RSVD2,          RSVD3,          0x2038,         1
   gen2_i2c_sda_pdd0,      I2C2,           RSVD1,          RSVD2,          RSVD3,          0x2040,         1

Let me check if the pex_l5 would be generated by spreadsheet.

14

Yes, this is the correct file at least for the first rows. As said, most of the pins are named accordingly, but have you compared the lines 141 and 142 to the namings to the exported dtsi files?

Lines 141 and 142:
pex_l5_clkreq_n_pgg0, PE5, RSVD1, RSVD2, RSVD3, 0x14000, 0
pex_l5_rst_n_pgg1, PE5, RSVD1, RSVD2, RSVD3, 0x14008, 0

15

Hi,

Do you want to say

You see"pex_l5_clkreq_n" in dts file but other pex pins are named something like “pex_l4_rst_n_pl1”?

So you wonder either the addr_info.txt or the pinmux spreadsheet is wrong?

16

No, I know pex_l4 and pex_l5 are different signals, but pin C5 CLKREQ and RST signals are named different between addr_info.txt and exported pinmux dtsi:
pex_l5_clkreq_n_pgg0 — pex_l5_clkreq_n
pex_l5_rst_n_pgg1 — pex_l5_clkreq_n

17

Yes, that is what I wanted to say. pex_l4 is just an example.
All other pex l0~l4 have their gpio pin name but l5 does not have it in dts.

Let me check this internally.

18

Thank you. By studying kernel sources, it seems that the addr_info.txt is named correctly (names with _pgg0 and _pgg1 suffix exist in the kernel sources) and it is the excel sheet that exports incorrectly named data.

19

Hi @juho.roine,

  1. This pin is different from other pex pins. pex_l5_clkreq_n is not able to be configured to GPIO (you shall see no option in spreadsheet), thus the pinmux cfg file may not have it.

  2. You are not asking to configure this pin as GPIO, right?

20

No, I’m not trying to configure it as GPIO.
I would like to change the pull-up/down -params of PEX_L5_RST and PEX_L5_CLKREQ. Because of the issue, the config does not get into pinmux cfg file like it does with other pins. Should it?

21

Still waiting for internal reply. Just tried to confirm your purpose.

22

Ok, thank you.
When you get the response, please let me know asap (even if the solution is not yet available).

24

Hello,

Per checked this internally.

This is not a bug. It is by design and the reason is that the C5 controller’s pex_rst and clkreq signals pinmux configuration registers are present in C5’s power domain and not in VDD_SOC. Since C5 is not unpowergated by the time MB1 comes into picture, MB1 can’t really touch these registers which are in C5’s power domain. Hence, these registers are skipped from the pinmux cfg file and if you want to do any configuration, please update the kernel DT file @ hardware/nvidia/soc/t19x/kernel-dts/tegra194-soc/tegra194-soc-pcie.dtsi#23 directly.

The cfg file is designed as that on purpose.