Orin NX SC16IS7XX driver

I have an Orin nx with jnx42 carrier. Running ubuntu 20.04, kernel version 5.10.104. I’ve manually built and installed the sc16is7xx driver. I have two sc16is752 devices connected. I’ve set them up (presumably correctly) in the device tree. I get:

orin3 ➜  ~  sudo dmesg | grep -i sc16
[   15.792992] sc16is7xx: no symbol version for module_layout
[   15.793001] sc16is7xx: loading out-of-tree module taints kernel.
[   15.798648] sc16is7xx: loading out-of-tree module taints kernel.
[   15.817138] 1-004c: ttySC1 at I/O 0x1 (irq = 307, base_baud = 921600) is a SC16IS752
[   15.823847] 1-004d: ttySC3 at I/O 0x1 (irq = 308, base_baud = 768000) is a SC16IS752

The driver was built on the correct version:

orin3 ➜  ~  uname -r
5.10.104-tegra
orin3 ➜  ~  modinfo sc16is7xx
filename:       /lib/modules/5.10.104-tegra/kernel/drivers/tty/serial/sc16is7xx/sc16is7xx.ko
description:    SC16IS7XX serial driver
author:         Jon Ringle <jringle@gridpoint.com>
license:        GPL
alias:          of:N*T*Cnxp,sc16is762C*
alias:          of:N*T*Cnxp,sc16is762
alias:          of:N*T*Cnxp,sc16is760C*
alias:          of:N*T*Cnxp,sc16is760
alias:          of:N*T*Cnxp,sc16is752C*
alias:          of:N*T*Cnxp,sc16is752
alias:          of:N*T*Cnxp,sc16is750C*
alias:          of:N*T*Cnxp,sc16is750
alias:          of:N*T*Cnxp,sc16is741C*
alias:          of:N*T*Cnxp,sc16is741
alias:          of:N*T*Cnxp,sc16is740C*
alias:          of:N*T*Cnxp,sc16is740
alias:          i2c:sc16is762
alias:          i2c:sc16is760
alias:          i2c:sc16is752
alias:          i2c:sc16is750
alias:          i2c:sc16is741
alias:          i2c:sc16is740
alias:          i2c:sc16is74x
depends:
name:           sc16is7xx
vermagic:       5.10.104 SMP preempt mod_unload modversions aarch64

But there are no /dev/ttySCx devices. Why?

Hi user43745,

It seems you are using the custom carrier board.
What’s your Jetpack version in use?
Please share the result of the following command on your board.

$ cat /etc/nv_tegra_release
$ ls -l /dev/ttySC*

and also the full dmesg for further check.

How do you connect them on your board?

# R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023

Additionally:

orin3 ➜  ~  apt-cache policy nvidia-jetpack
nvidia-jetpack:
  Installed: 5.1.2-b104
  Candidate: 5.1.2-b104
  Version table:
 *** 5.1.2-b104 500
        500 https://repo.download.nvidia.com/jetson/common r35.4/main arm64 Packages
        100 /var/lib/dpkg/status

ls -l /dev/ttySC* returns nothing.

Full dmesg attached
dmesg.log (72.4 KB)

The devices are connected via I2C-1 through PCB traces. Each is configured with a different address (0x4C and 0x4D), and each of those shows as in use UU on i2cdetect -y -r 1. Interrupts (1x each) are connected to pins for gpio sysfs# 473 and 474.

DTS snippet:

        i2c@c240000 {
                ...
                sc16is752@4c {
                        compatible = "nxp,sc16is752";
                        clocks = <0x48a>;
                        gpio-controller;
                        #gpio-cells = <0x02>;
                        status = "okay";
                        i2c-max-frequency = <0x61a80>;
                        interrupt-parent = <0x05>;
                        interrupts = <0x7d 0x02>;
                        reg = <0x4c>;
                        clock-frequency = <0xbb8000>;

                        sc16is752_clk {
                                compatible = "fixed-clock";
                                #clock-cells = <0x00>;
                                clock-frequency = <0xe10000>;
                                phandle = <0x48a>;
                        };
                };

                sc16is752@4d {
                        compatible = "nxp,sc16is752";
                        clocks = <0x48b>;
                        gpio-controller;
                        #gpio-cells = <0x02>;
                        status = "okay";
                        i2c-max-frequency = <0x61a80>;
                        interrupt-parent = <0x05>;
                        interrupts = <0x7e 0x02>;
                        reg = <0x4d>;
                        clock-frequency = <0xbb8000>;

                        sc16is752_clk {
                                compatible = "fixed-clock";
                                #clock-cells = <0x00>;
                                clock-frequency = <0xe10000>;
                                phandle = <0x48b>;
                        };
                };
                ...
        };
[   15.952974] serial serial0: tty port ttySC0 registered
[   15.954889] 1-004c: ttySC1 at I/O 0x1 (irq = 307, base_baud = 921600) is a SC16IS752
[   15.955248] serial serial1: tty port ttySC1 registered
..
[   15.959553] serial serial2: tty port ttySC2 registered
[   15.961452] 1-004d: ttySC3 at I/O 0x1 (irq = 308, base_baud = 768000) is a SC16IS752
[   15.961802] serial serial3: tty port ttySC3 registered

It seems ttySC0 to ttySC3 are registered.

Could you tried to run the following command on your board?

$ sudo su
# cd /
# find -name ttySC*
[   15.975117] bmi088 9-0069: removed
[   15.975126] bmi088: probe of 9-0069 failed with error -22
[   15.981444] bmi088 10-0069: removed
[   15.981453] bmi088: probe of 10-0069 failed with error -22

What is bmi088? Are you connecting a motion sensor on your board?

bmi088 - I’m using a stereolabs zed box (OEM Auvidea JNX42), which does have a bmi088 onboard.

On the find -name ttySC*, I get no results.

Could you ask for the help with your vendor of sc16is752 devices for details?
We don’t have this module to debug the issue in details.

I submitted a support ticket to NXP yesterday morning, and have yet to receive a response. If I order a development board for the IC to you or others, could support continue here? I’m afraid NXP might not be able to provide much assistance, as I know the hardware itself works by successfully testing on a TX2

Sorry that we won’t receive the equipment from forum user.

Do you mean that sc16is752 can work as expected on TX2 and the /dev/ttySC0 to /dev/ttySC3 exist?

You can also try to add more debug message in sc16is7xx driver to check if probe function finishes w/o any error.

Correct, the sc16is752 works as expected on TX2, and the ttySCx devices exist. This is true with a development board for the sc16is752, i.e. controlling the variable of our custom pcb, the TX2 works and the Orin does not.

I’ve managed to make a small amount of progress. We built the driver onboard the Orin itself. Now, using the breakout board, dmesg shows:

[   12.797537] sc16is7xx: loading out-of-tree module taints kernel.
[   12.807251] irq: IRQ309: trimming hierarchy from :pmc@c360000
[   12.813927] gpiochip2: registered GPIOs 308 to 315 on 1-0048
[   12.820513] serial serial0: tty port ttySC0 registered
[   12.826443] serial serial1: tty port ttySC1 registered

But there are still no /dev/ttySCx devices, and a find . -name ttySC0 from the root returns nothing

May I know why you don’t build the module in kernel image and flash onto your board?

You can add more debug messages in sc16is7xx driver.

I’ve been attempting to build it into the kernel image as well, and have been similarly unsuccessful. At this point, I get a brief Nvidia startup page with some option for continuing boot, settings, etc. Regardless of what I do, it goes straight to a black screen and remains that way.

My method is as follows:

Download to ~/orin/:

Download and extract Bootlin Toolchain gcc 9.3

  • I extract to a folder ~/linux/bootlin/
tar xpvf Jetson_Linux_R35.3.1_aarch64.tbz2
tar xpvf public_sources.tbz2
export L4T_HOME=$(pwd)/Linux_for_Tegra
cd Linux_for_Tegra/rootfs
sudo tar xpvf ../../Tegra_Linux_Sample-Root-Filesystem_R35.3.1_aarch64.tbz2
cd ../
sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh
cd source/public
sudo tar xpvf kernel_src.tbz2
cd kernel/kernel-5.10
sudo mkdir kernel_out
export KERNEL_OUT=$(pwd)/kernel_out
export CROSS_COMPILE=~/linux/bootlin/bin/aarch64-buildroot-linux-gnu-
sudo make ARCH=arm64 O=$KERNEL_OUT tegra_defconfig
sudo make ARCH=arm64 O=$KERNEL_OUT menuconfig

// navigate to Device Drivers>Character Devices>Serial and enable SC16IS7XX as "*", with only the I2C option selected (not SPI)

sudo make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=${CROSS_COMPILE} -j8 Image
sudo make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=${CROSS_COMPILE} -j8 dtbs
sudo make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=${CROSS_COMPILE} -j8 modules
sudo make ARCH=arm64 O=$KERNEL_OUT modules_install INSTALL_MOD_PATH=$L4T_HOME/rootfs/

cp $KERNEL_OUT/arch/arm64/boot/Image $L4T_HOME/kernel/
cp $KERNEL_OUT/arch/arm64/boot/Image $L4T_HOME/rootfs/boot/
cp $KERNEL_OUT/arch/arm64/boot/dts/nvidia/* $L4T_HOME/kernel/dtb/

On the Auvidea carrier, you need to change cvb_eeprom_read_size = <0x100> in Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb2-bct-misc-p3767-0000.dts to cvb_eeprom_read_size = <0x0>

Then it should be good to flash. I power on in recovery mode.

cd $L4T_HOME
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs --network usb0 p3509-a02+p3767-0000 internal

It seems you are using a custom carrier board and it is not designed from you.
As a result, you have to ask you vendor(of the carrier board) for the kernel source(they should have some customization for the board) to build and update kernel image locally.

Okay. To simplify the debug process, maybe build it as a loadable module is a easier way for you.
Please check if there’s other errors when you are loading sc16is7xx driver.

Correct, I’m using a carrier board not designed by me. We’re using the Auvidea JNX42 carrier, their software setup instructions (page 15) use the base Nvidia BSP and rootfs.

I’ll try building as a module.

1 Like

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