From owner-freebsd-arm@freebsd.org Fri Apr 19 07:21:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35FEB1587A25 for ; Fri, 19 Apr 2019 07:21:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8224D6A58B for ; Fri, 19 Apr 2019 07:21:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 3A7C61587A23; Fri, 19 Apr 2019 07:21:05 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15C591587A22 for ; Fri, 19 Apr 2019 07:21:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 944BF6A587; Fri, 19 Apr 2019 07:21:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=0RgnG3/ZeLhG8Obic2XPDoYxe+betwcRc6VGWUnVS2M=; b=Ao/VrIJro/oK1xUHU9vcPBJCovLGPqQJq2kbPmqUWCm4F3BZNTUDTSHEtQfQHQ5SpiuA+/tXfKo1qdV5N+0mlx7YPIJr/LQrRCdEyo1V0VHnpUOGA0YSRVmNFfifCJdfD2ZT9NaobEVF6Ga9iiBRVnfk20iai64SpLzC/nbEOSZsPtqcpS3csU1NT/aCjPqYaarFFXbqRGqtKSUjtA2GU/pk3EPqlrD8p5kXSrFzFP3vxc9da7bm0xVhBWovObsfURAQ8BUcpcUfpp5ULABcw6+rCbfZaAn/YmW2TcFkemU4M8T+VcioXNd5y8d/UdP4sF+9sARsYp4g6Vpqbixrwg==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1hHNpH-0004my-UI; Fri, 19 Apr 2019 10:20:47 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: i2c almost working for me, was Re: i2c still not working for me From: Daniel Braniss In-Reply-To: <64b5598e2c8c7265f89a31b1f191cb1be318788a.camel@freebsd.org> Date: Fri, 19 Apr 2019 10:20:47 +0300 Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <12F641C3-9FAA-4A3A-BA18-A7302F3A0F5E@cs.huji.ac.il> <20190409095819.c560dbc156c46e5ca0244e3e@bidouilliste.com> <23A47048-642A-481C-B7BE-B61E55F82955@cs.huji.ac.il> <20190409171604.GA4581@bluezbox.com> <6119CE3B-6042-4DDC-82BE-B0C0C7ADA838@cs.huji.ac.il> <5D4799BC-08DF-4F3D-81A4-C2D938F4AF93@cs.huji.ac.il> <20190417222601.c037efe0cb48987c81032bac@bidouilliste.com> <64b5598e2c8c7265f89a31b1f191cb1be318788a.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 944BF6A587 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.92)[-0.923,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 07:21:06 -0000 > On 18 Apr 2019, at 17:19, Ian Lepore wrote: >=20 > On Thu, 2019-04-18 at 10:12 +0300, Daniel Braniss wrote: >>> On 17 Apr 2019, at 23:26, Emmanuel Vadot >>> wrote: >>>=20 >>> On Tue, 16 Apr 2019 09:16:02 +0300 >>> Daniel Braniss > >>> wrote: >>>=20 >>>>=20 >>>>=20 >>>>> On 11 Apr 2019, at 09:56, Daniel Braniss >>>>> wrote: >>>>>=20 >>>>> if no device is connected, I2CRDWR hangs,=20 >>>>> it also happens with i2c(8) -s, only reboot helps. >>>>>=20 >>>>> ichb1: twsi_reset: Using IIC_FASTEST/UNKNOWN mode with speed >>>>> param=3D2a >>>>> iichb1: TWSI_WRITE: Writing 0 to 18 >>>>> iichb1: TWSI_WRITE: Writing 2a to 14 >>>>> iichb1: TWSI_WRITE: Writing 40 to c >>>>> iichb1: TWSI_WRITE: Writing c4 to c >>>>> iichb1: twsi_transfer: transmitting 2 messages >>>>> iichb1: TWSI_READ: read f8 from 10 >>>>> iichb1: twsi_transfer: status=3Df8 >>>>> iichb1: twsi_transfer: msg[0] flags: 0 >>>>> iichb1: twsi_transfer: msg[0] len: 9 >>>>> iichb1: TWSI_WRITE: Writing e4 to c >>>>>=20 >>>>> and now it?s hung >>>>=20 >>>> [?] >>>=20 >>> I don't see that on my OrangePi One or Pine64-LTS. >>=20 >> well, mine is are Nanopi Neo, maybe it=E2=80=99s a dts issue? >> I also have a orangepi-zero but it will take me some time to make >> a sdcard I managed to boot my OrangePi Zero, and i2c -s has no issues, does not = hang. still, with the latest (r346368) my NanoPi Neo hangs when no i2c device = is present, so what is the difference? or where can I look? >>>=20 >>>>=20 >>>> even with a working device, this happens sometimes: >>>>=20 >>>> my app gets ENXIO from the ioctl(fd, I2CRDWR, &data) and on the >>>> console: >>>> ? >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2 >>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2 >>>>=20 >>>> the good news: my app is killable :-) >>>=20 >>> I would need more details for this. >>=20 >> it was caused by i2c issues - the cable was a bit too long. >> BTW, does changing the frequency work? ie dev.iicbus.0.frequency >=20 > It looks like that driver does not honor the frequency sysctl/tunable. >=20 > You can often compensate for a too-long cable by adding some stronger > pullups. It's typical for a SOM to have pullups in the 4.7K range on > i2c. You can add your own 1K pullups to see if that helps the rise > times on the bus. well, at the moment it works ok with a 6m cable, i=E2=80=99ll try your = suggestion soon. >=20 > -- Ian >=20 cheers, danny