Change I2C2 Pins to P9_21 and P9_22 fails

General Discussion
1

Hello,
I have an extention board where I use d_can0 and d_can1.
To free Pin P9_19 and P9_20 for d_can0, I switched I2C-2 to P9_21 and P9_22 in mode 2
On these I2C-2 pins I have connected a RTC DS1307

My device overlay worked fine with Debian 9 and Kernel 4_14
Now I want to update to the current Debian11 image.

I will try to give a clear summary of what I tried yet
This is the overlay that I want to use
BB-I2C2-ALTERNATIVE-RTC-DS1307.dts (2,3 KB)

When I am only using this overlay, probe of rtc-ds1307 in overlay fails and I2C controller seems to be “blocked”.

[    5.001137] omap_i2c 4819c000.i2c: controller timed out
[    5.006636] rtc-ds1307: probe of 2-0068 failed with error -110
[    6.057122] omap_i2c 4819c000.i2c: controller timed out
[    7.113107] omap_i2c 4819c000.i2c: controller timed out
[    8.169124] omap_i2c 4819c000.i2c: controller timed out
[    9.225105] omap_i2c 4819c000.i2c: controller timed out
[   10.281125] omap_i2c 4819c000.i2c: controller timed out
[   11.337115] omap_i2c 4819c000.i2c: controller timed out
[   12.393125] omap_i2c 4819c000.i2c: controller timed out
[   13.449110] omap_i2c 4819c000.i2c: controller timed out
[   13.467247] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz

Also i2cdetect -r 2 is not able to find anything, it is only showing -- --… for all address

When I combine this overlay with the BB-CAN0-00A0.dtbo, than it still can not probe in boot sequence but i2cdetect -r 2 is now able to detect the 68 which is the address of the ds1307.

The OF_FULLNAME looks different compared to old linux.
With Kernel 5.10:

OF_NAME=ds1307
OF_FULLNAME=/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/ds1307@68

With Kernel 4.14:

OF_FULLNAME=/ocp/i2c@4819c000/ds1307@68

When I run this on a standalone beaglebone black, than I can not see the “controller timed out” messages with dmesg but as soon as I boot with connect extention board, these messages are there.

When I remove the ds1307 lines from the overlay (lines 67 and 100-102), than I am able to manually probe the ds1307

root@BeagleBone:/sys/class/i2c-dev/i2c-2/device# echo ds1307 0x68 > /sys/class/i2c-dev/i2c-2/device/new_device
root@BeagleBone:/sys/class/i2c-dev/i2c-2/device# dmesg | grep i2c
[    7.840438] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[    8.887850] i2c /dev entries driver
[    9.114806] input: tps65217_pwr_but as /devices/platform/ocp/44c00000.interconnect/44c00000.interconnect:segment@200000/44e0b000.target-module/44e0b000.i2c/i2c-0/0-0024/tps65217-pwrbutton/input/input0
[    9.117005] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[   10.154779] omap_i2c 4819c000.i2c: controller timed out
[   11.210751] omap_i2c 4819c000.i2c: controller timed out
[   12.266800] omap_i2c 4819c000.i2c: controller timed out
[   13.322743] omap_i2c 4819c000.i2c: controller timed out
[   14.378760] omap_i2c 4819c000.i2c: controller timed out
[   15.434750] omap_i2c 4819c000.i2c: controller timed out
[   16.490761] omap_i2c 4819c000.i2c: controller timed out
[   17.546750] omap_i2c 4819c000.i2c: controller timed out
[   17.564879] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[  371.212227] i2c i2c-2: new_device: Instantiated device ds1307 at 0x68

Does anyone have an idea on how to solve it?

  • Where is i2c2 initialized first? Is it possible to initialize it directly to P9_21 and P9_22?
  • Why does reconfiguring take approx. 7sec?
  • Why does reconfiguring seems to depend on initialyzing P9_19 and P9_20 to d_can0_rx/tx?
  • Why there is a dependency whether the pins are free or the can transceiver and the ds1307 are connected?
  • Is it possible to remove existing i2c2 before making the new device on the alternative pins?
  • Is it possible to delay probing of ds1307 in overlay? 10sec additional time before ds1307 works does not matter for me

Many thanks
Martin

2

Hi @Martin_Voelz that should work, can you please share your full serial boot log… (including u-boot)…

Both those set of pins share i2c2, moving P9_19/P9_20 is needed as by default it’s i2c, so it would short between P9_21/P9_22 and make i2c transactions interesting…

Regards,

3

Answer part4

And my last test was to set P9_19/P9_20 to gpio in can0 pingroup, than P9_21/P9_22 to i2c2 and as a last step P9_19/P9_20 to can0 mode.
But this overlay did not compile with error “dublicat node name”:
BB-FLASHBOX-CAPE-00A0_dublicateNodeName.dts (6,9 KB)

Do you have any suggestions how to solve this?

Thanks Martin

4

Answer part3

To solve this I tried is to put all the settings into one overlay file and put the can0 settings before the i2c2 settings. Unfortunatly this did not work. Controller timed out again:
BB-FLASHBOX-CAPE-00A0.dts (6,6 KB)
bootlog_completeOverlayInOneFile.txt (4,9 KB)

5

Answer part2

Next thing I tried was to set P9_19/P9_20 to GPIO mode before setting P9_21/P9_22 to i2c2.
Without much thinking, I did this inside the i2c2-pingroup and now i2c2 init works.

root@BeagleBone:~# dmesg | grep ds1307
[    4.003779] rtc-ds1307 2-0068: registered as rtc1
root@BeagleBone:~# cd /dev
root@BeagleBone:/dev# ls rt*
rtc  rtc0  rtc1

Unfortunatly, now CAN0 can not get the pins, because they are in i2c2 pingroup.

[   29.543473] pinctrl-single 44e10800.pinmux: pin PIN95 already requested by 4819c000.i2c; cannot claim for 481cc000.can
[   29.776049] pinctrl-single 44e10800.pinmux: pin-95 (481cc000.can) status -22
[   29.869397] pinctrl-single 44e10800.pinmux: could not request pin 95 (PIN95) from group pinmux_dcan0_pins  on device pinctrl-single
[   29.992577] c_can_platform 481cc000.can: Error applying setting, reverse things back

BB-I2C2-ALTERNATIVE-RTC-DS1307.dts (2,6 KB)
bootlog_modified_i2c2_pinmux.txt (5,1 KB)

6

Hi @RobertCNelson,
thank you very much for this impulse for brainstorming. Thinking of the pins as physical connections makes it indeed much clearer.
I did some further tests with interesting results:

This is the bootlog from a standalone beaglebone black (can not check DS1307 because not connected):
bootlog_standalone_beagleboneblack.txt (4,3 KB)

This is the bootlog from beaglebone black and Cape PCB, DS1307 not working, Controller timed out:
bootlog_beagleboneblack_withCape.txt (5,2 KB)

I have to split my answer here, because as a new user I am only allowed to add two links.

7

From all my test, this is my current overview of the problem:

When I have the Pins P9_19 and P9_20 in the bb_i2c2_pins group, than CAN driver shows error at approx. 30 seconds after starting kernel. (This might happen, when I do not enable the BB-I2C2-ALTERNATIVE-RTC-DS1307.dts overlay for example)

[   29.543473] pinctrl-single 44e10800.pinmux: pin PIN95 already requested by 4819c000.i2c; cannot claim for 481cc000.can
[   29.776049] pinctrl-single 44e10800.pinmux: pin-95 (481cc000.can) status -22
[   29.869397] pinctrl-single 44e10800.pinmux: could not request pin 95 (PIN95) from group pinmux_dcan0_pins  on device pinctrl-single
[   29.992577] c_can_platform 481cc000.can: Error applying setting, reverse things back

When I assume, that CAN driver always needs so long to initialize the pins, than for the first 30sec, the I2C2 is connected to 4 pins at the same time. (Connected to DS1307 and CAN Transceiver) which might lead to not beeing able to communicate to the DS1307.

[    5.001137] omap_i2c 4819c000.i2c: controller timed out
[    5.006636] rtc-ds1307: probe of 2-0068 failed with error -110
[    6.057122] omap_i2c 4819c000.i2c: controller timed out
[    7.113107] omap_i2c 4819c000.i2c: controller timed out
[    8.169124] omap_i2c 4819c000.i2c: controller timed out
[    9.225105] omap_i2c 4819c000.i2c: controller timed out
[   10.281125] omap_i2c 4819c000.i2c: controller timed out
[   11.337115] omap_i2c 4819c000.i2c: controller timed out
[   12.393125] omap_i2c 4819c000.i2c: controller timed out
[   13.449110] omap_i2c 4819c000.i2c: controller timed out
[   13.467247] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz

The i2c driver seems to make retrys, but the rtc-ds1307 driver seems to try only once.

What I would need is a possibiliy to not only remove the P9_19 / P9_20 from the bb_i2c2_pins group (there they are by default), but also to change the mode of these pins already in the BB-I2C2-ALTERNATIVE-RTC-DS1307.dts overlay. (Not having to rely on CAN driver changing the mode of them)

8

I did some tests with the 4_14 kernel.

1.) when I only load the overlay for the alternative I2C2 pins and not the CAN0 overlay, than I have the same issue that “Controller timed out”

2.) When I do not load any overlay, I see a difference.
The 4_14 image does not have a i2c2 pingroup after boot. The pins P9_19 and P9_20 seem to be single pinmux pins.
The 5_10 image has an i2c2 pingroup with P9_19 and P9_20

Next thing I will try: Remove the settings for i2c2 in the am335x-bone-common.dtsi and recompile the am335x_boneblack_uboot.dts the because for my special usecase I do not need the CAPE eeproms.

9

Hello,
I tried changing the am335x-bone-common.dtsi in a way that it does not create a pingroup for i2c2 but this did not have success. Still “Controller times out” when probing the DS1307.

When comparing the files /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pingroups in both systems, I recognized:
In the Linux 4.14 file, CAN0 and CAN1 are the first devices in this file.
In the Linux 5.10 file, CAN0 and CAN1 are the last devices in this file.