0
votes

I have a problem with the i2c/SMBus on a Linux System with an Intel Apollo Lake processor. I am trying to read/write from/to an EEPROM but I face some issues. My EEPROM is located at the address 0x56, and I am able to watch the Bus with my Logic Analyzer.

When I try to read from the device via i2ctools (i2cget) the System behaves as expected. My issue occurs when I try to perform a write command via i2cset for example. i2cset ends with an error (Write failed). Because I am able to watch the Bus electrically I can also say that all lines stay HIGH and the Bus is not touched. I was able to activate the dev_dbg() functions in the i2c driver i2c_i801 and when I perform i2cset I am able to find (dmesg) the debug message:

[  765.095591] [2753] i2c_i801:i801_check_post:433: i801_smbus 0000:00:1f.1: No response

When running my minimal I²C Python code using the smbus2 lib, I get the following error message and the above mentioned debug message:

from smbus2 import SMBus
bus = SMBus(0)
b = bus.read_byte_data(86,10)       #<- This is performed 
b = bus.write_byte_data(86,10,12)   #<- This is not performed
bus.close()

Error: File "usr/local/lib/python3.8/dist-packagers/smbus2-0.4.0-py3.8.egg/smbus/smbus2.py", line 455, in write_byte_data ioctl(self.fd, I2C_SMBUS, msg)

OSERROR: [Errno 6] No such device or adress

A big hint for me is that I am not able to perform a write command in the address space form 0x50 to 0x57. My guess is that some driver locks the address space to prevent write command to that "dangerous" area.

My question is: "Does anyone know this kind of behavior and is there a solution so that I can write to my EEPROM at address 0x56? OR Is there a lock surrounding the i2c adress space from 0x50 to 0x57 and who is my opponent?"

I am kind of a newbie to the whole driver and kernel world so please be kind and it is quite possible that I made a beginner mistake. I would appreciate hints and tips I can look after surrounding my problem.

1
Some libraries are expecting 8-bit address instead of 7-bit. Check if you can deal with 0xa6 (read) and 0xa7 (write). Also read about EEPROM in datasheet. They may have different data width organization. In that case you might need to write/read two bytes per an access.0andriy
The Library behaves as expected when I am writing to some address except the mentioned address space form 0x50 to 0x57. My guess is, that some driver or the OS (Linux Ubuntu) is locking the userspace from writing to this address space. Indeed, the memory addressing of a big EEPROM is handled with high and low byte but that is not my issue. I can check the action taken on the I2C-Bus with my Logic Analyzer and can assure, that there is no action performed, when writing to the forbidden address space (0x50-0x57).mates868

1 Answers

1
votes

It seems that I found the cause of my problem. In this Forum post is described that Intel changed a configuration Bit at the SMBus controller.

OK, I know what's going on.

Starting with the 8-Series/C220 chipsets, Intel introduced a new configuration bit for the SMBus controller in register HOSTC (PCI D31:F3 Address Offset 40h):

Bit 4 SPD Write Disable - R/WO. 0 = SPD write enabled. 1 = SPD write disabled. Writes to SMBus addresses 50h - 57h are disabled.

This badly documented change in the configuration explains the issues.

One Challenge is, that to apply and enable changes to the SPD-write Bit the System needs to be rebooted. Unfortunately while rebooting the BIOS will change the Bit back to the default. The only solution seems to be an adaption in the BIOS.

For me, this issue is resolved. I just wanted to share this information in case someone faces the same issues.