BBB, BB-View and I2C port usage

Each physical pin can have up to eight different possible functions, but only one function can be enabled at a time. So yes, if the pin is being used for GPIO you can't also use it for i2c. If you try using overlays then the overlay will fail to load as there's a conflict of two things trying to use the same pin.

Even if not using overlays, two pinmux definitions for the same pin will cause an error message and the second function will fail to bind. When that happens, the driver won't load any the device you're looking for never appears.

When you say 'installing BB-View' what exactly do you mean?  Are you installing the complete BB-View angstrom image ?  Or just loading the BB-View dtbo file into an existing angstrom ? (with something like echo BB-VIEW-43-* > $SLOTS)

Simply loading a new overlay shouldn't cause anything to disappear, so if you do something like

ls /dev/i2c* and see three devices..

then do (without a reboot)

echo BB-VIEW > $SLOTS

ls /dev/i2c*

you should not see any change in available i2c devices. Although the overlay may fail to load if there's a conflict...

However, if you wipe the OS and reinstall something else the base devicetree may not be the same, if the new OS doesn't provide all three i2c busses even before it loads the BB-View overlay then your starting point is different and it's unlikely to be the BB-View itself that's causing it.

Anyway, here's what I see on a vanilla A5C BBB with the factory Angstrom image:

The Angstrom Distribution beaglebone ttyO0

 

Angstrom v2012.12 - Kernel 3.8.13

 

root@beaglebone:~# ls -l /dev/i2c*

crw------- 1 root root 89, 0 Jan  1 00:00 /dev/i2c-0

crw------- 1 root root 89, 1 Jan  1 00:00 /dev/i2c-1

root@beaglebone:~# i2cdetect -r 1

WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will probe file /dev/i2c-1 using read byte commands.

I will probe address range 0x03-0x77.

Continue? [Y/n] y

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

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

total 0

lrwxrwxrwx 1 root root 0 Jan  1 00:00 i2c-0 -> ../../devices/ocp.2/44e0b000.i2c/i2c-0/i2c-dev/i2c-0

lrwxrwxrwx 1 root root 0 Jan  1 00:00 i2c-1 -> ../../devices/ocp.2/4819c000.i2c/i2c-1/i2c-dev/i2c-1

the cape eeproms are 4 devices at 0x54-0x57 on /dev/i2c-1 which is the i2c bus at 0x4819c000.  In the TRM you'll find

Showing that /dev/i2c-1 is the peripheral named I2C2.

Remember that my look into the same directory on a different image had

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

which clearly shows you can't use the /dev entry to work out what pins are actually going to be used, and that you get different results from a different base dtb file.

(the 3.13 kernel I use has BB-View and all i2c interfaces enabled, but doesn't have capemgr and therefore I don't care about P9.18/19 being i2c2)

decompiling /boot/am335x-boneblack.dtb using "dtc -O dts -I dtb -o bb.dts /boot/am335x-boneblack.dtb" and looking at the result shows

pinmux_i2c0_pins {

     pinctrl-single,pins = <0x188 0x70 0x18c 0x70>;

     linux,phandle = <0x6>;

     phandle = <0x6>;

};

 

pinmux_i2c2_pins {

     pinctrl-single,pins = <0x178 0x73 0x17c 0x73>;

     linux,phandle = <0x7>;

     phandle = <0x7>;

};

where 0x178 and 0x17c are the pinmux addresses for P9.19 & P9.20.  Note that there's no section for i2c1_pins by default.

Later you'll find

i2c@4819c000 {

     compatible = "ti,omap4-i2c";

     #address-cells = <0x1>;

     #size-cells = <0x0>;

     ti,hwmods = "i2c3";

     reg = <0x4819c000 0x1000>;

     interrupts = <0x1e>;

     status = "okay";

     pinctrl-names = "default";

     pinctrl-0 = <0x7>;

     clock-frequency = <0x186a0>;

     linux,phandle = <0x26>;

     phandle = <0x26>;

 

     cape_eeprom0@54 {

          compatible = "at,24c256";

          reg = <0x54>;

          linux,phandle = <0xd>;

          phandle = <0xd>;

     };

 

     cape_eeprom1@55 {

          compatible = "at,24c256";

          reg = <0x55>;

          linux,phandle = <0xe>;

          phandle = <0xe>;

     };

 

     cape_eeprom2@56 {

          compatible = "at,24c256";

          reg = <0x56>;

          linux,phandle = <0xf>;

          phandle = <0xf>;

     };

 

     cape_eeprom3@57 {

          compatible = "at,24c256";

          reg = <0x57>;

          linux,phandle = <0x10>;

          phandle = <0x10>;

     };

};

showing how the cape eeproms are tied to the physical peripheral regardless of /dev entries.

Then later there's this:

bone_capemgr {

     compatible = "ti,bone-capemgr";

     status = "okay";

     eeprom = <0xc>;

 

     baseboardmaps {

 

          board@0 {

               board-name = "A335BONE";

               compatible-name = "ti,beaglebone";

               linux,phandle = <0x4b>;

               phandle = <0x4b>;

          };

 

          board@1 {

               board-name = "A335BNLT";

               compatible-name = "ti,beaglebone-black";

               linux,phandle = <0x4c>;

               phandle = <0x4c>;

          };

     };

 

     slots {

 

          slot@0 {

               eeprom = <0xd>;

          };

Note the 0xd in the eeprom line, this is the phandle used for cape_eeprom0@54 in the earlier section..  There's also nothing to stop you defining the eeprom to be on a different i2c bus if you feel like it. Or from pinmuxing I2C2 onto P9.21/22 for that matter

You can do exactly what I've done here on your problem BB-View setup to find out what's going on.  Remember though that the BB-View doesn't have a cape eeprom which forces you to manually enable it somehow - generally by some extra arguments on the kernel command line.

So it may simply be that while everything is configured otherwise identically, the pinmux_i2c2_pins section has been disabled/removed from the base dtb. Meaning that while capemgr will appear to work as normal it's simply unable to see any capes as any i2c access will never reach the outside world and you'll have to force load all overlays manually.

If that's the case, it's easily reversible, you just need to pick the bits of the devicetree that you want, remove the bits you don't and rebuild everything. Changing things that have something physically wired up may mean you need to get the soldering iron out in orger to prevent malfunctions though.

Ultimately it may simply be that as BB-View doesn't use the eeprom then that functionality has been sacrificed by it's designers. Whether we think that's a good idea or not almost certainly wasn't a factor in the decision.

Sorry for the long post... trying to work through devicetree quickly gets complex, and may not help anyway if we all have different base devicetree files as our starting points.  Hope you find some of this useful though.

Thanks, no apologies needed for long reply and your time is much appreciated.

When I say 'installing BB-View' I am referring to installation instructions in BB-View User Manual V1.6 - where is instructs one to copy files and un-tar kernel module

• cp -f /media/udisk/uImage /boot/
• cp -f /media/udisk/*.dtb /boot/
• tar -xvf /media/udisk/kernel_modules.tar.gz - this is the real scary step to me and makes me uncomfortable
• cp am335-boneblack-lcd4.dtb am335x-boneblack.dtb

This is a destructive install and there is no easy way of undoing install if one wanted to revert to using HDMI port as example - if there is a better way to do this please let me know.

These are the files downloaded per instructions - note there is no BB-VIEW*.dtb (which would be my preference)

$ ls -l

total 73408

-rwxr-xr-x@ 1 cccc  staff     23798 Nov 21  2013 am335x-boneblack-lcd4.dtb

-rwxr-xr-x@ 1 cccc  staff     23798 Nov 21  2013 am335x-boneblack-lcd7.dtb

-rwxr-xr-x@ 1 cccc  staff     23798 Nov 21  2013 am335x-boneblack.dtb

-rwxr-xr-x@ 1 cccc  staff  33135741 Nov 21  2013 kernel_modules.gz

-rwxr-xr-x@ 1 cccc  staff   4371504 Nov 21  2013 uImage

Also, when reviewing listed i2c devices I don't see i2c at 0x4819C000 after BB-View install, I only see it prior to install.

Note, I did nothing else besides what's described in the manual. In my case it is definitely the case that installation of BB-View is removing I2C interface and is not due to any messing around with base OS install (besides what's stipulated in user manual).

My understanding is that the I2C on pins P9-19/20 are primarily for use by system for 'discovery' (my words) of capes and capability and can be used by other processes as long as there is no conflict in I2C addressing. It appears to me that BB-View not only doesn't support cape eeprom but also disables it removing this capability from the system - to me this is a degradation of BBB ecosystem and doubt it would be considered as a compatible cape (maybe I totally misunderstand, but clearly the i2c support is missing and in it's place I have a rather (resource) expensive led that I can toggle).

If there is another way to install BB-View (as you seem to be suggesting) then I'd really like to look into that, else it may be time to RMA devices ordered and look for more suitable (for this project) LCD solution.

Again, I appreciate your time on this, I am definitely learning more and hopefully this can help others as well.

Right, maybe begins to make some sense... I've not used Angstrom in a very long time, so forgive if I end up sidetracked by stuff from other distros sometimes.

At a guess what you have there is a custom kernel that contains the modified driver for the touchscreen and a dtb that contains all of the details of the BBB itself along with the BB-View in one file. Depending on which display you have, you just copy am335x-boneblack-lcd7.dtp over the top of am335x-boneblack.dtb and switching is simple.  It also seems likely that other capes are effectively disabled with this configuration.

What you can probably do is compare the contents of your original angstrom am335x-boneblack.dtb with the new one provided for the BB-View to find out what they've done.

As for it being a destructive install, yes and no.. the files are limited to a few places. The modules all go to a directory under /lib/modules/<kernel_version> for example. So it's fairly easy to backup the originals and restore them, I'd think you could easily put together a script to do the swap.

You may even be lucky and the modules will be in different directories, in which case it's really just kernel and dtb that you would have to backup.

Is there any particular reason you have to stick to using angstrom?  New BBB boards are going to have Debian installed instead as the factory image, so possibly it's better to invest your time in Debian rather than angstrom.  Don't know if you've seen it, but there's a discussion on getting the BB-View working on the new debian builds here: http://www.element14.com/community/thread/31051/l/how-to-bb-view-on-latest-debian

If you read through that, you'll see that there is an overlay for the BB-View available in the angstrom source download. Louis did a good job figuring out what was needed to get everything working on debian, but even so there are signs later in the discussion that the base debian devicetree has changed somehow with a few people having problems getting the overlay to load without more modifications.

Even switching to debian may leave you with the same problem with I2C2, but with an overlay it may be simpler to resolve. (I never really looked too closely at the debian image as I'd already done my own linuxfromscratch build by then)

As for the BB-View being actively hostile to the rest of the cape system, yes I think we can take that for granted.  It requires changes to the touchscreen driver that are incompatible with CircuitCo LCD capes, and as you're seeing makes other things difficult as well. Since there's no way to force anyone to build compatible capes, I don't think the situation will get better.

From a personal point of view, I'm very close to thinking that the whole cape system is doomed to failure, or at least permanent life-support. Happy to discuss the reasons I think that separately if you like, but they're not really relevant to this discussion.

Makes sense. Actually I do want to switch to Debian, I was just trying Angstrom first as a baseline, maybe I will switch now and try.

Would love to chat more, please contact me on colin_at_besterdesigns.com