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

111 views
Skip to first unread message

Phil Mills

unread,
Aug 9, 2016, 3:41:07 PM8/9/16
to BeagleBoard
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 ?

Gerald Coley

unread,
Aug 9, 2016, 3:43:43 PM8/9/16
to beagl...@googlegroups.com
You will need to modify the hardware to remove the write protect before you can do any writes..

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fab7a669-a56e-4c30-901f-89552495aa50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Phil Mills

unread,
Aug 9, 2016, 3:50:58 PM8/9/16
to beagl...@googlegroups.com
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. 


On Tue, Aug 9, 2016 at 1:43 PM Gerald Coley <ger...@beagleboard.org> wrote:
You will need to modify the hardware to remove the write protect before you can do any writes..

Gerald

On Tue, Aug 9, 2016 at 2:41 PM, Phil Mills <phil....@gmail.com> wrote:
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 ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fab7a669-a56e-4c30-901f-89552495aa50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/EuSRwT-Zs3U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BdxZac2kZwE%2BmSN8ShMWT0siaGhQfCOw%2BaJuiTjwurY1w%40mail.gmail.com.

William Hermans

unread,
Aug 9, 2016, 4:06:19 PM8/9/16
to beagl...@googlegroups.com
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


On Tue, Aug 9, 2016 at 12:50 PM, Phil Mills <phil....@gmail.com> wrote:
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. 


On Tue, Aug 9, 2016 at 1:43 PM Gerald Coley <ger...@beagleboard.org> wrote:
You will need to modify the hardware to remove the write protect before you can do any writes..

Gerald

On Tue, Aug 9, 2016 at 2:41 PM, Phil Mills <phil....@gmail.com> wrote:
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 ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fab7a669-a56e-4c30-901f-89552495aa50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/EuSRwT-Zs3U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BdxZac2kZwE%2BmSN8ShMWT0siaGhQfCOw%2BaJuiTjwurY1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCPF%2BsVrR98rp22_%3Df%3D7ZMTVp%3DD4vdC6mq65jdqZd-NmygnLQ%40mail.gmail.com.

William Hermans

unread,
Aug 9, 2016, 4:09:14 PM8/9/16
to beagl...@googlegroups.com
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.

William Hermans

unread,
Aug 9, 2016, 4:13:20 PM8/9/16
to beagl...@googlegroups.com
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.

Phil Mills

unread,
Aug 10, 2016, 10:17:35 AM8/10/16
to beagl...@googlegroups.com
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.  

On Tue, Aug 9, 2016 at 2:13 PM William Hermans <yyr...@gmail.com> wrote:
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.
On Tue, Aug 9, 2016 at 1:09 PM, William Hermans <yyr...@gmail.com> wrote:
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.
On Tue, Aug 9, 2016 at 1:06 PM, William Hermans <yyr...@gmail.com> wrote:
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

On Tue, Aug 9, 2016 at 12:50 PM, Phil Mills <phil....@gmail.com> wrote:
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. 


On Tue, Aug 9, 2016 at 1:43 PM Gerald Coley <ger...@beagleboard.org> wrote:
You will need to modify the hardware to remove the write protect before you can do any writes..

Gerald

On Tue, Aug 9, 2016 at 2:41 PM, Phil Mills <phil....@gmail.com> wrote:
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 ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/EuSRwT-Zs3U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/EuSRwT-Zs3U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpxNUmVRowcoFnbo3UHL9JcqjM_RajYbOHLnDuX0fkjew%40mail.gmail.com.

William Hermans

unread,
Aug 11, 2016, 12:18:25 PM8/11/16
to beagl...@googlegroups.com


On Wed, Aug 10, 2016 at 7:17 AM, Phil Mills <phil....@gmail.com> wrote:

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.
Reply all
Reply to author
Forward
0 new messages