Releasing the on-board EEPROM on i2c-0 / 0x50 from Kernel control?

GoogleGroups
1

I’d like to be able to read/write data from the BBB’s on-board EEPROM programatically using the ioctl(…) interface just like any other i2c eeprom my software might be asked to go deal with.

Of course the kernel claims that device for itself pretty quickly upon boot which means I can’t get to it that way (fails to set address, device in use).

Is there a relatively simple way of getting the Kernel to release that device ?

2

You will need to modify the hardware to remove the write protect before you can do any writes…

Gerald

3

Naturally - that’s part of the test jig. I have a very special paperclip all modeled up in solidworks.

But the first problem is that ioctl (or the i2cdump utility) won’t touch that address even for a read operation because it’s in use by the kernel. That’s the bit I’d like to get around.

4

william@beaglebone:~$ sudo dd count=30 bs=1 if=/sys/bus/i2c/devices/0-0050/0-00500/nvmem
▒U3▒A335BNLT00C03214BBBK0403▒▒30+0 records in
30+0 records out
30 bytes (30 B) copied, 0.0114076 s, 2.6 kB/s

5

When attempting to use an I2C device that is already in use by the kernel. You can’t use I2C_SLAVE, you must use I2C_SLAVE_FORCE.

6

Additionally, you should make absolutely positive that you know what you’re doing. When writing to that eeprom. Otherwise you’ll end up rendering your beaglebone non bootable. Until you hard code which board file to load at boot, or you reflash the eeprom.

7

I2C_SLAVE_FORCE got the job done - thank you very much for the suggestion, William. My additional manufacturing and cal information is now fat and happy on the EEPROM.

Had to leave a much longer delay between writes than I’d expected, though.

8

I2C_SLAVE_FORCE got the job done - thank you very much for the suggestion,

William. My additional manufacturing and cal information is now fat and
happy on the EEPROM.

Had to leave a much longer delay between writes than I'd expected, though.

Yeah, somewhere, probably in the /sys/bus/i2c, but maybe in the kernel
driver I was noticing that i2c speeds seemed to be set lower than even
400kbit/s. The "magic number" that I'm thinking is 180kbit/s, but this is
just something I was noticing while looking for something else. So might be
wrong. Either way, 400kbit/s is not all that fast.