From nobody Mon Mar 07 07:10:05 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 EE66F19FBBFC for ; Mon, 7 Mar 2022 07:10:10 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KBqNK4l8Fz3JVw for ; Mon, 7 Mar 2022 07:10:09 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Mon, 07 Mar 2022 08:10:07 +0100 id 00DADC7E.6225AFCF.000035B7 Date: Mon, 7 Mar 2022 08:10:05 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B Message-ID: <20220307081005.6a944b46@zeta.dino.sk> In-Reply-To: <20220306230947.47F0A19F60FF@mlmmj.nyi.freebsd.org> References: <20220306231815.6ea9b3b2@zeta.dino.sk> <20220306230947.47F0A19F60FF@mlmmj.nyi.freebsd.org> X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KBqNK4l8Fz3JVw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 06 Mar 2022 23:09:14 UTC Don Kuenz wrote: > Milan wrote: > > > could you show us what's in /dev directory? Probably no iic0 file > > there. Also, you did not write which kernel are you using. For > > /dev/iic0 to appear, you need either 'device iic' in your kernel > > config or load it dynamically via 'kldload iic', in addition to > > working i2c controller. > > > > Showing your 'dmesg' output helps to determine what's going on, > > along with DTB used as well. > > > > All this are just basic hints what and where to look for, there are > > probably other as well, but I hope this helps. > > root@generic:~ # dmesg | grep iic > OK, this means no iic device is being detected. > root@generic:~ # dmesg | grep gpio > gpio0: mem 0x7e200000-0x7e2000b3 irq > 7,8 on simplebus0 gpiobus0: on gpio0 > gpioc0: on gpio0 > gpioled0: on ofwbus0 > So, you have GPUIO controller present, you should see what's available to control it with 'gpioctl -lv' (it uses /dev/gpioc0, which should be present in your system according to the dmesg snippet above). > root@generic:~ # ls /dev/iic* > ls: /dev/iic*: No such file or directory > This confirms what I wrote above, no iic device. > root@generic:~ # kldload iic > kldload: can't load iic: module already loaded or in kernel > You are probably using GENERIC kernel, judging from host name show, and indeed, 'device iic' is present in GENERIC kernel config. > root@generic:~ # kldstat > Id Refs Address Size Name > 1 14 0xc0000000 d6a938 kernel > 2 1 0xc0d6b000 23358 gpioiic.ko > 3 2 0xc0d8f000 23fcc iicbb.ko > 4 1 0xc0db3000 24f48 umodem.ko > 5 2 0xc0dd8000 28328 ucom.ko > 'kldstat -v' would show more details, device iic is presented as part of kernel, most probably (again, judged from what you present). > FreeBSD 11.1 automatically creates /dev/iic (unsure of the suffices). > But 11.1 is now obsolete. FDT replaced automatic IIC bit-bang driver > discovery. > You need to "wire" FDT beforehand. Although there's hints and > configuration snippets all over the Inet, a full blown howto example > eludes me thus far. > Well, I think what Mark wrote is exactly what's needed. As I did not work with Raspberry a long time, I can't tell anything about config.txt in /boot/msdos directory (or, in another word, in FAT partition available for pre-FreeBSD boot loader), but I think this snippet from your first message should not go there: > / { > gpioiic0 { > compatible = "i2c-gpio"; > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_gpioiic0>; > scl-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>; > sda-gpios = <&gpio3 5 GPIO_ACTIVE_HIGH>; > status = "okay"; > }; > }; My gut feeling here is it is just being ignored because syntactically it does not make much sense. I may be wrong here. Do you have any pointer where you got this snipped from? For me it would be meaningfull if you put this snippet into a file, say, rpi2-gpioiic.dtso, use DTB compiler to create binary blob, rpi2-gpioiic.dtbo. I would create such an overlay by putting source file into sys/dts/arm/overlays directory and modifying Makefile in sys/modules/dtb/rpi directory to include rpi2-gpioiic.dtso in DTSO variable for appropriate MACHINE_ARCH. (As I see there now, file name should be gpioiic-rpi2.dtso to match the convention used here, but this is functionally irrelevant.) This way, overlay file would be created when doing 'make buildkernel' and installed in appropriate place with 'make installkernel', but it is possible to do just FDT overlay build, I just do not know exact commands from my memory. Now, when you have your overlay in /boot/dtb/overlay directory, you need to activate it by including its name in fdt_overlays variable in loader.conf file present in /boot directory, so there should be line like this: fdt_overlays="rpi2-gpioiic" I hope this is correct and usefull for you. It's based on my experience elsewhere, but this is what works for me on my boards, albeit not RPI (I did not use for a long time). Also, you can try 'ofwdump -a' command to see which devices should be present according FDT provided to system before and after doing some change to verify there is some effect from your changes... Regards, Milan