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:
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?
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?
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.
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:
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…
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:
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().
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.