BBB, BB-View and I2C port usage

Since we don't have schematics, it's difficult to be 100% sure, however there appears to be nothing on the board that uses P9 17/18.  Those are connected to U26 on the underside of the board, but that's not installed. They also connect to pins 42 & 43 on the LCD connector, however on the 4.3" lcd board there's nothing connected to them.

As for P9.20, it's connected via R52 to Q17, so as long as this doesn't load I2C2_SDA significantly then it should be possible to use. If not, then at the risk of your warranty, that can be fixed with a soldering iron easily enough.

Either way, you'll need to make appropriate devicetree modifications in order to use it as i2c.

Even if we were to assume that i2c1 really is in use, then you can still connect something to it as long as the address of the i2c device you're connecting does not conflict with whatever address the BB-View might be using.

Whether the 7" version is the same I don't know, I have a 4.3" one myself.

As much as I like BBB and it's supported capes I must say it is extremely frustrating trying to get stuff to work - one of the downsides of configurability I guess. Too many options, too little documentation.

I am not sure you can use I2C1 if it is being assigned by LCD Cape - I am not sure how to reconfigure cape, especially as we don't have access to dts file.

Thanks for responding.

~C

Perhaps you misunderstand how the pieces come together.  The cape 'assigning' i2c1 only causes the two pins to be configured as i2c. It may also configure a driver at one or more i2c addresses on that bus (there are up to 128 devices on an single i2c bus).

Any I2C addresses that the cape doesn't configure are free for you to use.

The devicetree side is somewhat complex in it's own right, but made much more complex by the addition of the overlay system used by the BBB.

Normally, the dts files are available. Often in /lib/firmware along with the compiled dtb files, but that depends on the distro somewhat. However, if they're not available you can use the 'dtc' command (or Device Tree Compiler) to decompile a dtb back into a dts.

Doing this isn't ideal as the resulting file has a lot of numeric data where you'd have symbolic names in the original dts, but it is possible to decompile then change something and recompile.

The BB-View overlay source files are available in one of the BB-View downloads, I don't remember exactly which one right now, but they are there.

Thanks,

I do understand i2c and it's addressing but may be jumping to conclusions on how various capes use the devices - for example, the BB-View cape uses some analog inputs for touchscreen and due to this I lose access to the remaining unused analogs - I assumed because I can't get I2C to work that I am seeing the same thing.

I think the analog inputs might be a special case there, the hardware behind them is really a touch screen controller, not a simple ADC.

The docs say you get the choice of:

8 general-purpose ADC channels

4-wire TSC with 4 general-purpose ADC channels

5-wire TSC with 3 general-purpose ADC channels

8-wire TSC

I didn't look in detail how the drivers work, but it may simply be a case of having to chose either TSC or ADC driver and both can't access the same peripheral simultaneously.  Or, it may just need some special devicetree magic.

Looking at Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt (3.13 kernel source) it looks to be possible to setup a binding that allows both TSC and to use the remaining ADC channels. Not sure if the same would be possible on 3.8.x. The problem is likely to be more related to how any overlay files have been setup. If the BB-View overlay claims all 8 ADC pins, only uses four, and doesn't provide an adc node for the rest then you may not be able to use a second overlay to get the ADC enabled as the pins are claimed by the BB-View but left unused.  You may be able to fix that with some creative editing of the relevant dts files.

On the I2C side, I've certainly been able to use multiple devices on one bus even though the i2c bus itself is only configured in one place. So I'm willing to try to help you get it going if you want..

Good input on the ADC site and this is something we may look into in the near future.

Good news on the I2C side, this makes me more comfortable. I've dug out the oscilloscope and will do some tests today but I think I may be doing something silly and most probably will need some help (or nudging in right direction. Let me know to touch base with you.

~C

you might find something useful here

http://www.element14.com/community/thread/33769/l/how-to-test-the-i2c

While that was aimed at the RIoTboard not the BBB, it shows what I did just to prove some activity on the i2c pins with use of i2cdetect and i2cdump. There's nothing all that different for the BBB, all the linux tools are the same. Scope is pretty much required to check what you think should be happening really is.. I spent far too long recently with i2c on a cubieboard2 only to find I had connected up SDA and SCL backwards

I did some more experiments with scope hooked up to pins. To me it looks like installing BB-View somehow affects I2C operation.

In summary, I started with a clean slate after reflashing BBB with latest Angstrom image. Without doing anything I could view and access two i2c ports, to access all three I needed to add BB-I2C1 to cape manager slots. i2cdetect worked and I could access i2c pins on P9_17/18 and P9_19/20 - I stick to pin numbers as the confusion around names/device/pin assignment is crazy confusing. Both Angstrom and Debian work as expected.

Copying latest BB-View install files and installing as per section 6 in user manual results in i2cdetect accessing different pins (different to native install) and am now only able to access 2 i2c devices and not all three. (Note, device on bus 0 is the internal i2c and is not brought out to header.

Somehow, somewhere BB-View install is seriously effecting i2c usage.

I really don't understand how in native install 'i2cdetect -r 1' accesses pins P9_19/20 and in BB-View install it accesses P9_17/18. I may well be misunderstanding something here but my understanding is that i2c access on pins P9_19/20 is shared across all capes and that change in device bus naming/assignment can not be a good thing.

It appears to me that something is not right with BB-View install.

Willing to help where I can

~C

Attachments:

notes.pdf

the numbering for /dev/i2c-* is done dynamically, in the order they're registered, so if for example you build a devicetree with only P9.19/20 defined then that becomes /dev/i2c-0

define P9.17/18 after 19/20 in device tree and 17/18 gets to be /dev/i2c-1, swap the order in devicetree and they change in /dev as well.

this obviously gets confusing when you look at the schematics and see i2c1, i2c2, i2c3 but you can get results like

i2c3 = /dev/i2c-0

i2c2 = /dev/i2c-1

i2c1 = /dev/i2c-2

capemgr circumvents this problem as it'll have a more physical view by using a reference inside devicetree to a section like

i2c0: i2c@44e0b000 {

compatible = "ti,omap4-i2c";

#address-cells = <1>;

#size-cells = <0>;

ti,hwmods = "i2c1";

reg = <0x44e0b000 0x1000>;

interrupts = <70>;

status = "enabled";

};

by using a label like &i2c0 it gets a reference to the i2c bus at physical address 0x44e0b000 at which point it really doesn't care what /dev/i2c-* entry that bus gets.

The /dev/i2c-* entries are actually provided by another driver called i2c-dev purely for userspace access. capemgr will function quite happily when i2c-dev isn't loaded and you have no /dev/i2c-* entries at all. It can do that as it has access to the i2c bus inside the kernel and never actually uses the /dev entries.

Now this can definitely be confusing from a users perspective, but there isn't necessarily anything wrong. Getting yourself to a point where you understand what's happening is always the tricky part, especially when everything just looks wrong.

Behind all of this you also have to consider the pinmux setup, for example the i2c1 pins that you see on P9.17/18  can be reconfigured to instead be presented on P9.24 & P9.26 which might allow you to use P9.17 as SPI0_CS0 and P9.18 as SPI0_DI.  Multiple levels of abstraction means there's multiple points of confusion, a steeper learning curve, and more work involved in trying to decipher what's actually going on.

Anyway, here's a shortcut to work out which /dev/i2c-* entry maps to which physical i2c interface.. On the BBB do the following

root@bblk01:~# ls /sys/class/i2c-dev/ -l

total 0

lrwxrwxrwx 1 root root 0 May 25 17:39 i2c-0 -> ../../devices/ocp.3/44e0b000.i2c/i2c-0/i2c-dev/i2c-0/

lrwxrwxrwx 1 root root 0 May 25 17:39 i2c-1 -> ../../devices/ocp.3/4802a000.i2c/i2c-1/i2c-dev/i2c-1/

lrwxrwxrwx 1 root root 0 May 25 17:39 i2c-2 -> ../../devices/ocp.3/4819c000.i2c/i2c-2/i2c-dev/i2c-2/

the symlinks for the i2c-dev entries point to a path that includes the address used to access the peripheral. You're not quite done there though, you also need to know the pinmux settings to know which physical pins the peripheral has been mapped onto.  You can either use the devicetree source to determine that, or if you have debugfs enabled then you can find a lot of details under /sys/kernel/debug/pinctrl/44e10800.pinmux/*

As you're probably noticing, most of the references you're seeing are to physical addresses like 44e0b000, so you end up needing to have a copy of the TI AM335x Technical Reference Manual open in another window so that you can work out what the numbers mean.

Unfortunately, another problem is that as you switch between Angstrom, Debian and 3.8.x or 3.13/14 kernel versions then some of the details change... it may be as simple as the paths linked to in /sys/class/i2c-dev/ have ocp.5 instead of ocp.3, or the devicetree could have changed drastically and present you with a very different viewpoint.

Some of these reasons combine to mean that it's not necessarily simple, or even a good idea, to try to compare things between different versions of angstrom, never mind between angstrom and debian.  The one thing that will stay constant is those 44e0b000 type addresses as they're defined by the hardware.

In a lot of this stuff, we may be able to point you in the right direction, or try to explain some things. Getting your head around it to the point where you're comfortable with how it all fits together is something only you can do.  We'll help as much as we can,...

I get all the potential confusion and mapping of devices, my explanation may be a bit terse but you can see from my findings that after installing BB-View image (which is scary in itself to even have to do this) that I lose access to an I2C port. I also agree on dangers of comparing debian/angstrom etc, although they tie up perfectly taking everything into account.

One of the reasons I hooked an oscilloscope up and refer to actual pin access is to have a universal language and bypass confusion of what i2c-x means - at the end of the day if I don't mess with device tree I should see no change in devices. The device that is missing is managed at board level so not being able to access it (control of pins P9_19/20) is really confusing.

What you don't address is where my missing i2c device to control pins P9_19/20 is and whether there is any explanation for this. Loading BB-View should not make this I2C device unavailable, especially considering its board level function. Now maybe I am kidding myself on what I understand and don't understand but I don't think so, but am open to learning and helping.

In my case, after installing BB-View and loading BB-I2C1, ls /sys/class/i2c-dev/ -l only shows two I2C devices, not three as you show. Note that prior to installing BB-View I see all three as you show,  this is the main issue - I lose I2C which drives pins P9_19/20 which should never be lost as they are used by capes at board level themselves.

Appreciate you taking the time and look forward to suggestions to debug this.

As a thought, could this device be 'gone' due to GPIO assignment on pin P9_20 - this would appear to be a mistake to me.

Colin