Trying to enable I2C5/6 using SODIMM pins 19 and 34 with tcbuilder

Hello Support,
My board is based off of the verdin dev board and I am trying to enable I2C 5/6 (there is some switching where they are called different things). I am doing an overlay which should overlay the dev board settings.
Using the pinout designer, I find that the pins are used elsewhere on the dev board (SODIMM 34, DIGITAL_AUDIO_1_I2S_MASTER_D_OUT0). On our board, which is modeled after the verdin dev board, has no digital audio lines connected. So, in theory, all I should have to do is disable that line I think and then build my I2c6 connections.

I have disabled the existing conflicting pin thusly:
&pwm3dsi1hpdgpiogrp {
status = “disabled”;
};

However, when I try to set the GPIO’s up as:
scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
Builder gives me a syntax error on either line (if I comment out the previous one). Yet these same basic lines are used to describe other I2C lines, such as here in imx8mp-verdin.dtsi:
&i2c3 {
clock-frequency = <400000>;
pinctrl-names = “default”, “gpio”;
pinctrl-0 = <&pinctrl_i2c3>;
pinctrl-1 = <&pinctrl_i2c3_gpio>;
scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
};

Here is my section:
&i2c6 {
clock-frequency = <400000>;
pinctrl-names = “default”, “gpio”;
pinctrl-0 = <&pinctrl_i2c6>;
pinctrl-1 = <&pinctrl_i2c6_gpio>;
scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = “okay”;
};

Which does compile and build correctly if I take the offending lines out.

Greetings @Evets,

If these are the offending lines:

However, when I try to set the GPIO’s up as:
scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;

Then the most likely issue is that you’re not including the header file that defines GPIO_ACTIVE_HIGH and GPIO_OPEN_DRAIN. Keep in mind these properties are macros that are defined elsewhere. The header file for these macros would be <dt-bindings/gpio/gpio.h>. You’ll need to add this to your overlay, adjust the path to wherever you have this header file relative to the overlay.

You can see an example of includes being used in overlays here: colibri-imx8x_panel-res-touch-7inch_overlay.dts « overlays - device-tree-overlays.git - Sources for Device Tree Overlays

Best Regards,
Jeremias

@jeremias.tx

OK, that worked, thought I’d already tried that.

However, for some reason, I have tried disabling everything associated with the output pins, SODIMM 19 and 34, except to making the connection for I2c6, as shown below :

/ {
compatible = “toradex,verdin-imx8mp”;
};

&hdmi_connector {
status = “disabled”;
};
&i2c3 {
status = “disabled”;
};

&iomuxc {
pinctrl_i2c6: i2c6grp {
fsl,pins =
<MX8MP_IOMUXC_SAI5_RXFS__I2C6_SCL 0x400001c6>,
<MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c6>;
};

pinctrl_i2c6_gpio: i2c6gpiogrp {
		fsl,pins =
			<MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19		0x400001c6>,
			<MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20		0x400001c6>;
};

};
&i2c6 {
clock-frequency = <50000>;
pinctrl-names = “default”, “gpio”;
pinctrl-0 = <&pinctrl_i2c6>;
pinctrl-1 = <&pinctrl_i2c6_gpio>;
status = “okay”;
scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
};

However, when I look at the i2C system using i2cdetect -l I get:
i2c-0 i2c 30a20000.i2c I2C adapter
i2c-1 i2c 30a30000.i2c I2C adapter
i2c-2 i2c 30a40000.i2c I2C adapter
i2c-3 i2c 30a50000.i2c I2C adapter
i2c-6 i2c DesignWare HDMI I2C adapter

And my i2c-6 is hooked up to /dev/verdin-i2c3 → I2c-6 and as you see it has the DesignWare HDMI driver is hooked up to it. I can’t seem to get rid of this and the only thing that shows up on i2C-6 is at address 0x30, not 0x48 which is where the chip that it is hooked up to 19 and 34 as I2c6.

Any suggestions to get this driver off my line? And hopefully connect to my chip? I don’t see any other place where the driver is installed.

Thanks,
Steve

Be aware that the i2c enumeration in Linux is not the same as the enumeration in the device tree. In Linux the numbering starts with 0 while in the device tree the numbering starts with 1. This means the i2c you’re looking for in Linux is one less than the i2c in the device tree.

So i2c6 in the device tree is i2c-5 in Linux. This means looking at your output for i2cdetect -l I don’t see your custom i2c enabled at all. I used the following device tree overlay and I can see the new i2c enabled:

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include "imx8mp-pinfunc.h"

/ {
        compatible = "toradex,verdin-imx8mp";
};

&pwm3 {
        status = "disabled";
};

&i2c6 {
        clock-frequency = <400000>;
        pinctrl-names = "default", "gpio";
        pinctrl-0 = <&pinctrl_i2c6>;
        pinctrl-1 = <&pinctrl_i2c6_gpio>;
        scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
        sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
        status = "okay";
};

&iomuxc {
        pinctrl_i2c6: i2c6grp {
                fsl,pins =
                        <MX8MP_IOMUXC_SAI5_RXFS__I2C6_SCL 0x400001c6>,
                        <MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c6>;
        };

        pinctrl_i2c6_gpio: i2c6gpiogrp {
                fsl,pins =
                        <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19             0x400001c6>,
                        <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20              0x400001c6>;
        };
};

With this overlay here’s what i see on my device:

torizon@verdin-imx8mp-06849059:~$ i2cdetect -l
i2c-0   i2c             30a20000.i2c                            I2C adapter
i2c-1   i2c             30a30000.i2c                            I2C adapter
i2c-2   i2c             30a40000.i2c                            I2C adapter
i2c-3   i2c             30a50000.i2c                            I2C adapter
i2c-5   i2c             30ae0000.i2c                            I2C adapter

This is without any other overlays enabled. Remember i2c-5 here corresponds to i2c6 in the device tree.

Best Regards,
Jeremias

1 Like

@jeremias.tx
Thank you, I will try putting the status = “okay”; after the gpio declaration. Mine is in there, it was just above that.
I see you have the &iomuxc declaration after the &i2c6 declaration. Is that the way it is supposed to be? Does it matter?
And when you are saying “This is without any other overlays enabled”, does that include the multiple overlays for the dev board?

Thanks!
Steve

@jeremias.tx
OK, I tried the things above and I still get the same thing, no i2c5. So I literally copied yours and built it and deployed it. I still get:
i2c-0 i2c 30a20000.i2c I2C adapter
i2c-1 i2c 30a30000.i2c I2C adapter
i2c-2 i2c 30a40000.i2c I2C adapter
i2c-3 i2c 30a50000.i2c I2C adapter
i2c-6 i2c DesignWare HDMI I2C adapter

Here is my tcbuild.yaml:

input:
easy-installer:
local: torizon-core-docker-verdin-imx8mp-Tezi_6.4.0-devel-202309+build.13.tar

Sample customization: insert the hdmi overlay in the IMX8mp

customization:
device-tree:
include-dirs:
- linux/arch/arm64/boot/dts/freescale
- linux/include
- device-trees/include
overlays:
add:
- device-trees/overlays/verdin-imx8mp-gimbal3b-overlay.dts

output:
easy-installer:
local: torizon-core-docker-verdin-imx8mp-Tezi_6.4.0-devel-202309+build.13.CUSTOM

Any clues as to why it’s not working? I have used this same yaml file before successfully adding another SPI port.

I also tried this on the Verdin dev board with the same result.

Steve

Well I see you still have:

i2c-6 i2c DesignWare HDMI I2C adapter

Listed in your i2cdetect. Did you make sure to remove all other overlays except yours? By default our OS images have some overlays applied by default. Did you make sure to remove these when applying yours?

Once I did this I no longer have i2c-6 listed on my device anymore.

Best Regards,
Jeremias

@jeremias.tx
So you just have imx8mp-verdin.dtsi?

So you just have imx8mp-verdin.dtsi?

I think you’re misunderstanding me. imx8mp-verdin.dtsi is not an overlay. This is a device tree include file. I’m asking you if you have any other overlays applied besides the overlay to enable the additional i2c. When the device boots you can see all the overlays being applied in the boot logs. Are there any other overlays?

Our out of the box image has some overlays being applied by default. One of these overlays is responsible for i2c-6 i2c DesignWare HDMI I2C adapter, another one uses SODIMM 19 which is in conflict with your overlay. Since you are still seeing this on your device, it means you have these additional default overlays still applied. I’m asking you to remove these other overlays.

Look this is my tcbuild.yaml:

input:
  easy-installer:
    local: torizon-core-docker-verdin-imx8mp-Tezi_6.5.0+build.8.tar

customization:
  device-tree:
    include-dirs:
      - linux/include
    overlays:
      clear: true
      add:
        - linux/arch/arm64/boot/dts/freescale/test.dts

output:
  easy-installer:
    local: test

See the clear: true property this removes all other overlays before adding the custom overlay for i2c6. This is what I mean by clearing the other overlays. Please do this.

Best Regards,
Jeremias

1 Like

@jeremias.tx
My tcbuild.yaml file is the same other than I’m using 6.4.0+build.13. and I have 2 other include directories as these were in the original build:
linux/arch/arm64/boot/dts/freescale
device-trees/include

I also added the clear: true to my .yaml file as that was the only thing missing.

I still get the same thing. I tried changing the original imx8mp-verdin-wifi-dev.dts file to not include the additional dtsi files, but still no joy. I also tried taking out the extra include dirs, but mine won’t compile without the linux/arch/arm64/boot/dts/freescale one because that’s where the imx8mp-pinfunc.h file is.

Thanks,
Steve

OK, so another person here who was working on pin issues earlier, said he had to do an unpack on the custom directory, then deploy to the target before things would work. According to the documetation, it doesn’t say that is needed. But after I did that, I could then see i2C5!

Steve

@jeremias.tx
OK, so while it shows up in /dev/, when I run i2cdetect -y 5, each address is run very slowly, like 1 second per address, and no responses. On all the other buses, listing them takes about 3 seconds or less to show the entire address list.
Maybe I spoke too soon.

It is running at.89 htz. That makes no sense.

We have the default frequency at 400000hz. Why would it run at .89 htz?

Steve

Glad to hear you finally see i2c5.

As for your speed issue. I’m honestly not sure. I don’t see this on my side i2cdetect is quick and snappy. Though I don’t have anything connected on i2c5. I imagine something in your setup is causing the entire interface to be slow or something to that effect. Though it’s really hard to say as I can’t reproduce this behavior you are seeing.

Best Regards,
Jeremias

It was the description of the outputs:
<MX8MP_IOMUXC_SAI5_RXFS__I2C6_SCL 0x400001c6>,
<MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c6>;
and
<MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19 0x400001c6>,
<MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20 0x400001c6>;

I was using using just 0x1c6, rather than the 0x400001c6. This corrected the issue. I am not sure why this worked though, so if you can enlighten me, it would be helpful. When I rechecked in the imx8mp-verdin.dtsi, all the I2C outputs were described this way. Which is what I had in the beginning but others were without that, so I changed it trying to get it to show up. Anyway, all is working now.

Steve

@jeremias.tx
OK, there is one other thing. I can’t debug anymore. I had to add the spi driver back in to get that part working, but now it goes through all the normal setup, uploads the image, but fails in the last step:

ssh: connect to host 192.168.12.241 port 2230: Connection refused
lost connection

** * The terminal process “scp ‘-i’, ‘/home/steve/Gimbal3b/.conf/id_rsa’, ‘-o’, ‘UserKnownHostsFile=/dev/null’, ‘-o’, ‘StrictHostKeyChecking=no’, ‘-P’, ‘2230’, ‘-pr’, ‘/home/steve/Gimbal3b/aarch64/debug’, ‘root@192.168.12.241:~/app’” failed to launch (exit code: 1). **
** * Terminal will be reused by tasks, press any key to close it.**

Do you know why it is failing this? If I go back to the original dev board device tree, it works fine. But in this stripped down version, I can’t connect because it refuses the ssh connection.

Yet I can ssh into the board just fine. It looks like the debug container isn’t running.

I did see this in run-torizon-binfmt tab:
container Runtime: docker
Run Arguments: --rm --privileged torizon/binfmt
Container Name: binfmt
Error response from daemon: No such container: binfmt
Container does not exists. Starting 


  • Terminal will be reused by tasks, press any key to close it.

Steve

@jeremias.tx
So, I changed my compatibility statement in the beginning of the overlay to include all the versions:
compatible = “toradex,verdin-imx8mp-wifi-dev”,
“toradex,verdin-imx8mp-wifi”,
“toradex,verdin-imx8mp”,
“fsl,imx8mp”;
And now I can get it to come up briefly, to the first statement, but then It is gone. It also doesn’t seem to upload the entire debug container, which in my case is like almost 3 GB. This only does about 9.8 MB before it gets to the location, and then shows the first lines of code with the highlight, then the debugger exits.

ERROR: GDB exited unexpectedly with exit code 255 (0xFF). Debugging will now abort.

I doubt the device tree change for i2c is fully responsible for the debug/ssh issue you’re now seeing. It just doesn’t make sense that adding an i2c in the device tree would result in such an issue.

I tested this on my own device with the i2c device tree change and I’m able to debug just fine with VSCode. Though it is just a simple hello-world application.

Perhaps you did some other change recently besides the i2c change we discussed that is causing this. Otherwise if we’re just talking about the changes we did in this thread, then I’m not seeing what you’re seeing.

Best Regards,
Jeremias

@jeremias.tx
Well, it is definitely the tree issue. I am not just adding I2c by eliminating the current overlays, I am removing additional items. I can go back to the default without my change and it comes up just fine. I added this to my Overlay’s &iomuxc:
pinctrl_ecspi1: ecspi1grp {
fsl,pins =
<MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x1c4>, /* SODIMM 198 /
<MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x4>, /
SODIMM 200 /
<MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x4>, /
SODIMM 196 /
<MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x1c4>; /
SODIMM 202 /
};
And this statement for SPI_1 since it is an overlay that was removed.
/
Verdin SPI_1 /
&ecspi1 {
#address-cells = <1>;
#size-cells = <0>;
cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_ecspi1>;
};
/
Verdin SPI_1 this turns on the driver for SPI */
&ecspi1 {
#address-cells = <1>;
#size-cells = <0>;
status = “okay”;

    spidev@0 {
            /* Use compatible "rohm,dh2228fv" to bind spidev driver */
            compatible = "rohm,dh2228fv";
            reg = <0>;
            spi-max-frequency = <10000000>;
    };

};
I haven’t tried removing that to see if I can debug with just the i2c change, but I will try that.

Steve

@jeremias.tx
Well, without the SPI changes, so back to your original file, it still will not hold the debugger running GDB crashes. I am running on our own carrier board. You are running on the Dev board, correct? I will try this build on the dev board and see if I can get it to run there.

Steve

@jeremias.tx
I get the same basic problem with the dev board, but in this case, rather than a GDB abnormal exit, something kills it. Here is the debug output:
Breakpoint 1, main (argc=2, argv=0xffffd87b16d8) at src/gimbal-main.cpp:101
Loaded ‘/lib/ld-linux-aarch64.so.1’. Symbols loaded.
Loaded ‘/lib/aarch64-linux-gnu/libgpiod.so.2’. Symbols loaded.
Loaded ‘/lib/aarch64-linux-gnu/libstdc++.so.6’. Symbols loaded.
Loaded ‘/lib/aarch64-linux-gnu/libm.so.6’. Symbols loaded.
Loaded ‘/lib/aarch64-linux-gnu/libgcc_s.so.1’. Symbols loaded.
Loaded ‘/lib/aarch64-linux-gnu/libc.so.6’. Symbols loaded.
Execute debugger commands using “-exec ”, for example “-exec info registers” will list registers in use (when GDB is the debugger)
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 33) killed]
The program ‘~/app/Gimbal3b’ has exited with code 0 (0x00000000).

Where does that come from: the Y? it’s as though I hit the stop button.

On my second try, I got a different message of an error when it tried to stop at the breakpoint:
Breakpoint 1, main (argc=2, argv=0xffffc12dfaf8) at src/gimbal-main.cpp:101
ERROR: Error while trying to enter break state. Debugging will now stop. Broken pipe
The program ‘~/app/Gimbal3b’ has exited with code 42 (0x0000002a).

It actually looks like it can’t start the docker container. Because it’s never showing as running.

Steve