Accessing cape eeprom from application code

In my BBB application, I would like to access the cape eeprom to verify that the correct cape is connected. I thought I could just perform an i2c read at the beginning of my application code and verify the eeprom contents, but my application is giving the ioctl busy response when I try to read the eeprom. Is the kernel occupying these addresses? If so, is there a way I can disable that?

I do see the following when I run dmesg:

[    1.279856] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.282174] at24 2-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.282529] at24 2-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.282855] at24 2-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.283167] at24 2-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.283253] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 400 kHz

These are the reserved cape eeprom addresses, and I’m guessing that the kernel is occupying these addresses, can I force the kernel to release them, or not get them at all?

You can get to them through the /sys/bus/i2c/devices/2-005[4567]/eeprom interface.

Also, I’ve found this repository handy for decoding/encoding cape eeprom images:

In the code I’m doing, I check for accessibility of the abstraction and then feed the path to his function(s)

Thank you! Lol, I had a face palm moment there. I was so convinced the only way to access i2c eeprom was the same way that other i2c devices have to be accessed (using i2c-dev). I didn’t even think that there would be a file mapping to the eeprom directly, thank you again!

1 Like