m7621 i2c read failure

Peter Naulls peter at chocky.org
Thu Feb 16 12:37:44 PST 2023


On 2/16/23 13:59, Jan Breuer wrote:
> On 16. 2. 2023 16:21, Peter Naulls wrote:
>>
>> On 2/15/23 13:31, Peter Naulls wrote:
>>>
>>> I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
>>>
>> x00
> 
> Can you please provide info about the exact SoC and hardware you are using?

Hi Jan, thanks for responding.  I probably cut too much of the original
message, but it's an mt7621 board, made by Atel.  Presumably heavily based
upon the original reference board, but I couldn't say for sure.  I don't
believe it's hugely different to any of the other mt7621 systems; certainly
the dts only varies in things like GPIO location and flash layout etc.


> I'm a little bit lost here. It seems to me, that also the vendor
> driver does not work all the time for you and you must "reset"
> something, but maybe I just misunderstood this.

I think the "reset" was a red herring due to a daemon I had running which
also queried the i2c bus (wrongly).  The i2c code on the MCU does seem a
bit fragile, but in any case appears to be now working as expected with the
vendor/old kernel driver.

The vendor driver appears to be also be the driver from OpenWrt 18.02ish
which is from before your changes.  I suspect it doesn't have any
changes from the vendor, but I would have to do some careful checking to
make entirely sure.

> Can you please describe the exact protocol you would like to implement
> in terms of I2C and what device is on the other side?


The other end is an MCU with a software setup i2c protocol - it's
pretty simple, but here's for example some queries to get the firmware version 
etc that I had posted originally:

------------------------


Writes work correctly. This for example sets LEDs via i2c (handled by the MCU 
and its GPIOs - I control this code too):


# i2ctransfer -y 0 w1 at 0x50 0x43 w3 3 2 1
Wed Feb 15 18:23:01 2023 kern.debug kernel: [  307.979880] i2c i2c-0: ioctl, 
cmd=0x705, arg=0x7fb736f0
Wed Feb 15 18:23:01 2023 kern.debug kernel: [  307.979927] i2c i2c-0: ioctl, 
cmd=0x703, arg=0x50
Wed Feb 15 18:23:01 2023 kern.debug kernel: [  307.979954] i2c i2c-0: ioctl, 
cmd=0x707, arg=0x7fb736f0


# i2ctransfer -y 0 w1 at 0x50 1 r1
Wed Feb 15 18:23:04 2023 kern.debug kernel: [  310.921389] i2c i2c-0: ioctl, 
cmd=0x705, arg=0x7febfd60
Wed Feb 15 18:23:04 2023 kern.debug kernel: [  310.921437] i2c i2c-0: ioctl, 
cmd=0x703, arg=0x50
Wed Feb 15 18:23:04 2023 kern.debug kernel: [  310.921463] i2c i2c-0: ioctl, 
cmd=0x707, arg=0x7febfd60
0x03
# i2ctransfer -y 0 w1 at 0x50 1 r1
Wed Feb 15 18:23:06 2023 kern.debug kernel: [  312.714856] i2c i2c-0: ioctl, 
cmd=0x705, arg=0x7feaf3e0
Wed Feb 15 18:23:06 2023 kern.debug kernel: [  312.714903] i2c i2c-0: ioctl, 
cmd=0x703, arg=0x50
Wed Feb 15 18:23:06 2023 kern.debug kernel: [  312.714928] i2c i2c-0: ioctl, 
cmd=0x707, arg=0x7feaf3e0
0x00

In particular, for the first read attempt, the value is always the first
value sent as part of the last write. i.e, 3 in this case. After, that,
it's always 0 (the correct answer ought to be 0xf).


The original post is here:

http://lists.openwrt.org/pipermail/openwrt-devel/2023-February/040509.html

Thanks!






More information about the openwrt-devel mailing list