Difference between revisions of "Tests:I2C-bus-recovery-write-byte-fix"

From eLinux.org
Jump to: navigation, search
(first part)
 
(second paragraph added)
Line 30: Line 30:
 
== Software Environment ==
 
== Software Environment ==
  
−
A busybox with standard commands like ''cd'', ''cat'', ''echo'' is needed. Also, ''i2cget'' and ''i2cdump'' from the i2c-tools package should be available.
+
A busybox with standard commands like ''cd'', ''cat'', ''echo'' is needed. Also, ''i2cget'' from the i2c-tools package should be available.
  
 
=Previous state=
 
=Previous state=
 
As documented in the test page for [[Tests:I2C-bus-recovery]], the bus recovery mechanism of the Linux I2C core was able to
 
As documented in the test page for [[Tests:I2C-bus-recovery]], the bus recovery mechanism of the Linux I2C core was able to
−
resurrect a stalled bus. However, the implementation had a flaw which could lead to accidental writes to a device during recovery. To demomstrate this,
+
resurrect a stalled bus. However, the implementation had a flaw which could lead to accidental writes to a device during recovery. To demonstrate this,
−
a new fault injector was implemented. From its documentation:
+
a new fault injector was implemented. For a summary about I2C fault injection, have a look here: [[Tests:I2C-fault-injection]]
  
−
        "incomplete_write_byte"
+
The Renesas I2C IP core is special, because it cannot read the SDA status directly, only set SDA. This leads to an undesired write when the following
−
        -----------------------
+
sequence of commands is executed:
−
       
 
−
        Similar to above, this file is write only and you need to write the address of
 
−
        an existing I2C client device to it.
 
−
       
 
−
        The injector will again stop at one ACK phase, so the device will keep SDA low
 
−
        because it acknowledges data. However, there are two differences compared to
 
−
        'incomplete_address_phase':
 
−
       
 
−
        a) the message sent out will be a write message
 
−
        b) after the address byte, a 0x00 byte will be transferred. Then, stop at ACK.
 
−
       
 
−
        This is a highly delicate state, the device is set up to write any data to
 
−
        register 0x00 (if it has registers) when further clock pulses happen on SCL.
 
−
        This is why bus recovery (up to 9 clock pulses) must either check SDA or send
 
−
        additional STOP conditions to ensure the bus has been released. Otherwise
 
−
        random data will be written to a device!
 
  
−
If you are not familiar with I2C fault injection yet, have a look here: [[Tests:I2C-fault-injection]]
+
Setup fault injector on the Renesas Lager board:
−
 
 
−
 
 
−
 
 
−
=Testing I2C bus recovery=
 
−
After booting, we activate the I2C GPIO fault injector:
 
 
<pre>
 
<pre>
 
# echo 2 > /sys/devices/platform/i2c-11/current_master
 
# echo 2 > /sys/devices/platform/i2c-11/current_master
 
i2c-gpio i2c-8: using lines 979 (SDA) and 978 (SCL)
 
i2c-gpio i2c-8: using lines 979 (SDA) and 978 (SCL)
−
</pre>
 
−
 
−
Then, we switch I2C2 from the IIC to the I2C IP core, where bus recovery was implemented:
 
−
<pre>
 
 
# echo 1 > /sys/devices/platform/i2c-12/current_master
 
# echo 1 > /sys/devices/platform/i2c-12/current_master
 
i2c-rcar e6530000.i2c: probed
 
i2c-rcar e6530000.i2c: probed
 +
# cd /sys/kernel/debug/i2c-fault-injector/i2c-8/
 
</pre>
 
</pre>
  
−
Now, we create the stalled SDA case again using the [[Tests:I2C-fault-injection|I2C fault injector]]:
+
Check original value of register 0 from device 0x12. It is 0x00 now:
 
<pre>
 
<pre>
−
# cd /sys/kernel/debug/i2c-fault-injector/i2c-8/
+
# i2cget -y -f 2 0x12 0
−
# echo 0x12 > incomplete_transfer
+
0x00
 
</pre>
 
</pre>
  
−
Using a scope, we verify that SDA is stuck low and needs to be recovered:
+
Use the ''incomplete_write_byte'' fault injector. Then, read register 8 to enforce bus recovery. Note that the read value from register 8 succeeds,
−
[[File:wsa-i2c_fi-device-keeps.png|800x428px|Incomplete transfer on Lager, device does not react]]
+
so the stalled bus has been corrected. Also, the register value 0xe1 is correct:
−
 
 
−
Now, we try to read register 8 from the audio codec via the stalled I2C bus:
 
 
<pre>
 
<pre>
 +
# echo 0x12 > incomplete_write_byte
 
# i2cget -y -f 2 0x12 8
 
# i2cget -y -f 2 0x12 8
 
0xe1
 
0xe1
 
</pre>
 
</pre>
  
−
So, we got a valid response from this read request. Using a scope, we see the following happening:
+
But if we read out register 0 again, it has been modified to 0xff! Which is the result of having SDA high all the time while clocking SCL:
−
[[File:Wsa-i2c_fi_recovery_complete.png|800x428px|Successful example of a I2C recovery releasing a stuck SDA]]
+
<pre>
 +
# i2cget -y -f 2 0x12 0
 +
0xff
 +
</pre>
 +
 
 +
Here is a scope of that scenario:
 +
 
 +
[[File:Wsa-i2c_fi-recovery-unwanted-write.png|800x428px|]Scope of an I2C bus recovery causing an undesired write to a device.]]
  
−
We see left of the markers that SCL was toggled until the audio codec released SDA again. There is one clock cycle done more than necessary.
+
You can even see the device acknowledging the sent byte.
−
This is due to the fact that the I2C IP core can't read back the status of the SDA line, so we always have to perform the maximum number of
 
−
clock cycles to be sure the line gets released. Nonetheless, the stuck SDA condition was detected and successfully recovered from.
 
  
−
Within the markers, we see that a valid STOP condition has been put onto the bus, to create a known bus state again. This is now possible
+
=Fixed state=
−
because SDA was released by the device and can now be controlled by the master again.
 
  
−
Right of the markers, we see the originally intended I2C transfer which reads out register 8 from the audio codec without any problems.
+
https://elinux.org/File:Wsa-i2c_fi-recovery-write_byte_with_stop.png
−
Also, the bus is in the correct idle state again after that transfer.
 
  
 
=Conclusion=
 
=Conclusion=
 
It could be shown that the implementation of I2C bus recovery in the R-Car I2C driver using the I2C core helpers was able to recover from a stalled bus.
 
It could be shown that the implementation of I2C bus recovery in the R-Car I2C driver using the I2C core helpers was able to recover from a stalled bus.
 
Even though SDA was held low by a device in an inconsistent state, it was recovered and the whole bus was brought back to a known state.
 
Even though SDA was held low by a device in an inconsistent state, it was recovered and the whole bus was brought back to a known state.

Revision as of 08:54, 2 July 2018

This document describes how to test if I2C bus recovery was fixed to not accidently write bytes during recovery. A Renesas I2C IP core used on a Renesas Lager board serves as an example platform here.

Setup

Kernel Version and Configuration

Support for this feature is expected to land upstream in v4.19. It is currently available in a topic branch:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/i2c/recovery/write-byte-fix

The following kernel options need to be set in addition to the defconfig: 

CONFIG_I2C_GPIO=y
CONFIG_I2C_GPIO_FAULT_INJECTOR=y

Hardware Environment

Lager/r8a7790 (R-Car H2 SoC)

You need to connect the pins: 

EXIO_C 78 <-> EXIO_A 58 (for SCL)
EXIO_C 80 <-> EXIO_A 60 (for SDA)

This will connect the I2C1 and the I2C2 bus. We will use the I2C demultiplexer at runtime to switch I2C1 to GPIO: 

# echo 2 > /sys/devices/platform/i2c-11/current_master

Software Environment

A busybox with standard commands like cd, cat, echo is needed. Also, i2cget from the i2c-tools package should be available.

Previous state

As documented in the test page for Tests:I2C-bus-recovery, the bus recovery mechanism of the Linux I2C core was able to resurrect a stalled bus. However, the implementation had a flaw which could lead to accidental writes to a device during recovery. To demonstrate this, a new fault injector was implemented. For a summary about I2C fault injection, have a look here: Tests:I2C-fault-injection

The Renesas I2C IP core is special, because it cannot read the SDA status directly, only set SDA. This leads to an undesired write when the following sequence of commands is executed:

Setup fault injector on the Renesas Lager board: 

# echo 2 > /sys/devices/platform/i2c-11/current_master
i2c-gpio i2c-8: using lines 979 (SDA) and 978 (SCL)
# echo 1 > /sys/devices/platform/i2c-12/current_master
i2c-rcar e6530000.i2c: probed
# cd /sys/kernel/debug/i2c-fault-injector/i2c-8/

Check original value of register 0 from device 0x12. It is 0x00 now: 

# i2cget -y -f 2 0x12 0
0x00

Use the incomplete_write_byte fault injector. Then, read register 8 to enforce bus recovery. Note that the read value from register 8 succeeds, so the stalled bus has been corrected. Also, the register value 0xe1 is correct: 

# echo 0x12 > incomplete_write_byte
# i2cget -y -f 2 0x12 8
0xe1

But if we read out register 0 again, it has been modified to 0xff! Which is the result of having SDA high all the time while clocking SCL: 

# i2cget -y -f 2 0x12 0
0xff

Here is a scope of that scenario:

]Scope of an I2C bus recovery causing an undesired write to a device.

You can even see the device acknowledging the sent byte.

Fixed state

https://elinux.org/File:Wsa-i2c_fi-recovery-write_byte_with_stop.png

Conclusion

It could be shown that the implementation of I2C bus recovery in the R-Car I2C driver using the I2C core helpers was able to recover from a stalled bus. Even though SDA was held low by a device in an inconsistent state, it was recovered and the whole bus was brought back to a known state.

Retrieved from "https://elinux.org/index.php?title=Tests:I2C-bus-recovery-write-byte-fix&oldid=470941"