BeagleBone, i2c-2 and i2c-3 bus frequency

[Tuwuh S]

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

[Tuwuh S]

Any updates on this? Does anyone also encounter the same issue?

---
Tuwuh S

[Maxim Podbereznyy]

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

[Tuwuh S]

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

[Glen Duncan]

Highly unlikely.

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

[Lars Poulsen]

Well it could be that it would change since devices are able slow down transmission

[Maxim Podbereznyy]

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>:

[Tuwuh S]

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

[Maxim Podbereznyy]

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>:

[Zhivko]

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:

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>:
> 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
>
> -- To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:

> beagleboard+unsubscribe@googlegroups.com

[Zhivko]

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:

[Steve Galle]

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

[Steve Galle]

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:

[Tuwuh S]

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.

[Steve Galle]

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

[Zhivko]

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?

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:

beagleboard+unsubscribe@googlegroups.com

[Zhivko]

Sory, link to picasa web images is as follows:

https://picasaweb.google.com/110230689089207649183/Beaglebone25kHzI2c 

Hope it will help someone.

Dne petek, 27. april 2012 10:08:41 UTC+2 je oseba Zhivko napisala:

[Koen Kooi]

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

[Steve Galle]

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

beagleboard...@googlegroups.com

Frequently asked questions: http://beagleboard.org/faq

<uEnv.txt>

[Zhivko]

I made simple i2c bechmark using:

http://code.google.com/p/uav-helicoptor-ece4007/downloads/detail?name=i2c_bench.c&can=2&q=#makechanges

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:

[Zhivko]

[Zhivko]

[Koen Kooi]

What about a driver in the kernel that takes care of all the reading?

regards,

Koen

[Zhivko]

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:

[Jason Kridner]

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.

> -- To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:

> beagleboard...@googlegroups.com

[jyore]

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. 

[Tuwuh S]

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

[Steve Galle]

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

[Hiremath, Vaibhav]

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

[Steve Galle]

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

[Zhivko]

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:

> beagleboard+unsubscribe@googlegroups.com

[Koen Kooi]

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.

[Klemen Živkovič]

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

[Steve Galle]

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

[Zhivko]

Maybe this could help:

http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git

Thanks,

zhivko

Dne petek, 04. maj 2012 15:47:34 UTC+2 je oseba Steve napisala:

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

On May 4, 2012, at 5:43 AM, Klemen Živkovič wrote:

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

On Fri, May 4, 2012 at 2:21 PM, Koen Kooi <ko...@beagleboard.org> wrote:

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.

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:

beagleboard+unsubscribe@googlegroups.com

Frequently asked questions: http://beagleboard.org/faq

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:

beagleboard+unsubscribe@googlegroups.com

[Pacifico]

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

[Koen Kooi]

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

[Steve Galle]

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

beagleboard...@googlegroups.com

[Pacifico]

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:

git clone git://github.com/beagleboard/kernel.git

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

[Robert Nelson]

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/

[Pacifico]

Thanks, Robert.

On Monday, May 21, 2012 10:45:55 AM UTC-7, RobertCNelson 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 

[Robert Nelson]

>> 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..

[Al Pacifico]

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

On Thu, Aug 16, 2012 at 10:41 PM, Thomas Spellman <tho...@gmail.com> wrote:

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                                                                                                                                                                                      

On Friday, July 27, 2012 6:45:55 PM UTC-7, tcmichals wrote:

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? 

-- 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.

[Andreas]

Any updates on how to get it to 400KHz?

Best,

Andreas

[Klemen Živkovič]

Hi pacifico,

have you checked: https://groups.google.com/d/msg/beagleboard/Q1pDr1lT7Gk/9wTgluPK2yUJ

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

--
 
 

[Kingbäck Andreas]

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.

https://picasaweb.google.com/102176254275622379919/CoolRunnerIICPLDCape#5814317656409845250

https://picasaweb.google.com/102176254275622379919/CoolRunnerIICPLDCape#5814317753292170418

I'm running ubuntu (http://wiki.flighttronics.se/index.php?title=Install_Ubuntu)

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>

--
 
 

[Klemen Živkovič]

1) Have you saw my osciloscope picture?

2) Have you done some calculation from picture - I think I got it to 400 MHz.

[Kingbäck Andreas]

Hello!

No it is only 98.361KHz

Best,

Andreas

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

--
 
 

[Zhivko]

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: