Date: Mon, 7 Mar 2022 09:25:38 -0800 From: Mark Millard <marklmi@yahoo.com> To: Don Kuenz <mail@crcomp.net> Cc: freebsd-arm@freebsd.org Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B Message-ID: <9B2150A8-40AA-47CE-9A78-985129865A7E@yahoo.com> In-Reply-To: <20220307144832.6D1771A0C112@mlmmj.nyi.freebsd.org> References: <47C61079-AB2E-4E81-AD95-F6042477D4E8@yahoo.com> <20220307144832.6D1771A0C112@mlmmj.nyi.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Mar-7, at 06:48, Don Kuenz <mail@crcomp.net> wrote:
> Attempt number four to answer Mark's question in regards to the origin=20=
> of config.txt content. (The em control character spewed out by "man"=20=
> mangled my mail earlier.)
>=20
> Mark wrote:
>> Don wrote:
>>>=20
>>> and /boot/msdos/config.txt looks like this:
>>>=20
>>> root@generic:/boot # cat /boot/msdos/config.txt
>>> init_uart_clock=3D3000000
>>> enable_uart=3D1
>>> kernel=3Du-boot.bin
>>> kernel7=3Du-boot.bin
>>> dtoverlay=3Dmmc
>>=20
>> config.txt seems fine up to here. But I've never seen
>> anything indicating that the following notation is
>> valid for config.txt files:
>>=20
>>> / {
>>> gpioiic0 {
>>> compatible =3D "i2c-gpio";
>>> pinctrl-names =3D "default";
>>> pinctrl-0 =3D <&pinctrl_gpioiic0>;
>>> scl-gpios =3D <&gpio2 3 GPIO_ACTIVE_HIGH>;
>>> sda-gpios =3D <&gpio3 5 GPIO_ACTIVE_HIGH>;
>>> status =3D "okay";
>>> };
>>> };
>>=20
>> If you have a reference indicating otherwise, I'd
>> be interested to know what it is.
>=20
> # man gpioicc
config.txt is not something from FreeBSD at all, its
is from/for RPi* firmware only and is common across all
contexts that use the RPi* firmware. Only RPi* specific
documentation applies to the content supported in
config.txt on the msdos file system for an RPi*.
In other words: man gpioicc does not in any way refer
to the config.txt file involved in booting an RPi*
(for any operating system). To my knowledge no FreeBSD
man page covers much about files that are specific to
the RPi* firmware (ignoring, say, drivers strictly
specific to RPi* contexts).
> =
------------------------------------------------------------------------
> GPIOIIC(4) FreeBSD Kernel Interfaces Manual =
GPIOIIC(4)
>=20
> NAME
> gpioiic - GPIO I2C bit-banging device driver
>=20
> SYNOPSIS
> To compile this driver into the kernel, place the following lines =
in your
> kernel configuration file:
>=20
> device gpio
> device gpioiic
> device iicbb
> device iicbus
>=20
> Alternatively, to load the driver as a module at boot time, place =
the
> following line in loader.conf(5):
>=20
> gpioiic_load=3D"YES"
>=20
> DESCRIPTION
> The gpioiic driver provides an IIC bit-banging interface using two =
GPIO
> pins for the SCL and SDA lines on the bus.
>=20
> gpioiic simulates an open collector kind of output when managing =
the pins
> on the bus, even on systems which don't directly support =
configuring gpio
> pins in that mode. The pins are never driven to the logical value =
of
> '1'. They are driven to '0' or switched to input mode =
(Hi-Z/tri-state),
> and an external pullup resistor pulls the line to the 1 state =
unless some
> other device on the bus is driving it to 0.
>=20
> HINTS CONFIGURATION
>=20
> <snipped>
>=20
> FDT CONFIGURATION
> On an FDT(4) based system, such as ARM, the DTS node for gpioiic =
conforms
> to the standard bindings document i2c/i2c-gpio.yaml. The device =
node
> typically appears at the root of the device tree. The following is =
an
> example of a gpioiic node with one slave device on the IIC bus:
>=20
> / {
> gpioiic0 {
> compatible =3D "i2c-gpio";
> pinctrl-names =3D "default";
> pinctrl-0 =3D <&pinctrl_gpioiic0>;
> scl-gpios =3D <&gpio1 5 GPIO_ACTIVE_HIGH>;
> sda-gpios =3D <&gpio7 11 GPIO_ACTIVE_HIGH>;
> status =3D "okay";
>=20
> /* One slave device on the i2c bus. */
> rtc@51 {
> compatible=3D"nxp,pcf2127";
> reg =3D <0x51>;
> status =3D "okay";
> };
> };
> };
This document does not say where the above text would
go for any system or what toolchain (if any) is involved
in putting it to use.
There can even be issues like the RPi* firmware and
FreeBSD kernel disagreeing about .dtb content and
the like. The FreeBSD firmware is still somewhat active
when FreeBSD runs as I understand. If true, it could
be important to have the RPi* firmware have the same
.dtb context as the kernel, normally by updating what
the RPi* firmware uses and letting the kernel
(indirectly) get its dtb information from the RPi*
firmware.
(I mention that because, if I remember right, one of
the replies proposed working strictly on the FreeBSD
side. I'm not sure such is appropriate to an RPi*.
However, I'm not an expert.)
> Where:
>=20
> compatible Should be set to "i2c-gpio". The deprecated =
string
> "gpioiic" is also accepted for backwards =
compatibility.
>=20
> scl-gpios sda-gpios
> These properties indicate which GPIO pins should be =
used
> for clock and data on the GPIO IIC bit-banging bus.
> There is no requirement that the two pins belong to =
the
> same gpio controller.
>=20
> pinctrl-names pinctrl-0
> These properties may be required to configure the =
chosen
> pins as gpio pins, unless the pins default to that =
state
> on your system.
>=20
> SEE ALSO
> fdt(4), gpio(4), iic(4), iicbb(4), iicbus(4)
>=20
> =
------------------------------------------------------------------------
>=20
> I'll take a closer look at "man dtc" and "i2c/i2c-gpio.yaml"
>=20
> =
https://mjmwired.net/kernel/Documentation/devicetree/bindings/i2c/i2c-gpio=
.yaml
>=20
> Other replies in the thread provide me with additional food for =
thought
> for the time being.
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9B2150A8-40AA-47CE-9A78-985129865A7E>