How to let the M.2 work on tx2?

Hi,
I have a brand new tx2, and only runs the installer.sh in the /home/nvidia/NVIDIA-INSTALLER folder.
My M.2 video capture card can be found by lspci on tx1, but can’t be found on tx2.
The version is (uname -a)
Linux tegra-ubuntu 4.4.15 #1 SMP PREEMPT Wed Feb 8 18:06:32 PST 2017 aarch64 aarch64 aarch64(GNU/Linux)

How should I do to let the M.2 work on tx2?

I would recommend flashing the newest L4T version as a start.

Does the capture card show up with “sudo lspci” on both the working and non-working system? In the case of the non-working system, assuming lspci shows up, you will see some numbers on the left, e.g., they will look something like:

01:00.0

…this is a slot ID, and you can limit the lspci query with this. Just as an example I will use “01:00.0”, but adjust for your system.

To get a verbose list run:

sudo lspci -s 01:00.0 -vvv

This testing so far is entirely a test of PCI bus content. I suspect the M.2 slot is working as expected and the failure has nothing to do with PCI. Once PCI detects a device it will announce to drivers what device is there, and if a driver can handle that device, then device special files and other content produced by the driver will appear, e.g, a video device which might be found as “/dev/video0” is a result of the driver, and without the driver the device would never appear…even if PCI has done its job (PCI has a driver for the bus…it doesn’t have a driver for the device the bus talks to). You do need to first determine if PCI is functioning.

One way of gaining more information is to run the same lspci command on the working system, then compare it to the system where it doesn’t work. On the working system it would also be useful to know the output of “lsmod” while the device is present…this could reveal driver details.

1.I use git to clone the source ,and execute “source_syn.sh -t tegra-l4t-r28.1” to check out kernel.
Then I compile and reflash with the new kernel image, the version is
“Linux tegra-ubuntu 4.4.38 #2 SMP PREEMPT Tue Nov 21 15:40:36 CST 2017 aarch64 aarch64 aarch64 GNU/Linux”.

2.I plug a M.2 capture card by using a M.2 to PCIe adapter into PCIe slot(card 1), and plug another M.2 card
into the M.2 slot(card 2).

3.The card 1 can be detected, but card 2 can’t.The result is same as the brand new which we bought few days
ago. Below is the UART log of dmesg.
You can see that the “link 2 down”, and the PCI can’t list/detect the ID of the device in M.2 slot.
Both of the cards can work properly in the PCIe slot, but I also need the card can work in the M.2 slot.
How to let the PCI list the device in the M.2 slot?
Thanks.

root@tegra-ubuntu:/home/nvidia# dmesg | grep pci
[ 0.142796] node /plugin-manager/fragment-500-pcie-config match with board >=
[ 0.143507] node /plugin-manager/fragment-500-e3325-pcie match with board >=3
[ 0.263615] iommu: Adding device 10003000.pcie-controller to group 50
[ 6.359536] tegra-pcie 10003000.pcie-controller: 4x1, 1x1 configuration
[ 6.370932] tegra-pcie 10003000.pcie-controller: PCIE: Enable power rails
[ 6.378849] tegra-pcie 10003000.pcie-controller: probing port 0, using 4 lane
[ 6.390461] tegra-pcie 10003000.pcie-controller: probing port 2, using 1 lane
[ 6.836779] tegra-pcie 10003000.pcie-controller: link 2 down, retrying
[ 7.248788] tegra-pcie 10003000.pcie-controller: link 2 down, retrying
[ 7.846774] tegra-pcie 10003000.pcie-controller: link 2 down, retrying
[ 7.854764] tegra-pcie 10003000.pcie-controller: link 2 down, ignoring
[ 7.861625] tegra-pcie 10003000.pcie-controller: PCI host bridge to bus 0000:
[ 7.868959] pci_bus 0000:00: root bus resource [mem 0x50100000-0x57ffffff]
[ 7.875847] pci_bus 0000:00: root bus resource [mem 0x58000000-0x7fffffff pre
[ 7.883170] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 7.888689] pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
[ 7.894903] pci 0000:00:01.0: [10de:10e5] type 01 class 0x060400
[ 7.901012] pci 0000:00:01.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 7.913392] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), rec
[ 7.913528] pci 0000:01:00.0: [12ab:0371] type 00 class 0x048000
[ 7.913570] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x01ffffff]
[ 7.913616] pci 0000:01:00.0: reg 0x24: [mem 0x00000000-0x00000fff]
[ 7.913699] pci 0000:01:00.0: supports D1
[ 7.913701] pci 0000:01:00.0: PME# supported from D0 D1 D3hot
[ 7.919782] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 7.919840] pci 0000:00:01.0: BAR 8: assigned [mem 0x51000000-0x53ffffff]
[ 7.919844] pci 0000:01:00.0: BAR 0: assigned [mem 0x52000000-0x53ffffff]
[ 7.919851] pci 0000:01:00.0: BAR 5: assigned [mem 0x51000000-0x51000fff]
[ 7.919857] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 7.919864] pci 0000:00:01.0: bridge window [mem 0x51000000-0x53ffffff]
[ 7.919934] pcieport 0000:00:01.0: enabling device (0000 -> 0002)
[ 7.920027] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[ 7.920029] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[ 7.920034] pcie_pme 0000:00:01.0:pcie01: service driver pcie_pme loaded
[ 7.920109] aer 0000:00:01.0:pcie02: service driver aer loaded

Under U-Boot flash isn’t required to add a new kernel…it’s just a file copy…either modules to the module directory, or Image to “/boot” (preferably with an alternate name and extlinux.conf edit). When you say you flashed the new kernel, what steps did you take?

It would still be very useful to see specifically what the PCI bus is seeing (dmesg won’t show everything):

sudo lspci -vvv

Some M.2 cards are actually USB devices, is there a specific model we can look up to see specs for? In the case where the card does show up, is this determined via lspci, via the device special file, or just with dmesg?

[A] Below are my steps for reflashing tx2
1.I follow the l4t_quick_start.html to extrace the R28.1 and rootfs.
1.1 sudo tar xpf Tegra186_Linux_R28.1_aarch64.tbz2
1.2 cd Linux_for_Tegra/rootfs/
1.3 sudo tar xpf …/…/Tegra_Linux_Sample-Root-Filesystem_R28.1_aarch64.tbz2
1.4 cd …
1.5 sudo ./apply_binaries.sh

2.The I follow the l4t_kernel_custom.html to get and compile the sources.
2.1 sudo ./source_sync.sh -t tegra-l4t-r28.1
2.2 Follow the “Building the NVIDIA Kernel” section to compile the source.

3.Reflash the new images by usb
3.1 Connect the tx2 with desktop by usb cable
3.2 Let tx2 to enter the “USB Recovery Mode”
3.3 sudo ./flash.sh jetson-tx2 mmcblk0p1

[B] So, What do you mean about “I would recommend flashing the newest L4T version as a start.”?
[C] sudo lspci -vvv can’t get any message, since the card can’t be detected by the PCI driver in the M.2 slot.
If I put the M.2 card by the PCIe adapter in the PCI slot, then I can get the information from the
“lspci-vvv”. Please check the attached.
Link for the M.2 card
http://www.yuan.com.tw/products/capture/m2/sc540n1_m2_type-a-e_hdmi.htm
lspci_vvv.txt (6 KB)

What this did was flash an entire new operating system…it wasn’t just a kernel flash, although loading an empty system with a new operating system does add a kernel. It sounded like you used a flash command to try to update a kernel and nothing else.

I do not know if the procedure to create a new kernel actually places that kernel into the image which was flashed. The process of the flash mostly creates a file system image from “rootfs/”, but arguments passed to flash.sh determine some of the content in “rootfs/boot/”. After the flash is complete you will see file “rootfs/boot/Image”. It is this file which was actually flashed. I suggest taking a checksum of this file and of the Image file you expected and see if they match, e.g., from the “rootfs/boot/” directory you can run “sha1sum Image”, and then again from the directory where your source created a new Image.

If these do not match it is a simple file copy to put the new Image into a running Jetson. My guess is that your compiled version did not make its way into “rootfs/boot/”. Do note though that if the driver is built in the form of a module you don’t need to copy an entirely new kernel, you’d just install the module.

The lspci does show that PCI sees your device, but it doesn’t know what it is (a sign that no driver was found which would also suggest you were correct that you were missing a driver). The device is capable of PCIe v1 speeds, and is operating at that speed without error (though the device does not have advanced error reporting, so error information is limited).

What is the meaning of “a sign that no driver was found which would also suggest you were correct that you were missing a driver”?
I can use the lspci to list the device in M.2 slot on tx1 without adding extra driver.
So, I think tx2 should be same as tx1, and all the pci drivers should be in the kernel source.
Currently, I use the tegra18_defconfig to build my kernel, do I missing some configs which are need to enable?

The PCI bus enumerates and passes on information provided by the PCI device. Your lspci shows this occurred as expected. Further information about the device is not found, other than perhaps describing this as needing a driver which is specific to the device (there are no generic drivers known for the device). The lack of this further information implies the driver specific to the card is itself missing…this isn’t the responsibility of PCI. Load the driver for the device (everything PCI is already loaded and working) and likely things will start working. The question is whether you’ve built a driver and actually made it available, or whether you built one and it didn’t make its way into the installation.

No PCI driver is involved with the issue…PCI is analogous to a road, and the road is there (lspci says so)…you’re missing the driver for your car(d). No operating system in the world installs 100% of all drivers, and embedded systems only install a certain known subset by default. The rest are optional installs. The kernel source is wide open for configuring to build and install almost anything…it just hasn’t been done yet.

NOTE: I recommend putting a default install in and making a copy of “/proc/config.gz”, then run it through gunzip. In the past tegra18_defconfig was a match to the running system, but I do not believe it is now. Even if it is, you still need to set CONFIG_LOCALVERSION, and then edit to include the driver you need. I do not know what driver this particular card requires…perhaps you can post the exact specification of the card model (this won’t care whether it is an M.2 card or full PCIe slot card).

My default from L4T R28.1 “/proc/config.gz”:

config-4.4.38-tegra_tx2.txt (139 KB)

Is there any M.2 device can be list on Jetson TX2?
I bought two intel wifi cards, but they also can’t be found by lspci.
Wireless- AC 8260 : https://www.amazon.com/Wireless-8260AC-8260NGW-Bluetooth-Wireless/dp/B01ERMBDCK
Wireless-AC 7265 : https://www.amazon.com/Intel-Wireless-AC-802-11ac-Wi-Fi-Bluetooth/dp/B00STV5UKW

How does NVIDIA to verify the M.2 is working?

Many WiFi cards need firmware to function, but they should be visible in lspci if they are PCI(e). If visible it does not mean the card will work without the correct firmware and driver.

FYI, that slot has both a USB interface and PCIe x1. A card using that slot may not be PCIe. If that is the case, then lsusb might show something.

On the first URL I see this (which shows after a number of restrictions to use only on particular versions of Windows and particular versions of an Intel CPU…both of which are missing in the Jetson):

Important Notice: Please must check and confirm your computer's motherboard whether open USB bus before purchase, because this card is going Bluetooth USB bus, if the motherboard does not open the USB bus, then it's unable to use Bluetooth function, also in the device manager cannot identify the new USB Bluetooth hardware.

…perhaps there is also PCIe used in addition to USB, but mostly what I can see is that this is a USB device.

I did not see information on the second URL, but since they are both Intel for the same slot, there is a strong chance that they have the same design…both are probably USB.

What does lsusb show?

root@tegra-ubuntu:/home/nvidia# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I don’t know what devices you have already on USB, but one of these two might be for your card (or might not be…look to see what it says):

sudo lsusb -d 8087:0a2b -vvv
sudo lsusb -d 046d:c534 -vvv

The “Intel” one ("-d 8087:0a2b") seems like a good possibility for being the M.2 card.

Hi jb035.cheng,

I think you need to changed ODMDATA to 0x90000. Because default ODMDATA is 0x1090000 and there is only one PCIe x4 on this configuration.

Hi Gary,
After changing to 0x90000, I can use the lspci to get the device ID, thanks.

Where is this ODMDATA at?

Hi BConklin,
The ODMDATA is in “Linux_for_Tegra/p2771-0000.conf.common”