Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Apr 2014 18:13:08 -0600
From:      Ian Lepore <ian@FreeBSD.org>
To:        Winston Smith <smith.winston.101@gmail.com>
Cc:        freebsd-arm <freebsd-arm@FreeBSD.org>, Mark R V Murray <mark@grondar.org>
Subject:   Re: i2c on RPI-B not working
Message-ID:  <1398903188.22079.89.camel@revolution.hippie.lan>
In-Reply-To: <CADH-AwFDk2uzOcNQQx%2BL%2BHGBgc7vccQVXLta_g6D3HRHhZxYsQ@mail.gmail.com>
References:  <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> <CADH-AwFDk2uzOcNQQx%2BL%2BHGBgc7vccQVXLta_g6D3HRHhZxYsQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2014-04-30 at 19:49 -0400, Winston Smith wrote:
> On Tue, Apr 29, 2014 at 1:07 PM, Rui Paulo <rpaulo@freebsd.org> wrote:
> > This is because the controller doesn't support scanning.  You need to write your own C program to issue iic ioctls for reading / writing to the i2c bus.
> 
> I'm in the same process except on a BeagleBone Black (currently
> running 11-CURRENT).  Running `i2c -sv` under `ktrace -t+`, it's
> returning:
> 
>    956 i2c      CALL  ioctl(0x3,I2CRSTCARD,0xbffffcc8)
>    956 i2c      RET   ioctl 0
>    956 i2c      CALL  ioctl(0x3,I2CSTART,0xbffffcc8)
>    956 i2c      RET   ioctl -1 errno 6 Device not configured
>    956 i2c      CALL  ioctl(0x3,I2CSTOP,0xbffffcc8)
>    956 i2c      RET   ioctl -1 errno 22 Invalid argument
> 
> 
> I know from Linux on the BBB, that when you run `i2cdetect`, you need
> to specify the `-r` to use "read byte" commands to probe the i2c bus
> and indeed I've written i2c code previously using ioctl() with
> I2CRDWR.
> 
> So I cobbled together a I2C bus scanner, i2cscan.c:
> http://pastebin.com/RxpRCyJU
> 
> root@beaglebone:~ # ./i2cscan /dev/iic0
> Checking device: /dev/iic0
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 
> 
> Hmmm ... on the BBB it's still not detecting anything; in fact
> according to `ktrace`, it seems to still return ENXIO (Device not
> configured):
> 
>    988 i2cscan  CALL  ioctl(0x3,I2CRDWR,0xbffffc58)
>    988 i2cscan  RET   ioctl -1 errno 6 Device not configured
> 
> 
> Not entirely sure why it's not detecting anything since I *know* the
> BBB has an EEPROM at 0x50 on bus 0 (I2C0 @ 44e0b000), which according
> to ofwdump should be iic0:
> 
> root@beaglebone:~ # ofwdump -a
> Node 0x38:
>   Node 0xc4: am335x
>     ...
>     Node 0x1504: i2c@44e0b000
>       Node 0x1590: pmic@24
>     ...
> 
> So:
> 
> 1) Hopefully, you'll have more luck with the i2cscan.c tool I wrote than I did!
> 2) Does anyone know why I'm not detecting any i2c devices on the BBB?
> 
> Thanks!
> 
> -W

I saw it mentioned on irc the other day that i2c(8) isn't very
functional on most of our ARM systems.  It's expecting a different
interface to the i2c hardware in which it sees all the low-level
protocol events.  Most modern hardware has more of a "do this whole
transaction for me" type interface.  We probably need to enhance i2c(8)
to work (as much as it can) in such a mode.

The i2c eeproms, on the other hand, should just work.  Add 'device icee'
to the kernel config, and in the dts file make an icee entry that's a
child of the i2c controller entry.  Something like this (this is for
wandboard)...

		i2c@021a4000		
		{
			status = "okay";
			icee@a0 {
				compatible = "atmel,24c256";
				reg = <0xa0>;
				status = "okay";
			};
		};

You'll end up with a /dev/icee0 device which you can read and write and
seek and so on.  Note that the device will show up even if the hardware
isn't there or isn't responding, there's no actual probe for hardware.
If you do "dd /dev/icee0 | hd" and it comes up all-bits-one that's
usually a sign that there's no hardware (but it could also be a brand
new eeprom with nothing written to it).

-- Ian







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1398903188.22079.89.camel>