From owner-freebsd-arm@FreeBSD.ORG Thu May 1 00:18:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF17FCE0; Thu, 1 May 2014 00:18:28 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31EF8188B; Thu, 1 May 2014 00:18:28 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hi2so10008744wib.11 for ; Wed, 30 Apr 2014 17:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h8CIUapE3PiHO/FNHQJeA5MRhMnW/W2EX26Cb+XBBP0=; b=VsLuaUlSXa8+fle0Ip3zCl5BjN8sqLah81BZ+u9mFQPElW0XvFSelCfckz2n/wWMc8 r1epMzGDDFXee9IvEdxl8zV4Wp+tCsANON+NPHQ79u1TzsR4UJ4zjGJlMQlc1AJnXrWl 7Mf2u0q2JRghmMi3K57ITao8JvxQVzhg6Ws6J6sU9803fB+8DnyWTmBx4Hnk6klL3MTU Nd+q3L0flb54GuRcKBRVDyzw5fH8x5vgry/Lm0Wkz7uw92U++p1U7vJk1o6/jmemxDED u0R7CCz7t1ZCwgpTJWQW0caQ3LqXw4vUKPH6hkkR36ctXrwq5az4KX8JkI6aSBmjlTeJ 2WFQ== MIME-Version: 1.0 X-Received: by 10.180.100.129 with SMTP id ey1mr5966793wib.60.1398903505985; Wed, 30 Apr 2014 17:18:25 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Wed, 30 Apr 2014 17:18:25 -0700 (PDT) In-Reply-To: <1398903188.22079.89.camel@revolution.hippie.lan> References: <93181B67-1944-4DDD-A595-455D2AE9B110@grondar.org> <1CFC3564-65F0-4DC8-950C-3D53BBB2761C@FreeBSD.org> <1398903188.22079.89.camel@revolution.hippie.lan> Date: Wed, 30 Apr 2014 20:18:25 -0400 Message-ID: Subject: Re: i2c on RPI-B not working From: Winston Smith To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:18:28 -0000 On Wed, Apr 30, 2014 at 8:13 PM, Ian Lepore wrote: > 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. i2c(8) being the user-mode utility; is the i2c kernel implementation functional? > 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). It sounds very similar to how Linux maps the BBB's EEPROM into /sys/bus/i2c/devices/0-0050/eeprom I also have a DS1307 compatible I2C RTC that I'm hoping to support! Thanks -W