Does anybody know how to enable and program an SPI protocol on the TX1?

We are attempting to communicate an arduino MEGA board with the TX1 via SPI communication protocol and the research we’ve made so far isn’t helpful at all. We have seen that, in order to initiate the process suggested in this article “GPIO and SPI - NVIDIA Jetson TX1 - JetsonHacks” we need to configure the kernel and the device tree. We already tried to modify the configuration for our port with the information given by this page “Jetson/TX1 SPI - eLinux.org” but the GPIO Pinmux part didn’t changed as it was supposed to(also, the information is meant to be for cards flashed with the outdated version of jetpack 2.3.1).

We are running out of information sources. Could anybody help us?

The newer releases have different methods for updating device tree. If you followed old instructions the device tree changes might be what you need, and yet installing would have failed to actually do this. Which L4T release is this? E.g., “head -n 1 /etc/nv_tegra_release”.

You can extract your running Jetson’s device tree with:

dtc -I fs -O dts -o extracted.dts /proc/device-tree

…and you could check if your device tree edits actually made it in.

HI Linuxdev:
The L4T release that our TX1 is running is this:
NVIDIA Jetson TX1
L4T 28.2.0 [ JetPack 3.2 ]
Board: t210ref
Ubuntu 16.04.4 LTS
Kernel Version: 4.4.38-tegra
CUDA 9.0.252

Also, I’ve tried using the command you told about to extract the device tree but when I typed it in nothing happened. Is this what was supposed to happen?

The last thing I was looking for was an example code to communicate via SPI. I found a lot of examples for Arduino Micro controller, but nothing for the TX1, which, I think, is python language.

Make sure you have “dtc” installed:

which dtc

…if nothing shows up, then install:

sudo apt-get install device-tree-compiler

There should be a new file created. The “-o extracted.dts” says to name that new file “extracted.dts”. The content is built from the running system because it creates the tree based on “/proc/device-tree”.

I don’t know much about SPI, but getting your device tree changes in has fooled several people when trying to use older methods of adding it. Whatever your tree changes are you can compare to the extracted.dts to see if the changes actually exist on the booted system.

Thank you for the reply, Linuxdev.
When I type in “which dtc” an address is displayed: /usr/bin/dtc. Is that file (dtc) the one that I should change the name to extracted.dts?

Originally you mentioned the need to edit the device tree. This is where dtc is useful since it can be used to extract what is already in the system, put it in a form you can edit with an ordinary editor, and then put it back in dtb format (which flash.sh can put into the Jetson).

“dtc” is a program…Device Tree Compiler. dtc can convert between the three forms of device tree: Source, binary, and file system. The (capital ‘i’) “-I” just says what you Input file type is, the file named at the end of the command line is the the file or directory which is the input (so name type with -I, then name where the content is found). The capital “-O” says what format you want output to be, and lower case “-o” names what you want it named (actual output file name can be anything you want).

In “dtc -I fs -O dts -o extracted.dts /proc/device-tree”:

  • "-I fs" (capital '-i') means input is in the format of a directory tree.
  • "/proc/device-tree" exists as a directory tree created by the kernel and is an exact match to what the kernel sees. This particular case uses "-I fs" because it is file system input instead of a dts or dtb input.
    • Note: "/proc/device-tree" is not a real directory tree. It is a reflection in ram of the way the device tree nodes are connected as seen by the running kernel. You don't edit this, but you do use it to create trees which match the existing system.
    • Flashing from a compiled copy of "/proc/device-tree" is equivalent to doing nothing and leaving the system untouched.
  • "-O dts" says to create ".dts" format in output.
  • "-o extracted.dts" means to name the output "extracted.dts" as a newly created file. "extracted.dts" is just an arbitrary name I chose to point out it was derived from some other source (in this case "/proc/device-tree").

Overall, dtc is just a way to convert from one device tree format to another, and if you want to view what your current tree is, edit it, and then put it back in place with the edits, then this is a simple way of doing it (the “.dts” source format is human readable and can be edited in most any code editor).

FYI, in the end you need a dtb format which can be flashed, and you can’t flash pieces of a dtb. Thus you edit a dts of the whole system and then put your edited copy back in where it changes only a tiny subset of the content.

In earlier releases you could simply name your dtb with the FDT entry in extlinux.conf and put the named file in “/boot”. This no longer works. Now there is a flash procedure since the device tree is in a partition instead of in a file. “flash.sh” does this.

If you were to flash R28.2 of the dev carrier board kit and log the flash you’d see at some point a reference to file “Linux_for_Tegra/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb”. If you were to manually flash that exact file without flashing the entire Jetson, then you’d be doing the equivalent of making no changes at all…for the dev kit this is the file a kernel “make dtbs” target creates (kernel build makes many device trees, but this is the one the dev carrier board utilizes).

If you were to reverse compile the dtb “tegra186-quill-p3310-1000-c03-00-base.dtb” to dts format you would get the equivalent of reverse compiling “/proc/device-tree” to dts format (this is a specific case…different carrier boards and modules use different trees…“/proc/device-tree” would always be a match, “tegra186-quill-p3310-1000-c03-00-base.dtb” would change for different hardware).

thank you very much!!!you help me remove a stone in heart! thanks