Question about i2c troubleshooting

Howdy,
I'm trying to get the rtc working on an armada-370 device but am having trouble getting the i2c bus to work. I can tell from the dmesg output from the stock firmware that the rrtc works and is connected via i2c. In fact I've had no trouble with some very similar devices (with the same stock dmesg output) but haven't had luck with this one but am encountering this on multiple units of this same model (i'm confident it isn't an issue with the individual device).

I've tried changing the pins from the default for the device to some of the alternates and have tried adjusting the bus speed but haven't had much luck. I have noticed that after I unplug the device and plug it back in (but not after a soft reboot) I get the following when starting the scan:

client found at address 0x48

This makes me think the chip might be getting into a bad state which requires power cycling to clear.

The dmesg output I see in stock firmware and on other working devices in debian is:

i2c /dev entries driver
rtc-rs5c372 0-0032: rs5c372a found, 24hr, driver version 0.6
rtc-rs5c372 0-0032: create wakealarm
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0

The error I'm seeing when i2cdetect fails is:

[ 6945.844595] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0

The device tree for this device can be seen here:
https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Buster/device_trees/armada-370-terastation-ts1400d.dts

does @bohdi or anyone have any advice on how to troubleshoot i2c issues like this? I'm reloading the stock firmware now examine a working system but don't know exactly what to look for.

any help would be greatly appreciated.

@1000001101000,

I don't have much experience troubleshooting i2c.

It has been a long time ago, but I do remember this error. In my case, it probably meant that the mv64xxx is not supposed to be used (the fact that it shows up in your dmesg is probably a hint). But I am not sure.

[ 6945.844595] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0

This is my NSA325 dmesg

[    7.317743] mousedev: PS/2 mouse device common for all mice
[    7.324295] i2c /dev entries driver
[    7.334774] rtc-pcf8563 0-0051: registered as rtc0
[    7.343131] hidraw: raw HID events driver (C) Jiri Kosina

I think we can see the similarity with you box

i2c /dev entries driver
rtc-rs5c372 0-0032: rs5c372a found, 24hr, driver version 0.6
rtc-rs5c372 0-0032: create wakealarm
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0

Both use a different rtc chip and driver, not Marvell RTC.

And your DTS:

			rtc@10300
			{
				status = "disabled";
			};

<snip>

i2c@11000
			{
				status = "okay";
				clock-frequency = <100000>;

				rs5c372: rs5c372@32
				{
					compatible = "ricoh,rs5c372a";
					reg = <0x32>;
				};
			};

My DTS for NSA325

/* This board uses the pcf8563 RTC instead of the SoC RTC */
                rtc@10300 {
                        status = "disabled";
                };

                i2c@11000 {
                        status = "okay";

                        pcf8563: pcf8563@51 {
                                compatible = "nxp,pcf8563";
                                reg = <0x51>;
                        };
                };

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/02/2019 05:29PM by bodhi.

I’m 99% sure that I got to detect the chip once a few days ago when I was troubleshooting a UART issue. I didn’t pay much attention since I thought fixing the UART pins resolved some kind of conflict. I wonder if stumbled across some sort of power/chip select pin without realizing it... or imagined it.

I think i’ll work it from that angle for a while. I didn’t find any meaningful differences between devices on the stock firmware so far.

Was finally able to confirm that trying to scan this i2c bus locks something up if you try to scan it and it stays that way across resets until you physically disconnect power. It works fine if you just use the rtc without trying to scan via i2cdetect or sensors-detect.

I confirmed this happens with the i2c-mv64xxxx driver and using the i2c-gpio “bitbang” driver.

I’m still narrowing down the specifics as to why this happens for this model and not others with the same SoC/RTC combination to see if there is something I can do to prevent it locking up like this. Having to pull the plug and restart after each experiment is a pain.

Had the same problem while connecting NanoPi Duo2 to pressure sensor via i2c

Solved by placing 10k pull-up resistors between SDA and VCC, SDL and VCC

otherwise bus is in unknown state without them

these resistors are mandatory on i2c bus!!!!!!!!!

lol, maybe Buffalo forgot a resistor on their board design.