Using UART

[Arcady]

Hello,

What configuration is exactly necessary to enable UART1/2/4 (or 3/5 but I am avoiding them for now because they aren’t native UART pins according to the board schematics)?
In the process I modified /boot/uEnv.txt to enable overlays and cape universal, and since then the ttyS and ttyO devices started showing up in /dev.
I have also checked that they get properly enabled:

debian@osd3358-sm-red:~$ dmesg | grep tty
[ 0.000000] Kernel command line: console=ttyS0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet
[ 1.310881] console [ttyS0] disabled
[ 1.310989] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 38, base_baud = 3000000) is a 8250
[ 1.321089] console [ttyS0] enabled
[ 1.322298] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 39, base_baud = 3000000) is a 8250
[ 1.323325] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 40, base_baud = 3000000) is a 8250
[ 1.324517] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 41, base_baud = 3000000) is a 8250
[ 1.325508] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 42, base_baud = 3000000) is a 8250
[ 1.326475] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 43, base_baud = 3000000) is a 8250

I am trying a small loopback test with a cable linking Tx to Rx, but I have only managed to observe something on UART0 with minicom.
For other UARTs, nothing.

I guessed I could follow the Beaglebone forums for troubleshooting but I just ended up modifying device trees with not much outcome.

Any indications?

[Neeraj Dantu]

Arcady,

The pinmux should be setup parts of the device tree overlay. You can make sure you are using the right pins looking at the pinmux section of the overlay(for example: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART2-00A0.dts#L29).

You can also use the config-pin utility to check on the pinmux states of the pins: https://github.com/beagleboard/bb.org-overlays/blob/master/tools/pmunts_muntsos/config-pin.c.

Depending on your kernel version and config, you should also be able to “cat /sys/kernel/debug/pinctrl” to get status of all pinmux for the device.

The bootlog you posted indicates that drivers were successfully initialized for several UARTs. So, it is probably a pinmux issue.

Best,

Neeraj

[Arcady]

Hi Neeraj,

Thanks for your response.

I have tried to using the config-pin tool but it didn’t solve my issue.
The pin mode did change but transmissions still failed.

I have also followed the PinMux guide to obtain a custom device tree and disabled overlays, yet it failed again.
Since I checked out the AM335x datasheet and the header file with pin data, there shouldn’t be any mistakes.

uart0 {
pinctrl-names = “default”;
pinctrl-0 = <&uart0_pins>;
status = “okay”;
};

uart1 {
pinctrl-names = “default”;
pinctrl-0 = <&uart1_pins>;
status = “okay”;
};

uart2 {
pinctrl-names = “default”;
pinctrl-0 = <&uart2_pins>;
status = “okay”;
};

uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)
AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
>;
};

uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
AM33XX_IOPAD(0x980, PIN_INPUT_PULLUP | MUX_MODE0)
>;
};

uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x954, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP | MUX_MODE1)
>;
};

At this point, I am getting quite confused as to what could be the root cause.
I’ll keep looking into the matter but it doesn’t seem very promising for now.

Best regards.

[Eshtaartha Basu]

Arcady,

The device tree snippet posted doesn’t look correct. By referencing “uart0”, “uart1”, “uart2” without preceding “&”, you’re re-defining the UARTx peripheral definition instead of referencing and updating existing base definition.

The base UARTx device tree definitions are already present in the lower level DTS files (one of the many “include” files). For example:

uart1: serial@48022000 {

               compatible = “ti,am3352-uart”, “ti,omap3-uart”;

               ti,hwmods = “uart2”;

               clock–frequency = <48000000>;

               reg = <0x48022000 0x2000>;

               interrupts = <73>;

               status = “disabled”;

               dmas = <&edma 28 0>, <&edma 29 0>;

               dma–names = “tx”, “rx”;

    };

 

To reference the above definition, enable the peripheral and update pinmux, you need to just refer the existing node’s name with “&” prefix as follows:

&uart1 {

pinctrl-names = “default”;
pinctrl-0 = <&uart1_pins>;
status = “okay”;

};

 

After applying the above fixes and building your DTB, you can double check how the final UARTx node looks like (base definition + your custom updates) by “disassembling” your DTB blob as shown in the link below. This is the fastest way to figure out if your custom updates are actually being reflected in the final DTB.
https://stackoverflow.com/questions/21670967/how-to-compile-dts-linux-device-tree-source-files-to-dtb

 

 

• This reply was modified 2 months, 1 week ago by Eshtaartha Basu.
• This reply was modified 2 months, 1 week ago by Eshtaartha Basu.

[Author]

Posts