Enabling sc16is7xx

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I am using an I2C to UART bridge controller and was hoping to use this driver on my TX2. I am struggling to get this done though.

Can I just download the kernel source, copy the config from /proc/, edit it to enable sc16is7xx and rebuild? (similar to how it was outlined here (https://devtalk.nvidia.com/default/topic/1032862/a-guide-to-solve-usb-serial-driver-problems-on-tx2/), just changing from CONFIG_USB_SERIAL_CH341 to CONFIG_SERIAL_SC16IS7XX (and all corresponding)? When attempting to do that, I get a .o object out instead of a .ko, and if I move it over to modules and attempt to modprobe it, it give mes an error “could no insert sc16is7xx: Exec format error”

Any help would be appreciated. Thanks!

2

You might be interested in this:
[url]https://devtalk.nvidia.com/default/topic/1038175/jetson-tx2/tx2i-wifi-support/post/5274619/#5274619[/url]

If there is a driver available in module form, then you basically set up a kernel build to match your running system, add the driver as a module, and then copy the newly built driver to the right place in “/lib/modules/$(uname -r)/”. If the driver is not available as a module, but is available integrated, then you’d build Image instead of modules (you might end up needing to build and install a new set of modules if base kernel configuration changes in the wrong way…if base kernel config does not change, then a module can be added at any time).

I know nothing about this particular driver, but if you build the whole Image, and then modules, it should always work out (I always suggest building Image first as a sanity check even if you don’t need it…but you could run “make modules_prepare” instead before “make modules”).

Note that exec format error occurs when the wrong object file format is used. One example is if you were to use a desktop PC’s x86_64 compiler…you would instead need an arm64/aarch64 cross compile (or just build it natively on the Jetson). An intermediate “.o” file is also not the kind of object required for a kernel module.

3

Thanks linuxdev!

That worked for me to add the kernel object to the modules folder. I did get the uname change from 4.4.38-tegra to 4.4.38-tegra+, so I had to create a new modules folder (I now have one for /lib/modules/4.4.38 and one for /lib/modules/4.4.38-tegra+). That does allow it to work whether I use the original Image (4.4.38-tegra) and my custom Image (4.4.38-tegra+).

I am now struggling to edit the device tree. I haven’t done it before, and have been following the following posts:
https://devtalk.nvidia.com/default/topic/1024097/jetson-tx2/how-to-update-device-tree-on-tx2/
https://elinux.org/Jetson/TX2_DTB
https://devtalk.nvidia.com/default/topic/1020708
https://devtalk.nvidia.com/default/topic/1019936/jetson-tx1/jetpack-3-1-how-to-select-different-dtbs/

and even this one referencing a raspberry pi (since that is the same driver I am attempting to add to the device tree):
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=146908
https://www.raspberrypi.org/forums/viewtopic.php?t=128892&p=904524

But unfortunately I haven’t been successful. Does the Jetson TX2 support overlays like the Raspberry Pi or do I need to add my own entry in the device tree by

  1. Grabbing the current device tree (dtc -I fs -O dts -o tree_from_proc.dts /proc/device-tree)
  2. Edit it (which I"m not sure how to do, I have a I2C to UART chip, with the I2C part of the chip connected to i2c-8 with an address of 0x4C)
  3. Recompile into a .dtb file.
  4. Flash it using dd to mmcblk0p15

Thanks again!

4

Earlier releases of L4T were simple file copies, and then the boot loader would find and use that. More recent releases are much more complicated and require the flash tool to load the device tree (the tool signs the device tree and then loads it into a partition…the extlinux.conf FDT entry won’t do what you expect).

These are notes on device tree (L4T release version changes what to use):
https://devtalk.nvidia.com/default/topic/1001443/jetson-tx2/extlinux-conf-fdt-no-longer-used-for-dtb-file-specification-/
http://elinux.org/Jetson/TX2_DTB
https://devtalk.nvidia.com/default/topic/1001584/jetson-tx2/gpio-pinmux/post/5226482/#5226482

Here is a suggestion on understanding what is going on. First, save a copy of the running system’s current device tree. Keep this and don’t let it get destroyed:

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

This “extracted.dts” is human readable and can be edited or converted back to binary format suitable for flashing:

dtc -I dts -O dtb -o recompiled_from_extracted.dtb extracted.dts

You may see places where it says to replace a certain file of a certain name, or to just flash with your file name. The edited-then-recompiled dtb is what you are using. Information in some places names kernel files for this, but those files are just fragments of the total extracted.dts (depending on build options different fragments are chosen…the version extracted from your Jetson is always the right version with the right fragments).