From nobody Mon Mar 07 17:25:38 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 43E291A0DDD9 for ; Mon, 7 Mar 2022 17:25:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KC52l1nvTz4rCh for ; Mon, 7 Mar 2022 17:25:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646673944; bh=2fqLh5m9USW/r4fn5/lSyKOlM8QhF8BndyysYpkPjx8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IyoodA77TpQdrigzu9DbE4xm2QbUonaOgpNu62PRy8FSvCu3Y24Q5c65SwyQUaNcF7xpFaceKdY/E0u35z0Ft8ERYx6l82OyUW/9I9hfSfPA7fzNJ19RU54+Mm/t8Cug+undMazPekRUcxDhe4xSul3zcKcjNDwyBLBhODLWA64vpKEJhgAa9Yq3UA1t1s8yTNFquWH0l/n7xi7wA0hrDAblNj6GVKD+JBcnl/F1AaGr60tdvaz2X6rziLvUwJyxc4mcGu0CFL9u85RsOgmHxhR4oQSQ6NBWX9u9XwJ4Xa/lM9Z4zCk99xzw9N5CCnP11v15UsXu8u+2Y/W4hxlE4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646673944; bh=2IZdYycHNH60YqxM4HDE1slXwvt+sH0PxpkciOJknpm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MO95kKuj62BIvZ8Gc/e89LECfMsSPkNRvzQkA19tZDR8i1B0zDuBpsPJqaEx82IZmoLcYhUfU7srxlO4ra2a32AHZkX3CgLk83OKQibBbIvQT1h2UIWz2cOy2qXUZuIw6nOmj7abnmgQco80tOe+ZzWhplfB/LfZRqlyfRQO8ZDl7WSLPEqRSBhtbEOEHVSbgDio3nb9femB64A6eO9nlAjKAtA0Ni5H7f5idnCgXGBN5FYXF9yrUaL2S4hpCWMaeyThSAtOIbX1gwVahaZQAVA8nhoeWfkI2oANVFGbO713H2k7oTZZTPxvbZcmUDTLGtDADNwLFm+I3EaP+iKx2Q== X-YMail-OSG: o9zmkuEVM1nloZiFpADWG_lm8U1rKpXAPCSIbgDumcoFAB5T2vlgKN4OxW2Yo7C _GEsITBTnVhUIk1V8svYsT3Ublzr4xlO9dh.GMAG8uHMwmzBXm8rWaQN5d2y__gSVcSXnOOai9Wb hc1f7cxNV4EfJSAqDmCepcbb_CiLIGWeynVjmqgap4ppdd77zc9rnvSxG6__pF0sEHWi53Y5Di3r iFC_5QWivFqib5k98T4VUa8gdJkTI.A7UXo9il49_ubgdpHLvPnGHIN4LPxTH68jZfwOU7FofdIl Wa6qY1.TU_AAooQPINscqIwTqafiet_DyeWpMLezU0imLmzDLpHB4mJA4DirK80enp_MqPIiMGjL d75SLQI9XGgeFuQXgHJDGwm6BpxOecM1Dt4YKsEKOxGGD5VhpfrGKG7hpXzQ0dh7nJRZtH0TPveB 0sFgGOCahxoM924.gm8eAP9bKi04q__0A1mMYir6PQW4keR4hnn1.Y3Q28wYSIeWfoDrv4iOzuym nhgpAbSmVQhllIR1FMiT8xNzVCyphDatJsdgXQiQz0uM6bPr.ZHeUqoX5rxwwBy181xNIbFO.vIS F9oMYjzvg5L8wKi.EUZYqd.EIoDFBC0XnJ3lnj7sZ1GZn4tywMqJAu9CtP0usSGWdN1IyQQ5l2vG PEz6wv8OWQxK_STMEjt3J2DxJuqwtLm39F8x3OIGK4u.kKU.sz6SVfi.4EA6WPLXP.WM3anEmaYJ wX75usoRDvMlnGByRRaulCMLAlQzHR_ISz4u3Yv7sDpgGUeQa1sdSGwiO32kIIysHr6_KMnWoIY_ FFtpaWHrQ8eI_mhFaIQdZEnQ89zIEMbaR1pecsGJ4rfthWMaWLV0fyGpILALtRzlr3KllybDGR2E Bm2BE7K56OydyGop6EMBn6ZI._scRjuoPQd.Dok2rFxMnImfIs9TkAVkTdMqJAMCvHS7v6TptuL1 RRDzipl4OKtiYJXNsV5GgxfFrwOYvE5gV6h9OxI9hfjeheMCFUEHTc.cMJF8hoG8dYhHebY1Q_KK 9EdCH.pKj3ZnnGxyvrlTMbGy6ktHVET7SztXykMlmHDot1P1lhzUDJyt3E8KxSUvoOxBYewd2QSj qrCe8NOTDbkC_AhKaXrG51NqapKf7jfyha_w1Lc01Yo7pUVwzroVm3cJvkINS_tGA0OFaJ4fgf0j kBYwZVkncq0qG_yGqynPacHNMMoI1bpC9UmdRQBfZNUXnDmHrRBzOqjK81c2A8YqLNl1_At_rg._ 1zINlZTdM39EqzV9Ci778ud1i_k.t_2COspjZtQYCjnuyOJomtEjss45ZtZplPKlGnjz99v1xW8J zLgH8ztcs0QLcTxpEnHfk9rwlpth8ser5iS9GctnOq7SN0m8TEiN7Org0AftKUIQIfqOv7RBN_4M 8JB7FokUq8eJflPMAwbUy4yc36d5Xw7CZjd0eOBdMJcBOgpkWxF5WhRGC.l2lO6peAEvmmWOKs1F cWogYL_.y3qiUXoyGk2Wfi.EGxKnB8rZ7GF7aIDSXhX2Mjwkxyxe0Do3buFhVVOD1shbPIf9IueF fH.pxr7OpFkNZaa8VBSKC225uh09j56R8bcPX4Vy04JTy9FEf6ychmou_2YSrblVcf1dijrB8yeN gYNszMAgFdS7Zie_ztl9YyuEzsCxv6aZbK9LHWJqE.zDOpfO7aYoL3GBQHrFicAaaSrAtUfETDlU BhrC5gZmZgUW0wdGNbhsiQstbwIBJi3yCHD5xrUN6jgaktJWnBwF9LfdXo5CekfeuHZQw7egpG7b _hgJNITshxvLN860ENQZmctot7KtBFjoPJ8ydPAEABbdcM8gtDpJ_L.ZgsBiwgT8D0mkzeHDV_9r lK14IV_I.S61Rhp9OelgHS0DrTVY.M2wPyTwsuit1._N41F14UwevVfImx_8HbXJMAGJNLMC7MQ1 Ok9kP1OXlHtq02Sw0kZDiJOunruD5nfxgqMHZBCKL56THuLN2S7hdyAsVpuTv9.J9MGx60Hb4wxr JKXZqUIS7HgJXxAwsmoyorWcjiwwqqoxMAfwU4vYLvY6cUZC6H_hkcV6t00G9R1GEMegvxVGAuyb tivie2xjQTyjmMT87wl6LQpiKRz4pTzeFw.5aPcrI9riB0TtngG.cqeA2aYBR3ZxC5py.B3dOHkA rfSD_Bz8V_253pRdjuP5s1LHPBI3a8.Iu8BzI8tmJrSXoIHEyG9b.oI2fLxbJsUzAk2yn3k0rEkI .RoYjxL4FRSqfBbgLWYgPMr02OcnL8_H5FySXizq_zc3UMu8vUNSiinAVpmdzqxQKbBQXNf0PotP k49h811.f728jg8iQ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 17:25:44 +0000 Received: by kubenode523.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c8982908dc2d63c5ff62b39a41b78f1a; Mon, 07 Mar 2022 17:25:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B From: Mark Millard In-Reply-To: <20220307144832.6D1771A0C112@mlmmj.nyi.freebsd.org> Date: Mon, 7 Mar 2022 09:25:38 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9B2150A8-40AA-47CE-9A78-985129865A7E@yahoo.com> References: <47C61079-AB2E-4E81-AD95-F6042477D4E8@yahoo.com> <20220307144832.6D1771A0C112@mlmmj.nyi.freebsd.org> To: Don Kuenz X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KC52l1nvTz4rCh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IyoodA77; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.51 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.51:email]; NEURAL_SPAM_SHORT(0.99)[0.994]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[0.0.0.51:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Mar-7, at 06:48, Don Kuenz 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 > >=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