Help setting up I2C2 on Angstrom

  1. I followed the instructions at http://elinux.org/BeagleBoardAndOpenEmbeddedGit to build an oe angstrom image.

uname -a
Linux beagleboard 2.6.29-omap1 #1 Thu Apr 16 12:40:41 PDT 2009 armv7l GNU/Linux

The issue is that I am trying to setup I2C and cannot find CONFIG_I2C2_OMAP_BEAGLE in the deconfig file. Here is the I2C section from deconfig:

Hi saladino,

Wed, 29 Apr 2009, saladino write:

Linux beagleboard 2.6.29-omap1 #1 Thu Apr 16 12:40:41 PDT 2009 armv7l GNU/Linux

The issue is that I am trying to setup I2C and cannot find CONFIG_I2C2_OMAP_BEAGLE in the deconfig file.

CONFIG_I2C2_OMAP_BEAGLE has been removed from kernel config. For 100 kHz I2C2 add the line starting with + to file arch/arm/mach-omap2/board-omap3beagle.c:

         omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
                         ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0);
         /* Bus 3 is attached to the DVI port where devices like the pico DLP
          * projector don't work reliably with 400kHz */
         omap_register_i2c_bus(3, 100, NULL, 0);

Then you will need to configure pin muxing to get I2C functionality out of those pins at the expansion board. The following entries at U-Boots file
board/omap3/beagle/beagle.h need to be done:

  MUX_VAL(CP(I2C2_SCL), (IEN | PTU | EN | M0)) /*I2C2_SCL*/\
  MUX_VAL(CP(I2C2_SDA), (IEN | PTU | EN | M0)) /*I2C2_SDA*/\

Muxing can also be configured in kernel. For that see:
  http://www.hy-research.com/omap3_pinmux.html

I found the kernel source in tmp/work/beagleboard-angstrom-linux-
gnueabi/linux-omap-2.6.29-
r31+gitr58cf2f1425abfd3a449f9fe985e48be2d2555022/git. Is that the
right place?
I've made the changes to arch/arm/mach-omap2/board-omap3beagle.c.

Now how do I rebuild the kernel?

I tried bitbake -b openembedded/recipes/linux/linux-omap_2.6.29.bb but
that did not build anything.
Also, my defconfig shows "# CONFIG_OMAP_MUX is not set". I don't need
to change this right? I am assuming this is needed when using the
kernel for muxing. I am using u-boot for muxing.

Thanks,
Saladino.

If your kernel is compiled before it will not recomplie unless PR is bumped.
You can remove the earlier kernel by adding -cclean to the bitbake command.
As we are currently on 2.6.29 as "standard" kernel you could also do
the following:

bitbake -cclean virtual/kernel; bitbake virtual/kernel

Have fun, Frans

bitbake -cclean virtual/kernel removed the directory with my source
changes and so the build with bitbake virtual/kernel did not build my
custom kernel. What is PR? Is that something I need to change?

Thanks.

Fri, 1 May 2009, saladino wrote:

Now how do I rebuild the kernel?
I tried bitbake -b openembedded/recipes/linux/linux-omap_2.6.29.bb but
that did not build anything.

bitbake -cclean virtual/kernel removed the directory with my source
changes and so the build with bitbake virtual/kernel did not build my
custom kernel. What is PR? Is that something I need to change?

I don't know much about OE and I have always recompiled my kernel without bitbake, so I haven't tried these but I have been saving these links as I really should try them:
  http://groups.google.com/group/beagleboard/browse_thread/thread/f9edc50ba03c94a6/e71e0f6b82017e4c
  http://groups.google.com/group/beagleboard/browse_thread/thread/b8d0e0a10d4d5a11/51bd45358eb9d7d7

bitbake -cclean virtual/kernel removed the directory with my source
changes and so the build with bitbake virtual/kernel did not build my
custom kernel. What is PR? Is that something I need to change?

If you want to make the changes without further use of bitbake, you can go to the kernel directory produced, in your case: tmp/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.29-r31+gitr58cf2f1425abfd3a449f9fe985e48be2d2555022/git

make your kernel mods there and then do a make command to rebuild it, probably something like:
make ARCH=arm CROSS_COMPILE=/opt/oe/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-
uImage
You'll need to change the "CROSS_COMPILE" path to whatever your real openembedded path is.

When the make command executes, it will tell you where the resulting uImage file ends up, probably the "arch/arm/boot" subdir.

There are cleaner ways to get this to work with the use of bitbake, and doing things this way runs the risk of losing your kernel mods (as you discovered), but it should work as a test of kernel rebuilding.

Brett

Thanks. It worked...