Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B

On 06 Mar 2022 23:09:14 UTC
Don Kuenz <mail@crcomp.net> 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: <BCM2708/2835 GPIO controller> mem 0x7e200000-0x7e2000b3 irq
> 7,8 on simplebus0 gpiobus0: <OFW GPIO bus> on gpio0
> gpioc0: <GPIO controller> on gpio0
> gpioled0: <GPIO LEDs> 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