Colibri i.MX7D Device Tree Customization Not Working

Hello,

I’ve started working on a device tree dts file for a custom board that we have developed for the i.MX7D Colibri V1.1 B module.

The default dtsi and dts files, for the iMX7D Colibri and Colibri Evaluation Board, setup and configure i2c port 1 and i2c port 4. I have some application code that calls down from user space and sends bytes out from the I2C port that is available from X8 on the Colibri Evaluation Board. This is i2c4 and it seems to be working fine.

In our board specific dts file I am disabling i2c port 1 and i2c port 4 by adding the following to the dts file:

&i2c1 {
     status = "disabled";
 }
 
 &i2c4 {
     status = "disabled"
 }

For i2c port 3, which we are using on our custom carrier board, I have added the following, based on the existing i2c port 4 setup:

&i2c3 {
     clock-frequency = <100000>;
     pinctrl-names = "default";
     pinctrl-0 = <&pinctrl_i2c3>;
 };
 
 &pinctrl_i2c3: i2c3grp {
     fsl,pins = <
         MX7D_PAD_LCD_DATA20__I2C3_SCL        0x4000007f
         MX7D_PAD_LCD_DATA21__I2C3_SDA        0x4000007f
     >;
 };

After building the dtb file using our custom carrier board dts file I use an SD Card to update the dtb on the Colibri i.MX7D module. As the embedded Linux OS boots it seems to lockup around the following line of output in the terminal program from embedded Linux:

[    2.374460] ubi0: available PEBs: 0, total reserved PEBs: 4060, PEBs reserved for bad PEB handling: 76
[    2.387433] ubi0: background thread "ubi_bgt0d" started, PID 143
[    2.388342] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[    2.395392] snvs_rtc 30370000.snvs:snvs-rtc-lp: setting system clock to 1970-01-01 00:00:00 UTC (0)

Occasionally Linux fully boots and I see /dev/i2c-2 as I expect, but when I run my test application to receive and send data over the port I do not see any data on SDA and no clocks on SCL as I would expect and as I saw previously when i2c4 was configured in the original Toradex device tree files.

Is there something that I’m missing in my setup of i2c3 above?

Thank You.

I can see two problems here:

  • You do not have status = "okay"; in &i2c3 node, so the device will not be enabled.
  • The pins you want to use are claimed by default in imx7-colibri.dtsi, node pinctrl_hog_3. Have you disabled this muxing? You can check pin collisions by dmesg | grep pinctrl command, it should not give you any errors or failures.

EGM, the dts file contents that I posted above are not complete. I do in fact have the line: status = "okay"; in my file, and I do see i2c_2 in /dev so I do have access to the device driver from user space. Sorry I did not have that included in my post, and thank you for pointing that out…

I did see where the pins, in my post above, are claimed in the imx7-colibri.dtsi file in the pinctl_hog_3 node. I tried commenting out the lines that were for those pins so that I could use them in my node, but when I rebuilt the dtb and flashed it to the Colibri i.MX7D board the embedded Linux OS hung on bootup. Is there a specific method that I need to use to disable the muxing?

Thank You.

@Gage05: Please post output from dmesg | grep pinctrl and complete DTS files. Without these information I can just guess what is wrong.

Please do not disable I2C1, it is used on the module to communicate with the power management chip (PMIC). Disabling it can lead to all kinds of weird issues.

As @EGM suspects, pinmux might be an issue. Make sure the pins are not muxed anywhere else. You can also check whether I2C3 successfully claimed the pins using: cat /sys/kernel/debug/pinctrl/pinctrl-handles.

Hello EGM,

Sorry for the late response to your question. I was out from work last week.

Unfortunately, the system is locking up during the boot process most of the time now that I’m using our custom carrier board file. Occasionally I get lucky and the embedded Linux OS fully boots, but I have not been able to do that this morning so I cannot run dmesg | grep pinctrl as you suggested.

Also, all of the DTS files that we are using for our project are the standard imx7 and imx7D files that are given at the bottom of the Device Tree Customization page on your website: Device Tree Customization.

The differences are that we have modified the imx7-colibri-eval-v3.dtsi file. We replaced the replaced the line:

native-mode = <&timing_vga>;

with

native-mode = <&timing_wvga>;

for the larger display that we are using, and I have replaced the standard imx7d-colibri-eval-v3.dts file with our own carrier board specific file: imx7d-colibri-p1100.dts.

I have uploaded all of these files here: link text.

I do see that the GPIO pins that I am trying to configure for use with i2c3 are setup in the imx7-colobri.dtsi file as:

MX7D_PAD_ENET1_RGMII_TD3__I2C4_SDA
MX7D_PAD_ENET1_RGMII_TD2__I2C4_SCL

This is in the pinctrl_i2c4: i2c4grp node.

I am trying to configure them using

X7D_PAD_LCD_DATA20__I2C3_SCL
MX7D_PAD_LCD_DATA21__I2C3_SDA

in our custom imx7d-colibri-p1100.dts file. I’m not sure how I need to disable the muxing and configure these pins for our use.

Thank You.

Are the lockups at the same location during bootup or is it different?

Regarding I2C, I am bit confused which pins you exactly try to use as I2C. The two muxes you mention are for different I2C instances (I2C3 vs. I2C4). LCD_DATA20/21 map to SODIMM 124/127. So you can actually use those two I2C buses independently, just enable I2C3 and add pinmux to the instance…

Hello stefan.tx,

It is at different locations during bootup, but the problem happened after adding our own carrier board file, imx7d-colibri-p1100.dts, where I attempt to setup and configure GPIO pins for use as i2c3.

Sorry, I realize now after re-reading my post that it is confusing. We are trying to use i2c3 not i2c4. Please disregard my mention of the pins:

MX7D_PAD_ENET1_RGMII_TD3__I2C4_SDA
MX7D_PAD_ENET1_RGMII_TD2__I2C4_SCL

above. I was in error.

What do you mean by “just enable I2C3 and add pinmux to the instance…”?

Am I doing this right in the imx7d-colibri-p1100.dts file that I have attached? I’ve commented out the section where I defined the pins, but it is still in the file. I also tried to redefine these pins in the iomuxc node.

I don’t understand what I’m doing wrong and why my pin definition doesn’t seem to be working. I am defining a node the way it is being done for i2c4, but that doesn’t work.

When things do work, occasionally when the system does not lock-up, I can make a call to open() in my application file and what looks like a valid file descriptor is returned for the i2c port, but I do not see any clocks or data from the lines when calling write() and attaching the colibri evaluation board outputs to an oscilloscope. When I was using the default i2c4 port that is already setup by default for the colibri evaluation board I did see clocks and data when making the call to write().

This is from my original question above:

&i2c3 {
      clock-frequency = <100000>;
      pinctrl-names = "default";
      pinctrl-0 = <&pinctrl_i2c3>;
  };
  
  &pinctrl_i2c3: i2c3grp {
      fsl,pins = <
          MX7D_PAD_LCD_DATA20__I2C3_SCL        0x4000007f
          MX7D_PAD_LCD_DATA21__I2C3_SDA        0x4000007f
      >;
  };

This is what I was setting up in our imx7d-colibri-p1100.dts file. Is this the correct way to setup the GPIO pins for use as i2c3?

Thank You

Do you have any additional information on this? I have spent days trying to figure out why we cannot customize our device tree. I have a carrier board specific file that I’m trying to use. I’m stuck at the moment and cannot make any progress as a result. What am I doing wrong? I have followed the Toradex Device Tree Customization page and this does not work.

Do you have any conflicting pinmux? The below was all that was required to enable i2c3 on Colibri Evaluation Board.

diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 1db5aa5365b2..03895852956d 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -116,6 +116,12 @@
        status = "okay";
 };
 
+&i2c3 {
+       status = "okay";
+       pinctrl-names = "default";
+       pinctrl-0 = <&pinctrl_i2c3>;
+};
+
 &i2c4 {
        status = "okay";
 
@@ -327,5 +333,12 @@
                                MX7D_PAD_GPIO1_IO10__GPIO1_IO10         0x14
                        >;
                };
+
+               pinctrl_i2c3: i2c3grp {
+                       fsl,pins = <
+                               MX7D_PAD_LCD_DATA20__I2C3_SCL           0x4000007f
+                               MX7D_PAD_LCD_DATA21__I2C3_SDA           0x4000007f
+                       >;
+               };
        };
 };
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 7220ea56a66a..49e4cb076db6 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -355,8 +355,6 @@
                        fsl,pins = <
                                MX7D_PAD_LCD_DATA18__GPIO3_IO23         0x14 /* SODIMM 136 */
                                MX7D_PAD_LCD_DATA19__GPIO3_IO24         0x14 /* SODIMM 138 */
-                               MX7D_PAD_LCD_DATA20__GPIO3_IO25         0x14 /* SODIMM 140 */
-                               MX7D_PAD_LCD_DATA21__GPIO3_IO26         0x14 /* SODIMM 142 */
                                MX7D_PAD_LCD_DATA22__GPIO3_IO27         0x14 /* SODIMM 144 */
                                MX7D_PAD_LCD_DATA23__GPIO3_IO28         0x14 /* SODIMM 146 */
                        >;