BeagleBone, i2c-2 and i2c-3 bus frequency

Showing 21-71 of 71 messages
BeagleBone, i2c-2 and i2c-3 bus frequency Tuwuh S 2/8/12 4:31 PM
I've been playing around with I2C on my BeagleBone.
I am using Angstrom demo image Angstrom-Cloud9-IDE-eglibc-ipk-v2012.01-
core-beaglebone-2012.01.11.img.gz

First, I put pull-ups to SDA and SCL line of i2c-3 (I2C2 in SRM), and
probe the bus using i2cdetect. It looks normal:
root@beaglebone:~# i2cdetect -r -y 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

From dmesg, I know that the bus frequency is 100kHz:
[    0.884620] omap_i2c omap_i2c.3: bus 3 rev4.0 at 100 kHz

However when I check the SCL line with scope, I found that the bus
frequency is 25kHz instead of 100kHz.

I also try putting pull-ups to i2c-2 (I2C1 in SRM). The bus is enabled
by adding "i2c_bus=2,400" to boot arguments in uEnv.txt. Here I am
aiming for 400kHz bus frequency. The dmesg confirms that the bus has
been successfully configured:
[    0.098696] omap_i2c omap_i2c.2: bus 2 rev4.0 at 400 kHz

When I check the SCL line, the bus frequency is measured to be 100kHz
instead of 400kHz. This is also /4 of the intended frequency like the
case of i2c-3.

Does anyone know how could I repair this? Do I need to set something
else to get the I2C working (something like clock divider, perhaps)?


Regards,

---
Tuwuh S
Re: BeagleBone, i2c-2 and i2c-3 bus frequency Tuwuh S 4/18/12 7:29 PM
Any updates on this? Does anyone also encounter the same issue?

---
Tuwuh S

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency lisarden 4/19/12 2:45 AM
Do you have any specific device the i2c bus could talk to? Why playing
with air? Connect something tangible and play with it.

2012/4/19 Tuwuh S <tuw...@potensi.net>:


> Any updates on this? Does anyone also encounter the same issue?
>
>
> ---
> Tuwuh S
>
> -- To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com
> Frequently asked questions: http://beagleboard.org/faq

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Tuwuh S 4/19/12 5:24 PM
I want to make sure that the configuration is OK before putting any device.
The frequency wouldn't change if I connect some device to the bus, would it?

---
Tuwuh S
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Glen D 4/19/12 5:29 PM

Highly unlikely.

-- To join: http://beagleboard.org/discuss

To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Lars Poulsen 4/21/12 5:38 AM
Well it could be that it would change since devices are able slow down transmission
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency lisarden 4/21/12 7:01 AM
pure I2C does not have the minimum frequency, DC is possible. SMBus
has the minimum of 25 kHz (not sure about this value), but the timeout
between clocks must be less than 35ms

2012/4/21 Lars Poulsen <larsop...@gmail.com>:

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Tuwuh S 4/22/12 5:39 PM
Actually, I'm curious why this inconsistency occurs (between dmesg reported i2c frequency and the actual bus frequency).
The other question is, is it possible to change the i2c bus frequency from userland? Or boot option?

Any pointers are welcomed...

---
Tuwuh S
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency lisarden 4/22/12 10:47 PM
from u-boot you set bootargs for the kernel. There you can use this
argument: i2c_bus=3,100
This means: i2c bus 3, freq=100kHz

2012/4/23 Tuwuh S <tuw...@potensi.net>:

> -- To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com
> Frequently asked questions: http://beagleboard.org/faq

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/26/12 5:49 AM
I have beaglebone ubuntu from (nelson)
I tried to add:

i2c_bus=2,400

to the end of:
/boot/uboot/uEnv.txt

but still in dmesh I have:

[    0.112609] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
[    1.501281]  omap_i2c.3: alias fck already exists
[    1.506439] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz 

I mean what's the purpose having all this drystones on beagle if i2c is on 25kHz ???

Dne ponedeljek, 23. april 2012 07:47:33 UTC+2 je oseba lisarden napisala:
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/26/12 5:52 AM
Have you been able to fix that? I have same problem - it looks like no matter what I put in uEnv.txt evrytime dmesg reports 100kHz...

Replies welcome!

Dne ponedeljek, 23. april 2012 02:39:04 UTC+2 je oseba Tuwuh S napisala:
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Steve 4/26/12 8:33 PM
The uEnv setting doesn't work for me either. I'm hoping to look at this when I have some time, but it sure looks like a bug in the kernel i2c code though. A previous post indicated that if the bus was set to 400mhz it actually ran at 100; so both bus speeds are running at 1/4 the requested rate. Perhaps this indicates a problem with the value being set in the clock prescaler register I2C_PSC? Just a guess though, like I say, I haven't had a chance to look yet. 

Steve

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Steve 4/26/12 10:25 PM
Ok, there is a problem in drivers/i2c/busses/i2c-omap.c. internal_clk is getting incorrectly set to 4000. Based on the TRM the i2c internal clock for the 335x should be 12000. I've fixed this here by creating a new i2c flag OMAP_I2C_FLAG_FORCE_12000_INT_CLK and setting it in arch/arm/mach-omap2/omap_hwmod_33xx_data.c. Then, in omap_hwmod_33xx_data.c I check for the flag and set internal_clk appropriately if it's set. With the new kernel in place I've measured the bus frequency at 95.xxx khz (100 was configured). 

Steve

On Apr 26, 2012, at 5:52 AM, Zhivko wrote:

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Tuwuh S 4/26/12 11:21 PM
I've never been fiddling around with kernel compiling. So far I'm just using the prebuilt demo image. Maybe now's the time for me to start learning. ;)

However I am wondering, why the internal clock must be set to 12000, not 16000 (which is 4 times the original 4000)?

---
Tuwuh S.

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Steve 4/26/12 11:27 PM
I'm not really sure without doing more reading; just blindly trusting the TRM:

21.3.15.3

How to Program I2C

Module Configuration Before Enabling the Module

Program the prescaler to obtain an approximately 12-MHz I2C module clock (I2C_PSC = x; this value is to be calculated and is dependent on the System clock frequency). 


I've got a tutorial for how to create OE patches, once I figure it out I'll submit it, unless someone beats me to it.

Steve


-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq

Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/27/12 1:08 AM
I think I made it.

Change of uEnv.txt did the trick: lines that are important are (see attachment for full uEnv.txt):

i2cspeed=3,400
mmcargs=setenv bootargs console=${console} i2c_bus=${i2cspeed} ${optargs} vram=${vram} omapfb.mode=${defaultdisplay}:${dvimode} omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype} ${device_args}

After reboot ob ubuntu on beagle it was easy to check i2c frequency in dmesg with:

ubuntu@omap:~/uav-helicoptor-ece4007/software/units$ dmesg | grep Kernel
[    0.000000] Kernel command line: console=ttyO0,115200n8 i2c_bus=3,400 vram=12MB omapfb.mode=: omapdss.def_disp= root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=none

and 

ubuntu@omap:~/uav-helicoptor-ece4007/software/units$ dmesg | grep i2c
[    0.000000] Kernel command line: console=ttyO0,115200n8 i2c_bus=3,400 vram=12MB omapfb.mode=: omapdss.def_disp= root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=none
[    0.100921]  omap_i2c.1: alias fck already exists
[    0.104095]  omap_i2c.3: alias fck already exists
[    0.112762] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
[    0.128997] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 400 kHz

I made some screenshots from osciloscope where it can be seen that i2c clock on bus 3 is running on 400kHz.

But still it seems that reading data on i2c as file is quite a lot overhead - bug in i2c driver maybe?

Can yomebody hjelp in which direction to go to improve i2c driver? Should I reinvent it ? ;)

Thanks for all comments.

Zhivko

Dne petek, 27. april 2012 08:27:36 UTC+2 je oseba Steve napisala:
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/27/12 1:14 AM
Sory, link to picasa web images is as follows:
Hope it will help someone.

Dne petek, 27. april 2012 10:08:41 UTC+2 je oseba Zhivko napisala:
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Koen Kooi 4/27/12 4:28 AM

Op 27 apr. 2012, om 10:08 heeft Zhivko het volgende geschreven:

> I think I made it.
>
> Change of uEnv.txt did the trick: lines that are important are (see attachment for full uEnv.txt):
>
> i2cspeed=3,400
> mmcargs=setenv bootargs console=${console} i2c_bus=${i2cspeed} ${optargs} vram=${vram} omapfb.mode=${defaultdisplay}:${dvimode} omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype} ${device_args}
>
>
> After reboot ob ubuntu on beagle it was easy to check i2c frequency in dmesg with:
>
> ubuntu@omap:~/uav-helicoptor-ece4007/software/units$ dmesg | grep Kernel
> [    0.000000] Kernel command line: console=ttyO0,115200n8 i2c_bus=3,400 vram=12MB omapfb.mode=: omapdss.def_disp= root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=none
>
> and
>
> ubuntu@omap:~/uav-helicoptor-ece4007/software/units$ dmesg | grep i2c
> [    0.000000] Kernel command line: console=ttyO0,115200n8 i2c_bus=3,400 vram=12MB omapfb.mode=: omapdss.def_disp= root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=none
> [    0.100921]  omap_i2c.1: alias fck already exists
> [    0.104095]  omap_i2c.3: alias fck already exists
> [    0.112762] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
> [    0.128997] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 400 kHz
>
> I made some screenshots from osciloscope where it can be seen that i2c clock on bus 3 is running on 400kHz.
> https://picasaweb.google.com/lh/reorder?uname=110230689089207649183&aid=5735825684553527041
>
> But still it seems that reading data on i2c as file is quite a lot overhead - bug in i2c driver maybe?

Are you using a in-kernel driver for your device, /dev/i2c-dev or i2c-get or something else?

regards,

Koen
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Steve 4/27/12 8:44 AM
Interesting; my uEnv.txt is completely different, literally the only thing it specifies is: 

optargs=run_hardware_tests quiet

I added the i2c_bus=3,400 argument to optargs and it did in fact set the speed for the driver (not sure how I messed it up when I tried before). It still runs at about 1/4 speed without my patch though, which is strange as it doesn't seem to match your experience. Which kernel are you running? 

Steve

<uEnv.txt>

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/28/12 10:14 AM
I made simple i2c bechmark using:


I am using i2c as channel like this:

if((fd = open("/dev/i2c-3",O_RDWR)) < 1) {
printf("ERROR Opening File\n");
return -1;
}

if(ioctl(fd,I2C_SLAVE,addr)) {
printf("ERROR Opening Device\n");
return -1;
}
and then issuing 1 write and 1 read.

And I am getting:

sudo ./i2c_bench 83 0 10
READ in 0s 733us
READ in 0s 488us
READ in 0s 397us
READ in 0s 397us
READ in 0s 366us
READ in 0s 367us
READ in 0s 366us
READ in 0s 488us
READ in 0s 397us
READ in 0s 366us
RAN 10 READS in 0s 4ms

So aproximately 1 read in 4ms. That's after I enabled 400kH speed on bus.

I think 4ms for read from i2c is too little for our project - can you prupose different way of doing it?

Dne petek, 27. april 2012 13:28:15 UTC+2 je oseba Koen Kooi napisala:
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/28/12 10:14 AM

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/28/12 10:15 AM

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Koen Kooi 4/28/12 11:10 AM

Op 28 apr. 2012, om 19:15 heeft Zhivko het volgende geschreven:
What about a driver in the kernel that takes care of all the reading?

regards,

Koen
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 4/29/12 12:14 AM
Sorry, but can you be more precise? Can you suggest a sample of source code maybe (preferably in C or C++)?

I really haven't been long in linux world.

Thanks, 

Dne sobota, 28. april 2012 20:10:59 UTC+2 je oseba Koen Kooi napisala:
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Jason Kridner 4/30/12 1:43 AM
On Sat, Apr 28, 2012 at 1:14 PM, Zhivko <klemenz...@gmail.com> wrote:
> I made simple i2c bechmark using:
>
> http://code.google.com/p/uav-helicoptor-ece4007/downloads/detail?name=i2c_bench.c&can=2&q=#makechanges

Looking at your loop:
                if(write(fd,buf,1) != 1) {
                        printf("ERROR Could not write to device\n");
                        return -1;
                }
                if(read(fd,buf,1) < 1) {
                        printf("ERROR Could not read from device\n");
                        return -1;
                }

Do you need to perform the write before every read?  There is a chance
that Linux isn't flushing the write very quickly.  There might even be
things like 'elevator' algorithms that try to aggregate writes
together before taking big I/O hits.  It could be that character
drivers don't typically have those, but I'm more familiar with block
driver implementations myself.  Anyway, you could be wasting a ton of
your time in-between those operations without having useful activity
on the bus.

If you do need the write, you might consider using a 'flush'.

Is it possible for you to turn it into a single operation per [1]:

123  ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
124          Do combined read/write transaction without stop in between.
125          Only valid if the adapter has I2C_FUNC_I2C.  The argument is
126          a pointer to a
127        
128          struct i2c_rdwr_ioctl_data {
129              struct i2c_msg *msgs;  /* ptr to array of simple messages */
130              int nmsgs;             /* number of messages to exchange */
131          }
132        
133          The msgs[] themselves contain further pointers into data buffers.
134          The function will write or read data to or from that buffers depending
135          on whether the I2C_M_RD flag is set in a particular message or not.
136          The slave address and whether to use ten bit address mode has to be
137          set in each message, overriding the values set with the above ioctl's.        

[1] http://www.mjmwired.net/kernel/Documentation/i2c/dev-interface#123

Also, would it make sense to make the write non-blocking with
O_NONBLOCK?  My thought is that it might save a context switch, but
I'm not that clear on the topic.  Just trying to throw some thoughts
out there.

>
> I am using i2c as channel like this:
>
> if((fd = open("/dev/i2c-3",O_RDWR)) < 1) {
> printf("ERROR Opening File\n");
> return -1;
> }
>
> if(ioctl(fd,I2C_SLAVE,addr)) {
> printf("ERROR Opening Device\n");
> return -1;
> }
> and then issuing 1 write and 1 read.
>
> And I am getting:
>
> sudo ./i2c_bench 83 0 10
> READ in 0s 733us
> READ in 0s 488us
> READ in 0s 397us
> READ in 0s 397us
> READ in 0s 366us
> READ in 0s 367us
> READ in 0s 366us
> READ in 0s 488us
> READ in 0s 397us
> READ in 0s 366us
> RAN 10 READS in 0s 4ms
>
> So aproximately 1 read in 4ms. That's after I enabled 400kH speed on bus.

k, sounds like you confirmed this with a scope as mentioned below.

>
> I think 4ms for read from i2c is too little for our project - can you
> prupose different way of doing it?

If you can do the I/O in a non-blocking manner, you should be able to
pipeline the operations a bit.

Of course, the recommendation to perform the operations in a kernel
driver could provide obvious benefits.  Simply moving to the best
kernel interface functions that avoid needing to switch back and forth
should give some benefit.
Re: BeagleBone, i2c-2 and i2c-3 bus frequency jyore 5/1/12 5:57 AM
In regards to recent posts:

As far as writing before reads goes...that is part of the spec.  The I2C slave devices maintain a register pointer.  To start reading, you must send a write request with no data to the  register you wish to read.  This moves the address pointer to that address.  A read request can then be sent to that register to read its contents.  The register pointer automatically increases.  While in an application with sensor data, you could send 1 write, and then read the next several bytes with 1 write and 1 read request, there are cases where you only need the same byte every time and cannot get it from a subsequent read (i.e. check an interrupt case).  Also there is no way to find what address the pointer is at, so you must reset it.  It is my experience with the Beaglebone i2c bus that even doing multibyte reads, you are still waiting quite a while to get the data in userland.

Second, non-blocking I/O doesn't really solve this problem (Poster was talking about an IMU).  You are requesting sensor data to use and then the application makes a decision based on that data.  Non-blocking I/O will allow you to do other things while you are waiting for the data to be available, however, if there is nothing you can do without that data, you are not gaining time or performance...in fact it will probably be worse.

Finally, a kernel level application would definitely decrease latency as you would see it soon after the kernel gets it, but this, to me, is defeating the purpose of using a device such as the Beaglebone.  The goal of these hobby type dev boards should be an easy to use application development platform.  It is beyond the scope of a normal hobby type project to have to rewrite a driver in order to use a device as it should be used.  The fact that the i2c clock is not even correct and there is not a simple userland remedy is completely useless as well. 



On Wednesday, February 8, 2012 7:31:22 PM UTC-5, Tuwuh S wrote:
I've been playing around with I2C on my BeagleBone.
I am using Angstrom demo image Angstrom-Cloud9-IDE-eglibc-ipk-v2012.01-
core-beaglebone-2012.01.11.img.gz

First, I put pull-ups to SDA and SCL line of i2c-3 (I2C2 in SRM), and
probe the bus using i2cdetect. It looks normal:
root@beaglebone:~# i2cdetect -r -y 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

From dmesg, I know that the bus frequency is 100kHz:
[    0.884620] omap_i2c omap_i2c.3: bus 3 rev4.0 at 100 kHz

However when I check the SCL line with scope, I found that the bus
frequency is 25kHz instead of 100kHz.

I also try putting pull-ups to i2c-2 (I2C1 in SRM). The bus is enabled
by adding "i2c_bus=2,400" to boot arguments in uEnv.txt. Here I am
aiming for 400kHz bus frequency. The dmesg confirms that the bus has
been successfully configured:
[    0.098696] omap_i2c omap_i2c.2: bus 2 rev4.0 at 400 kHz

When I check the SCL line, the bus frequency is measured to be 100kHz
instead of 400kHz. This is also /4 of the intended frequency like the
case of i2c-3.

Does anyone know how could I repair this? Do I need to set something
else to get the I2C working (something like clock divider, perhaps)?


Regards,

---
Tuwuh S

On Wednesday, February 8, 2012 7:31:22 PM UTC-5, Tuwuh S wrote:
I've been playing around with I2C on my BeagleBone.
I am using Angstrom demo image Angstrom-Cloud9-IDE-eglibc-ipk-v2012.01-
core-beaglebone-2012.01.11.img.gz

First, I put pull-ups to SDA and SCL line of i2c-3 (I2C2 in SRM), and
probe the bus using i2cdetect. It looks normal:
root@beaglebone:~# i2cdetect -r -y 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

From dmesg, I know that the bus frequency is 100kHz:
[    0.884620] omap_i2c omap_i2c.3: bus 3 rev4.0 at 100 kHz

However when I check the SCL line with scope, I found that the bus
frequency is 25kHz instead of 100kHz.

I also try putting pull-ups to i2c-2 (I2C1 in SRM). The bus is enabled
by adding "i2c_bus=2,400" to boot arguments in uEnv.txt. Here I am
aiming for 400kHz bus frequency. The dmesg confirms that the bus has
been successfully configured:
[    0.098696] omap_i2c omap_i2c.2: bus 2 rev4.0 at 400 kHz

When I check the SCL line, the bus frequency is measured to be 100kHz
instead of 400kHz. This is also /4 of the intended frequency like the
case of i2c-3.

Does anyone know how could I repair this? Do I need to set something
else to get the I2C working (something like clock divider, perhaps)?


Regards,

---
Tuwuh S
Re: BeagleBone, i2c-2 and i2c-3 bus frequency Tuwuh S 5/1/12 5:24 PM
Just my ¢2.
Regarding the incorrect I2C clock, still, I think this is a kind of bug in the Beaglebone kernel I2C driver, which should be fixed.
This does not seem to be a big problem, yet it may be important for others who use Beaglebone as a development platform.

---
Tuwuh S
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Steve 5/1/12 6:10 PM
It's definitely a bug. I have generated a patch set that fixes it, but I don't know how to submit it (although at the 12kHz clock rate the TRM specifies the rates are still a little slow, haven't quite nailed it), and I don't have enough time to go through the process of figuring it out. Is the process clearly spelled out on any one wiki page? If not, I'm happy to send the patch to anyone who knows the process and has time to submit it for inclusion in the distro.

Steve

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq

RE: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Hiremath, Vaibhav 5/1/12 11:20 PM
On Wed, May 02, 2012 at 06:40:33, Steve Galle wrote:
> It's definitely a bug. I have generated a patch set that fixes it, but I
> don't know how to submit it (although at the 12kHz clock rate the TRM
> specifies the rates are still a little slow, haven't quite nailed it),
> and I don't have enough time to go through the process of figuring it
> out. Is the process clearly spelled out on any one wiki page? If not,
> I'm happy to send the patch to anyone who knows the process and has time
> to submit it for inclusion in the distro.
>

I am not the one for distros, but definitely I am the one for all Beaglebone
baseport issues.

This seems to be major bug in the baseport, I already have this in my TODO
list, especially hwmod related changes which you have done to fix this. Also,
Clock tree should make sure that you get desired functional clock, if that's
not happening, I would also consider it as a bug.

Let me finish my current activity, then I will work on this.

Thanks,
Vaibhav


Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Steve 5/1/12 11:35 PM
I think the actual clock is OK, but there is a prescaler register set by the driver, and that value is being incorrectly set. There are multiple ways to fix this, but for reference here is my patch (against 3.2.14:

Index: git/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
===================================================================
--- git.orig/arch/arm/mach-omap2/omap_hwmod_33xx_data.c        2012-04-26 23:38:21.830141828 -0700
+++ git/arch/arm/mach-omap2/omap_hwmod_33xx_data.c        2012-04-26 23:41:08.337546725 -0700
@@ -1243,7 +1243,8 @@
 
 static struct omap_i2c_dev_attr i2c_dev_attr = {
         .flags                = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
-                                        OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
+        OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+        OMAP_I2C_FLAG_FORCE_12000_INT_CLK,
 };
 
 static struct omap_hwmod_class i2c_class = {
Index: git/drivers/i2c/busses/i2c-omap.c
===================================================================
--- git.orig/drivers/i2c/busses/i2c-omap.c        2012-04-26 23:38:44.813510057 -0700
+++ git/drivers/i2c/busses/i2c-omap.c        2012-04-26 23:40:14.671019065 -0700
@@ -408,6 +408,8 @@
                 if (dev->speed > 400 ||
                                pdata->flags & OMAP_I2C_FLAG_FORCE_19200_INT_CLK)
                         internal_clk = 19200;
+                else if (pdata->flags & OMAP_I2C_FLAG_FORCE_12000_INT_CLK)
+                   internal_clk = 12000;
                 else if (dev->speed > 100)
                         internal_clk = 9600;
                 else
Index: git/include/linux/i2c-omap.h
===================================================================
--- git.orig/include/linux/i2c-omap.h        2012-04-26 23:39:23.052443403 -0700
+++ git/include/linux/i2c-omap.h        2012-04-26 23:39:47.459764332 -0700
@@ -24,6 +24,8 @@
 #define OMAP_I2C_FLAG_APPLY_ERRATA_I207        BIT(4)
 #define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK        BIT(5)
 #define OMAP_I2C_FLAG_FORCE_19200_INT_CLK        BIT(6)
+#define OMAP_I2C_FLAG_FORCE_12000_INT_CLK        BIT(9)
+
 /* how the CPU address bus must be translated for I2C unit access */
 #define OMAP_I2C_FLAG_BUS_SHIFT_NONE 0
 #define OMAP_I2C_FLAG_BUS_SHIFT_1                BIT(7)


As I said before the clock is still slightly slow, so there may be more tweaks required.

Steve
Re: [beagleboard] Re: BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 5/4/12 5:12 AM
Could we expect this to be patch that we could get it from "opkg update" ?
Trying to use i2c and the it seems reading bytes from i2c device seems to be unstable. Could somebody push this patch ?

Thanks,
Zhivko

Dne sreda, 02. maj 2012 08:35:45 UTC+2 je oseba Steve napisala:
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Koen Kooi 5/4/12 5:21 AM

Op 4 mei 2012, om 14:12 heeft Zhivko het volgende geschreven:

> Could we expect this to be patch that we could get it from "opkg update" ?
> Trying to use i2c and the it seems reading bytes from i2c device seems to be unstable. Could somebody push this patch ?

No, it needs to be in the git-format-patch format with a signed-off-by line before I can take it.
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Klemen Živkovič 5/4/12 5:43 AM
Steve and Koen,

can you two work out his specific format for patch issue - to allow also others to get this update?

Thanks to both of you,
Klemen


-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Steve 5/4/12 6:47 AM
I have said before, if someone can point me at concise instructions for generating an appropriate patch then I'm happy to do it. I put the time into working out at least some of what was wrong, but I don't have the time to noodle around right now figuring out how to submit this. I suspect if I knew the process it's probably only a few minutes of work; is there a tutorial anywhere that walks through the steps? 

Thanks, 
Steve
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 5/10/12 10:23 AM
Maybe this could help:


Thanks,
zhivko

Dne petek, 04. maj 2012 15:47:34 UTC+2 je oseba Steve napisala:
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Pacifico 5/15/12 9:55 PM
I am new to Beagle (mine is on the way), but fairly experienced with Git. I thought I would take this on because the first thing I need out of my BeagleBone is i2c.

I could not locate the first of the three files Steve modified (arch/arm/mach-omap2/omap_hwmod_33xx_data.c) in the tree I cloned with git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. I did find a similarly named arch/arm/mach-omap2/omap_hwmod_3xxx_data.c but the diff does not look like it came from that file.

I am willing to try to address this, but I'd need either Steve's original file for comparison purposes or to get pointed to the correct git repo.
-Al
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Koen Kooi 5/16/12 7:47 AM

Op 16 mei 2012, om 06:55 heeft Pacifico het volgende geschreven:

> I am new to Beagle (mine is on the way), but fairly experienced with Git. I thought I would take this on because the first thing I need out of my BeagleBone is i2c.
>
> I could not locate the first of the three files Steve modified (arch/arm/mach-omap2/omap_hwmod_33xx_data.c) in the tree I cloned with git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. I did find a similarly named arch/arm/mach-omap2/omap_hwmod_3xxx_data.c but the diff does not look like it came from that file.
>
> I am willing to try to address this, but I'd need either Steve's original file for comparison purposes or to get pointed to the correct git repo.

https://github.com/beagleboard/kernel
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Steve 5/16/12 9:14 PM
Al, hi. Thanks for taking this on; for the next few weeks I'm pretty much consumed finishing work, handing off projects, and preparing to move. I saw that Koen replied with the path to the proper kernel. Let me know if you have any other questions about the changes. 

Steve
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Pacifico 5/21/12 10:37 AM
Koen-
I agree with Steve that some concise instructions for going about this are needed. I am happy to contribute them to the wiki of your choice once this is done.

Forgive me if these questions seem lame, but let me show what I did and then ask:

I cloned the kernel repository and checked out the kernel tree in the following way:

pushd kernel/
git checkout origin/beaglebone-3.2 -b beaglebone-3.2
./patch.sh

Some time later, I have a kernelish directory structure, shown by:
ls -1
which outputs: 
export
kernel
patches
patch_script.sh
patch.sh
README.md
src-uri.txt

 I created a branch and modified the files according to Steve's diff(s) with a text editor.

git branch i2c-prescaler-fix
git checkout i2c-prescaler-fix
scite kernel/arch/arm/mach-omap2/omap_hwmod_33xx_data.c kernel/drivers/i2c/busses/i2c-omap.c kernel/include/linux/i2c-omap.h &

However, it seemed that the files Steve changed were never added to the git tree of the repository cloned from git://github.com/beagleboard/kernel.git, the problem being that they are part of the git tree in the kernel subdirectory that was cloned by the patch.sh script. This is demonstrated by:

[alberto@caboto kernel]$ git status
# On branch i2c-prescaler-fix
nothing to commit (working directory clean)
[alberto@caboto kernel]$ pushd kernel
~/Development/oe/kernel/kernel ~/Development/oe/kernel ~/Development/oe ~/Development ~
[alberto@caboto kernel]$ git branch
  master
  tmp-patching-branch
* tmp-patching-branch-sha
[alberto@caboto kernel]$ git status
# On branch tmp-patching-branch-sha
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   arch/arm/mach-omap2/omap_hwmod_33xx_data.c
# modified:   drivers/i2c/busses/i2c-omap.c
# modified:   include/linux/i2c-omap.h
#
no changes added to commit (use "git add" and/or "git commit -a")
[alberto@caboto kernel]$ 

So, I used git stash, created a new branch in this repository, applied the stashed changes. I will submit the patches to you in a git-format-patch format from a users.sourceforge.net email address.

My questions are:
1. Have I done this correctly? What should I do differently?
2. Would you want instructions of how to go about this placed online and if so, where?

As stated before, I am new to the BeagleBone and apologies if this seems kind of basic.
-Al
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency RobertCNelson 5/21/12 10:45 AM
The git kernel directory is just the source of a pure pristine
upstream tree, to help generate the patchset found under "export"
which both Angstrom and my ubuntu/debian scripts use directly.....
For the kernel dir/git we aren't planning to have users push that
directly, as it's more throw away, but i believe koen was planning to
push a tree based off it somewhere on github just to make things
eaiser..

When used as a development tree i usually run "./patch.sh" to generate
a fresh kernel dir, then apply/tweak my patch to that directory, then
run "git add/git commit -a -m" and with the output of "git
format-patch -1", copy that new "git am'ble" patch to the patches
directory into the appropriate subfolder..  Modifing patch.sh
directory listing if it's something unrelated and thus a new dir..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Pacifico 5/21/12 11:12 AM
Thanks, Robert.

On Monday, May 21, 2012 10:45:55 AM UTC-7, RobertCNelson wrote:
On Mon, May 21, 2012 at 12:37 PM, Pacifico wrote:

Understood.
 

When used as a development tree i usually run "./patch.sh" to generate
a fresh kernel dir, then apply/tweak my patch to that directory, then
run "git add/git commit -a -m" and with the output of "git

"git add" did not function for me as expected from within the kernel directory, and I found that pretty confusing. That was what I was referring to in the sixth paragraph.
 
format-patch -1", copy that new "git am'ble" patch to the patches
directory into the appropriate subfolder..  Modifing patch.sh

I assume Koen copies the patch after reviewing it, then?
 
directory listing if it's something unrelated and thus a new dir..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

I think having clear instructions about how to go about this is pretty important to speeding refinement of the BeagleBone software, since it will decrease frustration on the part of contributors. Hacking this sort of stuff is far removed from what I am trying to accomplish with my BeagleBone (providing a web interface for control of a device), and simplicity is what I am looking for. I came to the BeagleBone because Arduino wasn't meeting my needs and was a pain to debug compared to userspace code on your average Linux box.
-Al 
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency RobertCNelson 5/21/12 12:32 PM
>> When used as a development tree i usually run "./patch.sh" to generate
>> a fresh kernel dir, then apply/tweak my patch to that directory, then
>> run "git add/git commit -a -m" and with the output of "git
>
>
> "git add" did not function for me as expected from within the kernel
> directory, and I found that pretty confusing. That was what I was referring
> to in the sixth paragraph.

"git add" adds files not previous recognized by the git index, to the
git index... So if you just modify something already in the index it's
not going to do too much..

If your working with capes (creating a new, etc..), your probally
going to be modifying the board file used by the BeagleBone.. In this
case (arch/arm/mach-omap2/board-am335xevm.c)

>> format-patch -1", copy that new "git am'ble" patch to the patches
>> directory into the appropriate subfolder..  Modifing patch.sh
>
>
> I assume Koen copies the patch after reviewing it, then?

Correct...  It's reviewed in the sense that it fixes something, or
makes something work..  If something breaks, then both Angstrom's
meta-ti and my builddeb scripts will fail...

> I think having clear instructions about how to go about this is pretty
> important to speeding refinement of the BeagleBone software, since it will
> decrease frustration on the part of contributors. Hacking this sort of stuff
> is far removed from what I am trying to accomplish with my BeagleBone
> (providing a web interface for control of a device), and simplicity is what
> I am looking for. I came to the BeagleBone because Arduino wasn't meeting my
> needs and was a pain to debug compared to userspace code on your average
> Linux box.
> -Al

This script is still just the first pass, to help decrease frustration
for contributors, but unfortunately it does require some knowledge
about using git in its current form..  It's main purpose is still to
quickly share the current Angstrom/Ubuntu kernel source tree currently
used by the BeagleBone (and other Beagle devices).  Such that
contributors can easily generate the same kernel source tree and more
easily submit patches to beagl...@googlegroups.com or via
github.com/beagleboard without having to learn bitbake/builddeb
scripts...

BTW: see Bas's BEBOPR cape patchset for a good example of this working..

https://github.com/beagleboard/kernel/commit/6fa43bcfa4e948db5a37c8b298cb7a3e7894fd97

and just like that his BEBOPR cape is now on the fast track to be
supported by Angstrom/Ubuntu/Debian..
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency tcmichals 7/27/12 6:45 PM
I'm using 3.2.23 kernel, ie the standard sdcard image.  I'm trying to se the i2c speed to 400khz, dmsg 
[    0.099945]  omap_i2c.1: alias fck already exists                                                                                                                                                
[    0.110961] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz                                                                                                                                       
[    0.234252]  omap_i2c.3: alias fck already exists                                                                                                                                                
[    0.234497] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz                                                                                                                                       
[    0.525878] i2c /dev entries driver                                                                                                                                                              
root@beaglebone:~# uname -a             
root@beaglebone:/boot# more uEnv.txt                                                                                                                                                                
optargs=run_hardware_tests                                                                                                                                                                          
i2c_bus=2400                                                                                                                                                                                        
root@beaglebone:/boot# 

I tried changing i2c_bus 4200, etc, but nothing changes.  Any suggestions? 

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Thomas Spellman 8/16/12 10:41 PM
I think it's supposed to be like so:                                          
optargs=run_hardware_tests i2c_bus=2,400

However, it appears that nothing I'm putting in uEnv.txt is getting read on boot using the latest Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.06.18.img.  Also, my info.txt is not getting updated with any system info.  Perhaps these two issues are related?

I can however stop the boot process at the uBoot prompt and edit the env variables there, but saveenv isn't working.

What pins is the /dev/i2c-2 bus exposed at, if any?  My current impression is that /dev/i2c-1 (I2C1 in the SRM) is at pins 17&18, and /dev/i2c-3 (SRM I2C2) is at pins 19&20.  Is this correct?

T                                                                                                                                                                                      
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Al Pacifico 8/17/12 6:19 AM
Thomas-
I am visting my in-laws with my wife right now, and left my Linux laptop at home, so I don't have my diagrams and BeagleBone documentation available. The pins you list sound right to my memory. I used /dev/i2c-3 to talk to a microcontroller in the project I worked on.
-Al

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq



--
Please forgive typo's, equally likely to have been typed on cell phone and to have been typed one-handed.


Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Andreas 11/23/12 1:05 PM
Any updates on how to get it to 400KHz?

Best,
Andreas

Den fredagen den 17:e augusti 2012 kl. 15:19:55 UTC+2 skrev Al Pacifico:
Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Klemen Živkovič 11/24/12 12:00 AM
Hi pacifico,


I pasted uEnv there and made some screenshots of i2c communication with oscilloscope (https://picasaweb.google.com/110230689089207649183/Beaglebone25kHzI2c#5735829998983027698)
Please calculate speed of i2c from time slot of i2c communication seen on osciloscope.

Best regards,
Zhivko



--
 
 

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Andreas 11/24/12 2:15 AM
Hi!

Thanx for your reply.
I2C works on the 100KHz but I need it to be 400KHz.

I have  checked: https://groups.google.com/d/msg/beagleboard/Q1pDr1lT7Gk/9wTgluPK2yUJ, but then it will not mount the root=/dev/mmcblk0p2.



See the boot below:

--------------------------------------------------------------------------------------------------------------------------------------------------------------- 

[    3.119323] omap_rtc omap_rtc: setting system clock to 2012-11-23 21:41:05 UTC (1353706865)
[    3.129241] Freeing init memory: 248K
Loading, please wait...
[    3.273864] udevd[65]: starting version 175
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
[    3.463500]  gadget: high-speed config #1: CDC Ethernet (ECM)
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mmcblk0p2 does not exist.  Dropping to a shell!

7B▒%չ▒Ձ▒Ҋr▒▒▒iS▒S▒▒▒▒WW▒%H▒]▒lt-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /proc/cmdline
console=ttyO0,115200n8 i2c_bus=3,400 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc
-----------------------------------------------------------------------------------------------------------------------------------------------




2012/11/24 Klemen Živkovič <klemen....@gmail.com>
--
 
 

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 11/24/12 4:53 AM
1) Have you saw my osciloscope picture?
2) Have you done some calculation from picture - I think I got it to 400 MHz.


On Sat, Nov 24, 2012 at 11:14 AM, Kingbäck Andreas <andk...@gmail.com> wrote:
ks on the 100KHz but I need it to be 400KH

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Andreas 11/24/12 8:52 AM
Hello!

No it is only 98.361KHz

Best,
Andreas

2012/11/24 Klemen Živkovič <klemen....@gmail.com>
--
 
 

Re: [beagleboard] BeagleBone, i2c-2 and i2c-3 bus frequency Zhivko 11/29/12 8:05 AM
Hi Andreas,

please check picture I attached to this post and please comment if my math is wrong.

Thanks,
KLemen

Dne sobota, 24. november 2012 17:52:54 UTC+1 je oseba Andreas napisala:
More topics »