I2C woes

I will keep looking into this.
more infos

I took the current DTB file and decompiled it
I looked at the I2C sections

i2c0 = "/ocp/i2c@44e0b000";
i2c1 = "/ocp/i2c@4802a000";
i2c2 = "/ocp/i2c@4819c000";

            i2c@44e0b000 \{
                    compatible = "ti,omap4\-i2c";
                    \#address\-cells = <0x1>;
                    \#size\-cells = <0x0>;
                    ti,hwmods = "i2c1";
                    reg = <0x44e0b000 0x1000>;
                    interrupts = <0x46>;
                    status = "okay";
                    pinctrl\-names = "default";
                    pinctrl\-0 = <0x32>;
                    clock\-frequency = <0x61a80>;
                    linux,phandle = <0xa0>;
                    phandle = <0xa0>;

                    with PMIC infos below this

           i2c@4802a000 \{
                    compatible = "ti,omap4\-i2c";
                    \#address\-cells = <0x1>;
                    \#size\-cells = <0x0>;
                    ti,hwmods = "i2c2";
                    reg = <0x4802a000 0x1000>;
                    interrupts = <0x47>;
                    status = "disabled";                           

<--------------------------- anybody know why this is listed as disabled ?
linux,phandle = <0xa9>;
phandle = <0xa9>;

nothing below this as the processor pins are not connected to anything
except
"P9.18", /* i2c1_sda */ "P9.17", /* i2c1_scl */

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;
clock-frequency = <0x186a0>;
linux,phandle = <0xaa>;
phandle = <0xaa>;

                    With cape eprom infos below\.

It would seem to me that even though we have a /dev/I2C-1 its somehow
not enabled for use
IF i do a i2cdetect and grep dmesg it just repeats a bus timeout

I am at a dead end on this for my knowledge any help would be appreciated

Wulfie:

I am not an expert at Device Tree stuff, but this is what I think I know.
I2C-0 is intended for internal board management, so sort of reserved, except as a last resort.
I2C-1 is available, but not enabled, on the BBB and is enabled/implemented on the PocketBeagle, so you could always look at the PocketBeagle implementation.
The I2C-1 pins are default assigned to other things, so they will need to be re-assigned to the I2C-1 peripheral if used.
It would make sense that I2C-1 was not enabled, if not used by default on the BBB.
I2C-2 is enabled/implemented on the BBB and the PocketBeagle. It is the primary bus for cape memory access, so it is always there.
The DTB you were looking at seems to have an off-by-one number assignment, with respect to the bus numbers used by Linux.
I don’t understand why or how.
There was a definite off-by-one issue with the I2C bus assignments for Debian 7 and prior.

— Graham

I figure then, if we want to hook our own stuff up, then I²C1 is the
preferred port to use? In my case I'm running a PocketBeagle, and while
I've hooked up headers to I²C0, I haven't yet exposed those.

This is the DTB file on the green downloaded yesterday.
I dont understand that if its disabled why is there a /dev/i2c-1 file ?
They fixed the numbering starting with the 9.1 images from what i can read.
If it needs to be enabled how would one go about enabling it ?

Robert nelson had answered this back in december
I searched this once and must have missed this.

  Robert Nelson
12/27/17

Other recipients: simo...@gmail.com
- show quoted text -
We've moved to u-boot overlays, to achieve the same follow:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
<https://www.google.com/url?q=https%3A%2F%2Felinux.org%2FBeagleboard%3ABeagleBoneBlack_Debian%23U-Boot_Overlays&sa=D&sntz=1&usg=AFQjCNHpUazBsNo5wncImK9uTkuurXkrbg>

and set:

uboot_overlay_addr0=/lib/
firmware/BB-I2C1-00A0.dtbo

in /boot/uEnv.txt

Regards,

oaphdfakmpmcmpge.png

On the PocketBeagle, both I2C-1 and I2C-2 are both brought out to the headers and both enabled by default.
I don’t know that there is any reason to prefer one over the other on the PocketBeagle.

— Graham