Date: Sun, 12 Aug 2018 01:46:42 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: freebsd-arm@FreeBSD.org Subject: Re: BeagleBone Black with a I2C Digital Analog Converter Message-ID: <2CE2A485-A96E-4DE6-BCEA-BF7A29492A5D@obsigna.com> In-Reply-To: <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> <A8BCB12A-7D7E-46C7-A6B0-081DADAA1530@obsigna.com> <1534020139.31375.16.camel@freebsd.org> <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 12.08.2018 um 01:01 schrieb Dr. Rolf Jansen <rj@obsigna.com>:
>=20
>> Am 11.08.2018 um 17:42 schrieb Ian Lepore <ian@freebsd.org>:
>>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CE2A485-A96E-4DE6-BCEA-BF7A29492A5D>