The uart3 of TK1 can not be used

I designed a custom TK1 board which needs to use uart3.

But unlike other 3 uarts, uart3 can not be used.

The dts file of TK1 in the kernel source is below

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

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

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

Only 3 serials are included .Adding a fourth serial here can solve the problem?

Thanks for your help.

The UART in question would be “serial@70006300” (this is the only UART not covered in the existing dts settings which you posted). The idea is that the dts would provide enough setup by adding UART-D (UART-D is TRM notation, label differs depending on document) that the UART drivers could find and function with the device.

There may also be PINMUX edits too, e.g., in some cases a GPIO might share function with a UART (I didn’t see anything in the TRM for UART-D/serial@70006300 though so you are probably in luck and not needing PINMUX edit). The dts edit will make that UART available in a manner the drivers can use if PINMUX is correct for UART function.

If the UART (or pin) was used for some other purpose you might also have to determine if that other purpose requires disabling (instead of just setting up for UART, you might also need to set up for losing something which already expected that pin).

On the Jetson TK1 schematic it looks like the label for the unused UART is “UART3” (serial@70006300?)…at least this one shows no connection to anything on the BGA (is the UART in question from those BGA pins on your custom board?). Some of the JTK1 unused UART pins: M3, M2, R8, R9.

It’s easy to test, just add a new/alternate boot entry in the extlinux.conf file, edit the FDT key/value pair with a different/alternate name for a custom dtb file with those edits, and place the alternate dtb file in “/boot”. Pick that entry via serial console when you boot…you should know with minimal testing if something went horribly wrong or if it works. In this particular case I’d just try that without researching PINMUX more…it’s harmless if it fails, and saves a lot of time if it works.