SC16IS752 Serial Expansion Board

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Continuing the discussion from SC16IS7xx Serial expander support Device Tree:

I’m trying to follow the instructions from the linked post, but am having issues making it work.

First, I’m really unclear on how to change Pin 18 to GPIO3_PB.07. When I download the pinmux spreadsheet for the Jetson Nano, it looks like spi2_cs0 is already set to GPIO3_PB.07, but there’s no mention of pin 18, so I’m not entirely sure.

Assuming that I didn’t need to change that, I went ahead with the make commands, but I get a syntax error from the modification of the dtsi file. The output of the make dtbs command is:

$ make -C kernel/kernel-4.9/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra CROSS_COMPILE=${TOOLCHAIN_PREFIX} -j8 --output-sync=target dtbs
  CHK     scripts/mod/devicetable-offsets.h
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-e-base-p2595-0000-a00.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-e-base-p2595-0000-a00.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-e-base-p2595-0000-a00.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-base-p2597-2180-a00.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-base-p2597-2180-a00.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-base-p2597-2180-a00.dtb] Error 1
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-a00.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-a00.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-a00.dtb] Error 1
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-imx274-dp-hdmi.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-imx274-dp-hdmi.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-imx274-dp-hdmi.dtb] Error 1
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-a00-auo-1080p-edp.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-a00-auo-1080p-edp.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-a00-auo-1080p-edp.dtb] Error 1
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-imx274-hdmi.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-imx274-hdmi.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-cv-p2597-2180-imx274-hdmi.dtb] Error 1
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb] Error 1
  DTC     arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-p2597-2180-a01-android-devkit.dtb
Error: /home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/../../hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-soc-shield.dtsi:435.12-13 syntax error
FATAL ERROR: Unable to parse input tree
/home/bluecamel/nano_kernel/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/Makefile:120: recipe for target 'arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-p2597-2180-a01-android-devkit.dtb' failed
make[2]: *** [arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/_ddot_/hardware/nvidia/platform/t210/jetson/kernel-dts/tegra210-jetson-tx1-p2597-2180-a01-android-devkit.dtb] Error 1
arch/arm64/Makefile:154: recipe for target 'dtbs' failed
make[1]: *** [dtbs] Error 2
Makefile:171: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

I would really appreciate if anyone can point me in the right direction to make this work. Thanks!

3

Well, I figured out one of the problems. Copying the provided block into the tegra210-soc-shield.dtsi file apparently got the wrong character for double quotes. I changed those and was able to compile and flash. However, the sc16is7xx kernel module doesn’t appear to be there. When I run sudo modprobe sc16is7xx I get an error that the module is not found.

I should mention that I did one other thing different than what the post said, since I got an error until I added an additional line to build/.config: CONFIG_SERIAL_SC16IS7XX_SPI=n

4

Hi bluecamel,

Are you using the devkit or custom board for Jetson Nano?
What’s your Jetpack version in use?

From pinmux spreadsheet, you could find the pin SPI1_CS0 configured as GPIO3_PB.07 by default.

image
image1819×30 2.59 KB

Pin 18 here means the 18th pin on 40-pin header and you could find it from the spec of carrier board.
image
image412×526 38.2 KB

image
image1030×25 5.06 KB

5

This is on a Jetson Nano Development Kit (A02). I’m working with Jetpack 4.6.4 and L4T 32.7.4.

I hadn’t been able to use the spreasheet because I didn’t have Excel yesterday, but I was able to get a trial copy this morning and generate the dtsi. I changed column AA to pu and column AU to Int PU, which I think is what the previous poster was saying to do. I generated the dtsi files and continued with the rest of the steps for that and I’m not sure if that worked.

After flashing, I can run sudo cat /sys/kernel/debug/gpio and the line for gpio-110 is blank aside from that name:

$ sudo cat /sys/kernel/debug/gpio | grep 110
 gpio-110 (                    )

Also, as far as the kernel module, I had misinterpreted and realized that it isn’t building a module, but is instead building it into the kernel. I now see that the devices (/dev/ttySC0 and /dev/ttySC1) are being created, but when I try to use them, dmesg repeatedly shows an error:

[ 3942.400194] tegra-i2c 7000c400.i2c: no acknowledge from address 0x48

6

Well, I seem to have figured it out. I had two of these boards and, though I had no real reason to suspect one of them defective, I decided to try the second and I can send characters back and forth using screen/minicom. I’ll have to try some other devices to confirm.

I guess I must have had the device tree and kernel compiled correctly all along. I would still appreciate if someone could point me to a guide for the device tree that doesn’t require days of study to grok, because that’s still clear as mud to me :)

7

Configuring the device tree depends on the different drivers needing and the module.
If you get a new module for your board, there should be the porting guide including all necessary modifications for device tree from your vendor.

8

Editing a device tree is simple. The hard part is knowing what edits to make.

Some devices are “plug-n-play”, meaning that they can self-report what they are and where they are. Drivers use that information to decide which driver works with it, and to arrange what physical address to find the device at. Other devices require “firmware”, of which the device tree is a subset. That particular subset provides the things the driver need to find and operate the device. This includes the physical address, explicitly naming what drivers work with the device, and perhaps some of the driver parameters for loading. Addresses are based on a physical address on a bus, and might include setting up “general purpose” I/O (GPIO) for some specific purpose. If it is an i2c device, then the node will start with “i2c@...some hexadecimal address...”. The driver it works with will have its name in the right hand side of a “compatible” statement of the device tree node. So it isn’t really possible to just guess the details, although it is possible to easily make the edits if you know some details and if you have a similar device with a device tree.

I can’t really give you an answer, but if you need to change “pin 18”, then it implies usually using the PINMUX spreadsheet to set up that pin to the correct function. I don’t even know if pin 18 can be changed (I don’t know if it is GPIO or something else). However, assuming this is an ordinary Jetson Nano development kit, this would show the PINMUX spreadsheet:
https://developer.nvidia.com/embedded/downloads#?search=pinmux&tx=$product,jetson_nano
(you would enable macros and look for what pin 18 can be set up as, along with what is required)

If you had the pin set up correctly, then that would at least be a start.

10

Well, I’m glad that you think so, lol. Figuring out where how to generate dtsi, cfg, and even just where to put them has been a real challenge and I would be completely lost if it weren’t for some forum posts explaining some of that. Yet I’m still not there. Anyhow, I’m going to post a new topic on those challenges since I’m past this particular issue for the Nano and now working on Xavier NX.

11

Some URLs which are related, though perhaps not exactly what you are after:

A bit of a restatement of the above: The official documentation which talks about .dtsi files isn’t really talking about directly editing a device tree. The .dtb file is the compiled binary device tree, and the .dts file is the device tree source file. Device trees come in fragments, whereby one branch or leaf of the tree is its own little independent world related to one driver. The .dts or .dtb are just packages of fragments combined in one organized fashion.

If you have the dtc program (via “sudo apt-get install device-tree-compiler”), then you don’t need a .dtsi file to edit or modify a device tree. One can convert back and forth between source format (a .dts file you can edit) and binary format (the form used during boot).

A given device tree fragment can be thought of as arguments or environment to pass to a driver as the driver loads. For example, plug-n-play devices state what they are and where they are, but some non-plug-n-play device exists on a bus at a specific hardware address and the driver has no way to know how to find that device (or even that the device exists). Device trees provide that information. When a driver loads it can examine the device tree to see if there is a fragment compatible with that driver. If there is, then the fragment is consulted to find the device and for optional arguments to pass to the driver.

Long ago, one would have had to have had a different driver, or some source code to select different variations on using the driver if the same chipset were used for a device, but located at some different address. Or if the device could run at multiple speeds, then one would have needed a different driver for every speed. The device tree was invented to allow generic/abstract drivers which are independent of the arguments passed to the driver. Device tree does not modify a driver except by data.

When building a kernel one is selecting a list of drivers and features. Building the kernel itself (the Image file), or building modules (still part of the kernel and drivers, just dynamically loadable/unloadable), is actually unrelated to device tree. There is no need to put device tree content in kernel source. However, it is rather convenient to do so since you only need to provide device trees for drivers which you are building. The kernel configuration is a shopping list of features that might need optional arguments or environment passed to it during load.

When talking about a .dtsi file you are talking about properly escaped strings containing the content of one device tree node or fragment. If you enable a driver which uses that fragment, then building the device tree in the kernel simply concatenates all the fragments and turns it into a single .dts file. Then it converts to binary format (the .dtb file). That’s the long way of building a tree: Configuration a kernel and then building from that shopping list.

If you look at a device tree binary file (e.g., one in “/boot”), then you can easily convert it to human readable source. If for example the file is named tree.dtb:

# Create binary to source:
dtc -I dtb -O dts -o tree.dts tree.dtb

# You can now read and edit tree.dts.

# Or, Jetsons export the current device tree to "/proc/device-tree" (browse those read-only files).
# You can create a source file from the running tree shown in the filesystem:
dtc -I fs -O dts -o extracted.dts /proc/device-tree

# Let's say you edited and now have "modified.dts". Convert it to binary:
dtc -I dts -O dtb -o you_can_boot_this.dtb modified.dts

I suggest you create a source file from “/proc/device-tree” like in the example above. Use an editor to look at it. Consider you can convert the source right back into binary format. It’s a simple file and files can be copied into place. The extlinux.conf FDT key/value pair is one way of naming a different .dtb file.

If you see reference to a .dtsi file, then someone is expecting you to configure a kernel to match your running system to pick the right features and drivers, followed by building the device tree target (the dtbs build target). The patch you might see is escaped so the build software can turn it into a device tree fragment and assemble all the fragments into a single file. It’s easier if you already have a file to turn it into source, edit, and turn it back into binary.

12

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