From owner-freebsd-arm@freebsd.org Sun Aug 12 04:46:49 2018 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 B578C1063BBB for ; Sun, 12 Aug 2018 04:46:49 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 384D878143 for ; Sun, 12 Aug 2018 04:46:48 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id 8099055 for ; Sun, 12 Aug 2018 06:46:47 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 022F21350F91D for ; Sun, 12 Aug 2018 01:46:43 -0300 (BRT) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: BeagleBone Black with a I2C Digital Analog Converter Date: Sun, 12 Aug 2018 01:46:42 -0300 References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> <1534020139.31375.16.camel@freebsd.org> <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> To: freebsd-arm@FreeBSD.org In-Reply-To: <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> Message-Id: <2CE2A485-A96E-4DE6-BCEA-BF7A29492A5D@obsigna.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 04:46:49 -0000 > Am 12.08.2018 um 01:01 schrieb Dr. Rolf Jansen : >=20 >> Am 11.08.2018 um 17:42 schrieb Ian Lepore : >>=20 >> On Sat, 2018-08-11 at 17:30 -0300, Dr. Rolf Jansen wrote: >>>>=20 >>>> ... >>>> , anyway I am >>>> stuck at this point. >>>=20 >>> I got it working. >>>=20 >>> 1.) The specification of the DAC board which I attached to my BBB = was >>> wrong in regards to the acceptable Vcc voltage range (2.7 to 5.5 V). >>> ...=20 >>>=20 >>> 2. There is still something wrong with my overlay. I need to hack in >>> the same I2C1 changes into the main DT, and then the bus scan by i2c >>> -f /dev/iic1 -s gives me the expected output. For my present = project >>> this is a minor issue, though. My best guess here is, that there is = a >>> problem with the reference of the I2C1 node to the proposed pinmux >>> node. >>>=20 >>> On Debian/Linux the very overlay does work. >>>=20 >>=20 >> Ah. The board probably does support 2.7-5.5v, but if the i2c bus has >> pullups that only pull the lines up to 3.3v, that may be too close to >> the VIH transition levels for the DAC chip running at 5v. Even if = it's >> within the VIH range, if the pulls aren't strong enough the clock >> signal may not rise above the 5v VIH fast enough for reliable comms. >=20 > I was too happy too soon. >=20 > Now, I updated my system to the 12 snapshot from yesterday, which = turned it from 12-CURRENT to 12-ALPHA1, and with that one, the issue = number 2 above turned from a minor issue to a major problem, in order = not to say a whole new barrier is now blocking all my further efforts. = It seems that in 12-ALPHA1 the DTB is statically compiled into the = kernel, and now I cannot simply hack-in anymore some nodes which don't = work by the way of overlays >=20 > OK, in the moment I may switch back to 12-CURRENT, however, I am = elaborating this project with 12 now, so I won't have any headaches in = the future. Now I am stuck again. Please may I ask for an advice? >=20 > May I expect that pinmuxing will work in a not too distant future with = overlays? I found the problem with my overlay. I needed to add a __local_fixups__ = section, and with that in place, it is working on FreeBSD 12-ALPHA1. I = am sorry for the false alert. For future reference, here comes the = source for my working I2C1 overlay: /dts-v1/; /plugin/; / { compatible =3D "ti,am335x-bone-black", "ti,am335x-bone", = "ti,am33xx"; part-number =3D "I2C1"; version =3D "0001"; exclusive-use =3D "P9.17","P9.18","i2c1"; fragment@0 { target =3D <&am33xx_pinmux>; __overlay__ { i2c1_pins: pinmux_i2c1_pins { pinctrl-single,pins =3D <0x158 0x32 = 0x15c 0x32>; }; }; }; fragment@1 { target =3D <&i2c1>; __overlay__ { status =3D "okay"; pinctrl-names =3D "default"; pinctrl-0 =3D <&i2c1_pins>; clock-frequency =3D <400000>; #address-cells =3D <0x1>; #size-cells =3D <0x0>; }; }; __local_fixups__ { fragment@1 { __overlay__ { pinctrl-0 =3D <0x0>; }; }; }; }; Best regards Rolf