After L4T upgrade on TX2 custom carrier, a WiFi PCI device is no longer enumerated

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
1

Greetings,

On our mature custom TX2 carrier board, we successfully use UPHY Lane Configuration #6, with a custom DTB file, and L4T version 32.4. With this configuration we are able to utilize a WiFi module inserted into the M.2 interface.

We are in the process of upgrading to L4T 33.7.1 on the same TX2 carrier board. The WiFi module mentioned above is not detected and the device are no longer appears in the output of the lspci command. Inspection of the system regarding the use of UPHY Lane Configuration #6 all looks good and is included below. Is it possible that switching to L4T 33.7.1 requires changes to our DTB file? Are there any other possible causes we should consider?

Best Regards,
Todd

ODMDATA is correct
/# ./odmtool --read
Current ODMDATA value: 0x3090000

Lane mappings look good: pcie-controller: 2x1, 1x1, 1x1 configuration
/# dmesg | grep -i pcie
[ 0.000000] Kernel command line: console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=UUID=ba1eadef-edc1-4ce1-b7d5-86bc0a65e794 ro rootwait gasket.dma_bit_mask=32 pcie_aspm=off l4tver=32.7.1 isolcpus=1,2,3 sdhci_tegra.en_boot_part_access=1
[ 0.000000] PCIe ASPM is disabled
[ 0.535241] node /plugin-manager/fragment-500-e3325-pcie match with board >=3310-1000-500
[ 1.314953] iommu: Adding device 10003000.pcie-controller to group 49
[ 1.321702] arm-smmu: forcing sodev map for 10003000.pcie-controller
[ 2.258318] tegra-pcie 10003000.pcie-controller: 2x1, 1x1, 1x1 configuration
[ 2.276438] tegra-pcie 10003000.pcie-controller: PCIE: Enable power rails
[ 2.276785] tegra-pcie 10003000.pcie-controller: probing port 0, using 2 lanes
[ 2.278948] tegra-pcie 10003000.pcie-controller: probing port 1, using 1 lanes
[ 2.281108] tegra-pcie 10003000.pcie-controller: probing port 2, using 1 lanes
[ 2.770822] tegra-pcie 10003000.pcie-controller: link 0 down, retrying
[ 3.769473] tegra-pcie 10003000.pcie-controller: link 0 down, retrying
[ 4.181852] tegra-pcie 10003000.pcie-controller: link 0 down, retrying
[ 4.183866] tegra-pcie 10003000.pcie-controller: link 0 down, ignoring
[ 4.585247] tegra-pcie 10003000.pcie-controller: link 1 down, retrying
[ 4.988426] tegra-pcie 10003000.pcie-controller: link 1 down, retrying
[ 5.391131] tegra-pcie 10003000.pcie-controller: link 1 down, retrying
[ 5.399732] tegra-pcie 10003000.pcie-controller: link 1 down, ignoring
[ 5.810989] tegra-pcie 10003000.pcie-controller: link 2 down, retrying
[ 6.219192] tegra-pcie 10003000.pcie-controller: link 2 down, retrying
[ 6.637002] tegra-pcie 10003000.pcie-controller: link 2 down, retrying
[ 6.645151] tegra-pcie 10003000.pcie-controller: link 2 down, ignoring
[ 6.959125] tegra-pcie 10003000.pcie-controller: PCIE: no end points detected
[ 6.968751] tegra-pcie 10003000.pcie-controller: PCIE: Disable power rails

The values below match these expected values: pcie/lane2, pcie/lane4, sata/lane5, xusb/lane0 and xusb/lane1
/# ls -lah /proc/device-tree/chosen/plugin-manager/odm-data/enableuphy
/proc/device-tree/chosen/plugin-manager/odm-data/enable-pcie-on-uphy-lane2
/proc/device-tree/chosen/plugin-manager/odm-data/enable-pcie-on-uphy-lane4
/proc/device-tree/chosen/plugin-manager/odm-data/enable-sata-on-uphy-lane5
/proc/device-tree/chosen/plugin-manager/odm-data/enable-xusb-on-uphy-lane0
/proc/device-tree/chosen/plugin-manager/odm-data/enable-xusb-on-uphy-lane1

USB Controllers are showing up correctly
/# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/3p, 5000M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/7p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
|__ Port 2: Dev 7, If 0, Class=Hub, Driver=hub/7p, 480M
|__ Port 7: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 480M

CPU Isolation is correct
/# cat /sys/devices/system/cpu/isolated
1-3

2

Hi

  1. Suggest to check the odmdata through register reading instead of checking /chosen/plugin-manager.

  2. If (1) is correct, please also check rel32.5/32.6.1 is working fine or not.

3

  1. Both the odmdata register read and checking the plugin manager confirm configuration #6

    ODMDATA is correct
    # ./odmtool --read
    Current ODMDATA value: 0x3090000
    [/quote]

    plugin-manager is correct
    # ls -la /sys/firmware/devicetree/base/chosen/plugin-manager/odm-data
    enable-pcie-on-uphy-lane2
    enable-pcie-on-uphy-lane4
    enable-sata-on-uphy-lane5
    enable-xusb-on-uphy-lane0
    enable-xusb-on-uphy-lane1

  2. I can confirm configuration #6 running on L4T 32.4 will enumerate the WiFi module as well as other PCI devices. Will also test 32.5 and 32.6 as you requested. @AlexCo

4

Hi,

No, Register read is to read 6 registers and each of them represents the lane function of lane 0 ~5.

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3261/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/adaptation_and_bringup_tx2.html

image
image1833×687 61.6 KB

5

@WayneWWW Thank you for the clarification on the register reads.

The values read from the registers match the values expected for configuration #6
UPHY Lane 0 Value at address 0x2520284 (0x7f89dd5284): (0x00) XUSB
UPHY Lane 1 Value at address 0x2530284 (0x7fab32f284): (0x00) XUSB
UPHY Lane 2 Value at address 0x2540284 (0x7f9069d284): (0x01) PCIe
UPHY Lane 3 Value at address 0x2550284 (0x7f85c68284): (0x01) PCIe
UPHY Lane 4 Value at address 0x2560284 (0x7fb4074284): (0x01) PCIe
UPHY Lane 5 Value at address 0x2570284 (0x7f7c3a2284): (0x02) SATA

Will follow up with test results from 32.5 and 32.6 as you requested.

6

@WayneWWW Using the Nvidia sdkmanager I have installed Jetpack 4.5.1 (with L4T 32.5) on our custom carrier board. The odmtool --read command returns 0x1090000 (configuration #2). The custom carrier board is setup for configuration #6. I’m trying to sort out what Jetpack 4.5.1 file I need to change to have the flashing process set the configuration to #6. Does this configuration have to happen during flashing or is it possible to modify the odmdata value at any point in time?

7

You can only update it through flashing.

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.