TX1 Serial port configuration

Needed two serial ports for my motor controllers. Since the port on the expansion connector is wired into the console I couldn’t use it. However its not too difficult to fix that or move the console for some other reason. You will need to compile the kernel there is an excellent recipe here http://developer.ridgerun.com/wiki/index.php?title=Compiling_Tegra_X1_source_code Works perfectly you can just cut and paste your way to a new kernel.

There are several parameters in the kernel boot command line. You can see the running kernels command line by doing cat /proc/cmdline or looking at /boot/extlinux/extlinux.conf Two console commands the first refers to virtual consoles. The flip screens you can sccess in ubuntu. In order to have console messages passed to whatever virtual screen you are accessing at the time. The second console directive is the one dealing with real serial ports. Its set to work on the /dev/ttyS0 device which is a real serial port and has an upstart config in /etc/init/ttyS0.conf. You will need to make a copy of this file and edit it for whatever port you want to use for your console so grab a copy into your work area.

Now you need to determine your serial port strategy. In my case I wanted the serial port on the 6 pin header for my master roboteq controller and the serial port on the expansion header pins 8 and 10 for the slave. They are also attached with a can bus connection the reason for the master slave terminology. I can use them either way. But having 2 serial ports so each has a connection allows me to use the mixing in the firmware for tank steering with a 4wd bot. Usually you use a controller on each side which follows along with the 2 wheel 2 caster simple bot chassis in ROS. However if you switch that up to using a controller for the front wheels and one for the rear you can start up 2 instances of the roboteq_driver in separate namespaces and they will act as 1 controller without doing any coding. Much more likely not to break something else in ROS either. So this is why I wanted 2 ports.

The ports are here in memory.

The expansion header port is at 0x70006000 Irq 69 /dev/ttyS0 and /dev/ttyTHS1 and console with default config
The 6 pin header serial port is at 0x70006200 irq 78
The one in the debug connector is 0x70006300 irq 122 Samtech has a mating connector with cable already attached if you need this port.

In my config I moved the console over to the uart on the debug port.

So once you have the cross compiler all set up and you are able to make zImage without errors go into the Linux_for_Tegra/sources/kernel_sources/arch/arm64/boot/dtb directory and edit tegra210-common.dtsi This section deals with the serial ports.

serial@70006000 {
compatible = “nvidia,tegra114-hsuart”;
status = “okay”;

    serial@70006200 {
            compatible = "nvidia,tegra114-hsuart";
            status = "okay";

    serial@70006300 {
            compatible = "nvidia,tegra210-uart", "nvidia,tegra114-hsuart";
            status = "okay";

If this were the default config file serial@70006000 would look like serial@70006300 and vice versa. So I’ve changed the console from the expansion connector to the debug connector uart.

At this point you just resume the kernel compile recipe. Now the /boot/extlinux.conf file on the new flash of l4t on the TX1 will be the default unless you change it before flashing on the Linux_for_Tegra filesystem. However you can always change it after the machine boots from the flash and reboot. Change the second console statement to match where you moved the console too or take it out altogether. Works either way. Now that file I told you about earlier comes into play. If you want to have a getty running on the new console port you need to go into the ttyS0.conf file I told you to grab and change any instances of ttys0 to either ttyS1 or ttyS2 depending on which uart you put the console on. The copy that back to the /etc/init directory using the correct filename corresponding to where you put the console. You don’t need to getty that port if you aren’t going to use a terminal on it. And you can test with minicom or cu I use cu the command is cu -s 115200 -l /dev/ttyTHSx and ~. to get back out of it. One more thing the devices will change. Now they will be /dev/ttyTHS0 - /dev/ttyTHS2 instead of /dev/ttyTHS1 - /dev/ttyTHS3. Not sure why this happens. If you look in the docs there is a blurb about noise on the expansion port serial pins might cause boot to halt. I have verified this by accident when I had a jumper on them to see if my config had worked. It booted maybe 1 in 8 times. I have a theory that the machine isn’t alive enough at that point to take any characters in basically. They fill the tiny fifo on the chip and its all over. So if you get your devices hooked up and all of a sudden you baby won’t play ball do something about grounding that line when you boot. In my case I don’t turn on the roboteq controllers until after the TX1 is up and ROS is running just in case it might spurt out a string that caused the controllers to turn on and run away for instance. So I haven’t seen the behavior with a controller hooked up yet just when I had it directly looped back. So I think its good to go.

Some commands you can use to check out the serial ports are cat /proc/tty/driver/serial serial-hs-tegra and even though setserial isn’t a main line program for config these days its still useful. Use apt-get to get a copy. setserial -a /dev/ttyXXX and setserial -G /dev/ttyXXX also you will notice that there is no baud rate or uart designated this is normal but if you want to set it by hand just to make sure you can use sudo setserial /dev/ttyxxx base_baud 115200 uart 16650A then use setserial -a to look at the port and verify.