at24 eeprom isn't working

[jk-ozlabs]

Looks like we get NAKs from the device:

root@palmetto:/sys/bus/i2c/devices/0-0050# hexdump -C eeprom 
hexdump: eeprom: Connection timed out
root@palmetto:/sys/bus/i2c/devices/0-0050# dmesg -c
i2c_aspeed 1e78a000.i2c: state[0], SCL[1], SDA[1], BUS[0]
i2c_aspeed 1e78a000.i2c: ast_i2c_do_byte_xfer 
i2c_aspeed 1e78a000.i2c: M cnt -1, xf len 2 
i2c_aspeed 1e78a000.i2c:  writeing 2 bytes to 0x50
i2c_aspeed 1e78a000.i2c: M clear isr: AST_I2CD_INTR_STS_TX_NAK = 2
i2c_aspeed 1e78a000.i2c: NAK error
i2c_aspeed 1e78a000.i2c: send stop 
i2c_aspeed 1e78a000.i2c: M clear isr: AST_I2CD_INTR_STS_NORMAL_STOP = 10
i2c_aspeed 1e78a000.i2c: end xfer ret = -11, xfer mode[0]
at24 0-0050: read 128@0 --> -121 (147715)
i2c_aspeed 1e78a000.i2c: state[0], SCL[1], SDA[1], BUS[0]
i2c_aspeed 1e78a000.i2c: ast_i2c_do_byte_xfer 
i2c_aspeed 1e78a000.i2c: M cnt -1, xf len 2 
i2c_aspeed 1e78a000.i2c:  writeing 2 bytes to 0x50
i2c_aspeed 1e78a000.i2c: M clear isr: AST_I2CD_INTR_STS_TX_NAK = 2
i2c_aspeed 1e78a000.i2c: NAK error
i2c_aspeed 1e78a000.i2c: send stop 
i2c_aspeed 1e78a000.i2c: M clear isr: AST_I2CD_INTR_STS_NORMAL_STOP = 10
i2c_aspeed 1e78a000.i2c: end xfer ret = -11, xfer mode[0]
at24 0-0050: read 128@0 --> -121 (147717)
i2c_aspeed 1e78a000.i2c: state[0], SCL[1], SDA[1], BUS[0]
i2c_aspeed 1e78a000.i2c: ast_i2c_do_byte_xfer 
i2c_aspeed 1e78a000.i2c: M cnt -1, xf len 2 
i2c_aspeed 1e78a000.i2c:  writeing 2 bytes to 0x50
i2c_aspeed 1e78a000.i2c: M clear isr: AST_I2CD_INTR_STS_TX_NAK = 2
i2c_aspeed 1e78a000.i2c: NAK error
i2c_aspeed 1e78a000.i2c: send stop 
i2c_aspeed 1e78a000.i2c: M clear isr: AST_I2CD_INTR_STS_NORMAL_STOP = 10
i2c_aspeed 1e78a000.i2c: end xfer ret = -11, xfer mode[0]
at24 0-0050: read 128@0 --> -121 (147719)

Dynamic debugging config:

$ echo 'module i2c_aspeed +p' > /sys/kernel/debug/dynamic_debug/control
$ echo 'func at24_eeprom_read +p' > /sys/kernel/debug/dynamic_debug/control

[jk-ozlabs]

.. whereas the RTC device on the same bus seems to work fine.

[jk-ozlabs]

@nkskjames is the address for this eeprom correct? We're addressing 0x50 on the first i2c bus.

[jk-ozlabs]

Hm, not even i2cdetect will find it at 0x50. Looks like an invalid address.

I do see a device at 0x71, but that doesn't look like the eeprom either.

@nkskjames : can we validate the addresses we have in the DT?

[shenki]

Looking at SCU90: Multi-function Pin Control #5:

Under the AST kernel:

 Enable I2C14 function pins: 0x0
 Enable I2C13 function pins: 0x0
 Enable I2C12 function pins: 0x0
 Enable I2C11 function pins: 0x0
 Enable I2C10 function pins: 0x0
 Enable I2C9 function pins: 0x0
 Enable I2C8 function pins: 0x1
 Enable I2C7 function pins: 0x1
 Enable I2C6 function pins: 0x1
 Enable I2C5 function pins: 0x1
 Enable I2C4 function pins: 0x1
 Enable I2C3 function pins: 0x1

On the OpenBMC kernel:

 Enable I2C14 function pins: 0x0
 Enable I2C13 function pins: 0x0
 Enable I2C12 function pins: 0x0
 Enable I2C11 function pins: 0x0
 Enable I2C10 function pins: 0x0
 Enable I2C9 function pins: 0x0
 Enable I2C8 function pins: 0x0
 Enable I2C7 function pins: 0x0
 Enable I2C6 function pins: 0x0
 Enable I2C5 function pins: 0x0
 Enable I2C4 function pins: 0x1
 Enable I2C3 function pins: 0x0

Note that we don't reinitalise these values at boot, so if you boot at AST kernel and then reboot into a OpenBMC kernel without power cycling, your i2c buses may just happen to work.

I will correct this in a future patch.

[jk-ozlabs]

Should be sorted with the current code.