UART6 on Iris board w. Colibri IMX7D under Linux

Hi Out There!

I’am strugling to bring up UART6 on Iris board, with iMX7D installed.
I’ve decompiled the device tree imx7d-colibri-eval-v3 from the running system,
and bring up the following section with an ‘okay’:

serial@30a80000 {
  compatible = "fsl,imx7d-uart", "fsl,imx6q-uart", "fsl,imx21-uart";
  reg = <0x30a80000 0x10000>;
  interrupts = <0x0 0x10 0x4>;
  clocks = <0x1 0xf6 0x1 0xf6>;
  clock-names = "ipg", "per";
  dmas = <0x2f 0x20 0x4 0x0 0x2f 0x21 0x4 0x0>;
  dma-names = "rx", "tx";
  status = "okay";
  };

This give me partial result - the device /dev/ttymxc5 can be used
as serial, but no pins activity were found.
I’ve read the article http://developer.toradex.com/device-tree-customization
and add the following:

serial@30a80000 {
......
.....
    pinctrl-names = "default";
    pinctrl-0 = <0x5d>;
    assigned-clocks = <0x1 0xeb>;
    assigned-clock-parents = <0x1 0xd>;
    fsl,dte-mode;
    };

And created a new control phandle <0x5d> (the next free number):

 uart6grp {
    fsl,pins = <0x16C 0x3DC 0x71C 0x1 0x3 0x79 0x168 0x3D8 0x
0 0x1 0x0 0x79 0x170 0x3E0 0x0 0x1 0x0 0x79 0x174 0x3E4 0x718 0x1 0x3 0x79>;
    linux,phandle = <0x5d>;
    phandle = <0x5d>;
    };

I’ve got those magic numbers from the kernel source, imx7d-pinfunc.h
at linux-4.12.3/arch/arm/boot/dts, as follows:

#define MX7D_PAD_ECSPI1_MOSI__UART6_DTE_RX  0x016C 0x03DC 0x071C 0x1 0x3
#define MX7D_PAD_ECSPI1_SCLK__UART6_DTE_TX  0x0168 0x03D8 0x0000 0x1 0x0
#define MX7D_PAD_ECSPI1_MISO__UART6_DTE_CTS 0x0170 0x03E0 0x0000 0x1 0x0
#define MX7D_PAD_ECSPI1_SS0__UART6_DTE_RTS  0x0174 0x03E4 0x0718 0x1 0x3

Unfortunately, it does not worked.
Did I missed something?

Regards
M5

The below would be the correct set of changes for activating UART6.

diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 6d349413b193..1c1ef5eead03 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -286,6 +286,12 @@
        status = "okay";
 };
 
+&uart6 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_uart6>;
+       status = "okay";
+};
+
 &usbotg1 {
        extcon = <&extcon_usbc_det>;
        vbus-supply = <&reg_usbh_vbus>;
@@ -328,5 +334,12 @@
                                MX7D_PAD_GPIO1_IO10__GPIO1_IO10         0x14
                        >;
                };
+
+               pinctrl_uart6: uart6grp {
+                       fsl,pins = <
+                               MX7D_PAD_ECSPI1_SCLK__UART6_DCE_RX      0x79
+                               MX7D_PAD_ECSPI1_MOSI__UART6_DCE_TX      0x79
+                       >;
+               };
        };
 };
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 9f3022b86041..30f9e5933646 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -339,12 +339,8 @@
                        fsl,pins = <
                                MX7D_PAD_SD1_CD_B__GPIO5_IO0            0x74 /* SODIMM 69 */
                                MX7D_PAD_I2C4_SDA__GPIO4_IO15           0x14 /* SODIMM 75 */
-                               MX7D_PAD_ECSPI1_MISO__GPIO4_IO18        0x14 /* SODIMM 79 */
                                MX7D_PAD_I2C3_SCL__GPIO4_IO12           0x14 /* SODIMM 81 */
                                MX7D_PAD_ECSPI2_MISO__GPIO4_IO22        0x14 /* SODIMM 85 */
-                               MX7D_PAD_ECSPI1_SS0__GPIO4_IO19         0x14 /* SODIMM 97 */
-                               MX7D_PAD_ECSPI1_SCLK__GPIO4_IO16        0x14 /* SODIMM 101 */
-                               MX7D_PAD_ECSPI1_MOSI__GPIO4_IO17        0x14 /* SODIMM 103 */
                                MX7D_PAD_I2C3_SDA__GPIO4_IO13           0x14 /* SODIMM 94 */
                                MX7D_PAD_I2C4_SCL__GPIO4_IO14           0x14 /* SODIMM 96 */
                                MX7D_PAD_SD2_RESET_B__GPIO5_IO11        0x14 /* SODIMM 98 */

Please do not modify SOC level dtsi files. Instead of using numbers please use the defines.

Hi,

So I did… :slight_smile:

Unfortunately there were no conquerors found in the GPIO section
for those pins in the running dtb. :frowning:

There were colliding entries in hoggrp-2, but did not referenced (I though).
Anyway, I’ve removed them but still nope.
Does not work.

Just a little note:

In case of a Tinker Board from ASUS, I’ve played this game aswell.
In that case the solution was a user space program that kicked
the ass of that pinmux stuff writing the registers according to the TRM.
I’ve hacked the ASUS ported wiringPi library in order to set
relevant pin functions to serial, and it worked.
It seems the same thing have to applied here…

Or any further tips or suggestions?

Regards,
M5

p.s.
Besides

snowwhite dts # dtc imx7d-colibri-eval-v3.dts -I dts -O dtb -o imx7d-colibri-eval-v3.dtb
Error: imx7d-colibri-eval-v3.dts:44.1-9 syntax error
FATAL ERROR: Unable to parse input tree

There were colliding entries in hoggrp-2, but did not referenced (I though)

They are referenced here.

I missed the DTE pinmux thing. Do you really need that? If not use DCE pinmux mode.

I changed my original answer a bit and tested it. Please check with that. That should work. I did not test with RTS/CTS but if that is a requirement, see an example of it here and here. Note the fsl,uart-has-rtscts property which has to be specified especially.

In case of a Tinker Board from ASUS, I’ve played this game aswell. In that case the solution was a user space program that kicked the ass of that pinmux stuff writing the registers according to the TRM. I’ve hacked the ASUS ported wiringPi library in order to set relevant pin functions to serial, and it worked. It seems the same thing have to applied here…

That breaks the defined userspace kernel interface and is completely wrong way to use in case of monolithic kernel like Linux.

Hi!

I’ve missed another obvious thing, to check dmesg:

[    1.021787] imx7d-pinctrl 30330000.iomuxc: pin MX7D_PAD_ECSPI1_MISO already requested by 30330000.iomuxc; cannot claim for 30a80000.serial
[    1.038191] imx7d-pinctrl 30330000.iomuxc: pin-92 (30a80000.serial) status -22
[    1.049423] imx7d-pinctrl 30330000.iomuxc: could not request pin 92 (MX7D_PAD_ECSPI1_MISO) from group uart6grp  on device 30330000.iomuxc
[    1.066034] imx-uart 30a80000.serial: Error applying setting, reverse things back
[    1.078233] 30a80000.serial: ttymxc5 at MMIO 0x30a80000 (irq = 287, base_baud = 1500000) is a IMX

I’ve included all four signals in the uart section, but forgot to delete RTS/CTS
from the colliding one. On the firts collision, the kernel rolled back the settings.

And then, after deleting the remaining two colliding entry:

root@var-som-mx7:~# ttysh /dev/ttymxc5 -s 115200
This is what I'm typed here :-)

TaDaaaa! It worked!
(beat me, but i’m using a debian based rootfs from Variscite,
that’s where var-som-imx7 prompt came in)

Many thanx for your help!
Now, if we use use the SOM in our hardware, even all of all serial
ports can be unleashed!

(also I will try these things in case of Tinker Board, instead of user space hacking)

Regards,
M5

Glad to know it’s working now.