I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

GoogleGroups
1

OK, I have made use of the MCP23008 and MCP23017, 8 bit and 16 bit GPIO
expanders that are I2C connected on Raspberry Pis. The Raspberry Pi kernels
include both an overlay (Device Tree Blob) and a driver module for the
MCP23008 and MCP23017 chips. I would also like to make use of these chips on
my beagle boards (a BeagleBoneBlack and a PocketBeagle).

I just did some poking around on my BBB, and there are neither Device Tree
Blobs nor driver modules for the MCP23008 and MCP23017 chips.

So, my question is: What is involved in building the missing driver modules
and Device Tree Blobs -- I have built driver modules and even rebuilt whole
kernels on x86 Linux boxen, so I have passing knowledge of how that goes, what
I am really wondering: is there a repo with .deb files containing the "extra"
ko files? Or tarballs containing the additional sources? I realize the BBB
and PB are rather slow, so maybe I should cross build this on one of my Pis?
Or is there an alternitive kernel I can upgrade to that includes these
modules?

Right now my two Beagles are running 4.14.71-ti-r80, Debian GNU/Linux 9,
BeagleBoard.org Debian Image 2018-10-07. I did do a apt-get update/apt-get
dist-upgrade about a month ago (May 14).

2

it's enabled, just after r80 came out.. Just run, and then reboot..

sudo /opt/scripts/tools/update_kernel.sh

Regards,

3

>
> OK, I have made use of the MCP23008 and MCP23017, 8 bit and 16 bit GPIO
> expanders that are I2C connected on Raspberry Pis. The Raspberry Pi kernels
> include both an overlay (Device Tree Blob) and a driver module for the
> MCP23008 and MCP23017 chips. I would also like to make use of these chips on
> my beagle boards (a BeagleBoneBlack and a PocketBeagle).
>
> I just did some poking around on my BBB, and there are neither Device Tree
> Blobs nor driver modules for the MCP23008 and MCP23017 chips.
>
> So, my question is: What is involved in building the missing driver modules
> and Device Tree Blobs -- I have built driver modules and even rebuilt whole
> kernels on x86 Linux boxen, so I have passing knowledge of how that goes, what
> I am really wondering: is there a repo with .deb files containing the "extra"
> ko files? Or tarballs containing the additional sources? I realize the BBB
> and PB are rather slow, so maybe I should cross build this on one of my Pis?
> Or is there an alternitive kernel I can upgrade to that includes these
> modules?
>
> Right now my two Beagles are running 4.14.71-ti-r80, Debian GNU/Linux 9,
> BeagleBoard.org Debian Image 2018-10-07. I did do a apt-get update/apt-get
> dist-upgrade about a month ago (May 14).

it's enabled, just after r80 came out.. Just run, and then reboot..

sudo /opt/scripts/tools/update_kernel.sh

OK, Sounds like I need to take the Beagles to library (I have dialup Internet
at home). Thanks.

4

>
> OK, I have made use of the MCP23008 and MCP23017, 8 bit and 16 bit GPIO
> expanders that are I2C connected on Raspberry Pis. The Raspberry Pi kernels
> include both an overlay (Device Tree Blob) and a driver module for the
> MCP23008 and MCP23017 chips. I would also like to make use of these chips on
> my beagle boards (a BeagleBoneBlack and a PocketBeagle).
>
> I just did some poking around on my BBB, and there are neither Device Tree
> Blobs nor driver modules for the MCP23008 and MCP23017 chips.
>
> So, my question is: What is involved in building the missing driver modules
> and Device Tree Blobs -- I have built driver modules and even rebuilt whole
> kernels on x86 Linux boxen, so I have passing knowledge of how that goes, what
> I am really wondering: is there a repo with .deb files containing the "extra"
> ko files? Or tarballs containing the additional sources? I realize the BBB
> and PB are rather slow, so maybe I should cross build this on one of my Pis?
> Or is there an alternitive kernel I can upgrade to that includes these
> modules?
>
> Right now my two Beagles are running 4.14.71-ti-r80, Debian GNU/Linux 9,
> BeagleBoard.org Debian Image 2018-10-07. I did do a apt-get update/apt-get
> dist-upgrade about a month ago (May 14).

it's enabled, just after r80 came out.. Just run, and then reboot..

sudo /opt/scripts/tools/update_kernel.sh

OK, I did the above and did a apt-get dist-upgrade.

The kernel module is there, but there isn't a Device Tree Blob for the *I2C*
mcp23* chips, just a Device Tree Blob
(/lib/firmware/BB-SPI0-MCP23S08-00A0.dtbo) for the SPI interface.

During the kernel update the package linux-firmware-image-4.14.108-ti-r106 was
suggested, but apt-get install is complaining when I try to install it:

snoopy% sudo apt-get install linux-firmware-image-4.14.108-ti-r106
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package linux-firmware-image-4.14.108-ti-r106 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or is only available from another source

E: Package 'linux-firmware-image-4.14.108-ti-r106' has no installation candidate

I do have device tree blobs on the RPi and can get a device tree blob source
file from the RPi device tree source repo. I guess it is *possible* to
compile a device tree blob for the beagles, but want to be sure and would
rather get a device tree blob properly built for the Beagles.

5

> it's enabled, just after r80 came out.. Just run, and then reboot..
>
> sudo /opt/scripts/tools/update_kernel.sh

OK, I did the above and did a apt-get dist-upgrade.

The kernel module is there, but there isn't a Device Tree Blob for the *I2C*
mcp23* chips, just a Device Tree Blob
(/lib/firmware/BB-SPI0-MCP23S08-00A0.dtbo) for the SPI interface.

Sorry, i don't have all the hardware, please feel free to fork the
repo and submit a merge request:

During the kernel update the package linux-firmware-image-4.14.108-ti-r106 was
suggested, but apt-get install is complaining when I try to install it:

snoopy% sudo apt-get install linux-firmware-image-4.14.108-ti-r106
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package linux-firmware-image-4.14.108-ti-r106 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or is only available from another source

E: Package 'linux-firmware-image-4.14.108-ti-r106' has no installation candidate

The "firmware" packages is not needed for us, all the device firmware
is packaged in a separate deb package.

I do have device tree blobs on the RPi and can get a device tree blob source
file from the RPi device tree source repo. I guess it is *possible* to
compile a device tree blob for the beagles, but want to be sure and would
rather get a device tree blob properly built for the Beagles.

That can also be done:

Regards,

6

It’s not enabled in the bone kernels:

`

CONFIG_PINCTRL_MCP23S08 is not set

`

While I’m pointing some of this out, is there any way to get CONFIG_SND_DUMMY added to bone kernel as well as getting a few of the more readily available sound codecs added to both kernels? Probably the PCM512X, SGTL5000, and WM8960 as there are a bunch of hats/addons available on Amazon that have those.

Dan

7

It's not enabled in the bone kernels:

# CONFIG_PINCTRL_MCP23S08 is not set

In the updated kernel is is enabled.

8

I don’t see a bone kernel with it enabled, either 4.14 or 4.19:

config-4.14.108-ti-r104:CONFIG_PINCTRL_MCP23S08=m
config-4.14.109-bone21:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.14.115-bone22:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.31-bone31:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.37-bone33:# CONFIG_PINCTRL_MCP23S08 is not set

I believe the 115-bone22 and 37-bone33 are the latest on the two branches.

9

>
>> It's not enabled in the bone kernels:
>>
>>
>> # CONFIG_PINCTRL_MCP23S08 is not set
>
> In the updated kernel is is enabled.

I don't see a bone kernel with it enabled, either 4.14 or 4.19:

config-4.14.108-ti-r104:CONFIG_PINCTRL_MCP23S08=m

                          ^^^^^^^^^^^^^^^^^^^^^^^^^
                          It is in the 4.14.108 kernel.

config-4.14.109-bone21:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.14.115-bone22:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.31-bone31:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.37-bone33:# CONFIG_PINCTRL_MCP23S08 is not set
                          
I just did:

sudo /opt/scripts/tools/update_kernel.sh

and it updated to 4.14.108-ti-r106 by default:

snoopy% grep MCP23 /boot/config-4.14.*
/boot/config-4.14.108-ti-r106:CONFIG_PINCTRL_MCP23S08=m
/boot/config-4.14.71-ti-r80:# CONFIG_PINCTRL_MCP23S08 is not set
snoopy% uname -a
Linux snoopy 4.14.108-ti-r106 #1 SMP PREEMPT Fri May 24 22:12:34 UTC 2019
armv7l GNU/Linux
snoopy% dir /lib/modules/4.14.108-ti-r106/kernel/drivers/pinctrl/pinctrl-mcp23s08.ko.xz
/lib/modules/4.14.108-ti-r106/kernel/drivers/pinctrl/pinctrl-mcp23s08.ko.xz

I believe the 115-bone22 and 37-bone33 are the latest on the two branches.

Then someone needs to rebuild them... Maybe you can file a bug report or
feature request?

Just because the BBB has 128 on-board GPIO lines (obviously not all of them
are on the headers), does not mean one could not build a Cape with a MCP23017
for 16 more GPIO lines. To quote Billy Idle: "Too much is never enough." (from
an old MTV promo).

10

“bone kernel”

That’s important. The TI kernels are not usable for my application. I need to use the bone kernel. (At least for the 4.9 and 4.14 series… haven’t had time to test with the TI 4.19 series kernels)

My initial reply was to RobertCNelson’s response that it’s enabled in the newer kernels to point out that it’s not enabled in ALL the newer kernels, just the “ti” channel kernels.

I’ve been playing around with a pcf8574 i2c gpio expander as that module is available in the bone kernel. The main problem with the pcf8574 is it only supports the 100khz i2c speed which sucks when you also have an i2c OLED on the bus. Updating to 400khz is important with that thing. Your mention of the MCP23008 is very timely as I was just beginning to start looking at other options. Just kind of hoping that future bone kernels would have the driver built in. Would be a big help if I don’t have to rebuild kernels.

11

>>>
>>>> It's not enabled in the bone kernels:
>>>>
>>>>
>>>> # CONFIG_PINCTRL_MCP23S08 is not set
>>>
>>> In the updated kernel is is enabled.
>>
>> I don't see a bone kernel with it enabled, either 4.14 or 4.19:

“bone kernel”

That’s important. The TI kernels are not usable for my application. I need to use the bone kernel. (At least for the 4.9 and 4.14 series… haven’t had time to test with the TI 4.19 series kernels)

Ah. I see. What sorts of differences are there between the TI kernels and
the Bone kernels? Is there some reason the Bone don't have the MCP23S08
module enabled? Wondering if a bug/feature request might make sense...

12

Honestly, I have no idea what the “official” differences are and why some modules are available in one and not the other. Likely just someone requested something. At some point, a “diff” of the configs and unifying the optional modules of it may make sense, not really sure.

In my particular case, I believe the power management stuff that is in the TI kernel is screwing up the timing to access anything in the L4_WKUP interconnect (which includes GPIO0). For folks that value the power management stuff, the TI kernel is much better. It contains the cpu IDLE driver and a bunch of other things that allow it to lower the power usage. In my case, I don’t care about any of that. Even with the bone kernel, I lock the CPU at 1ghz. I need more predictable and consistent access to the gpio pins (all of them). With the TI kernel, access to GPIO1-3 (via the PRU) is very consistent, but access to GPIO0 can have several hundred ns delays which I cannot have (relatively infrequent, once or twice a second, but still too often). I KNOW the CPU idle stuff in the TI kernel plays a large part of the problem. If I use cpupower to turn off the idle states, 90% of the delays go away (so once every 10 seconds or so). Anyway, the bone kernel doesn’t have a bunch of the PM things so I don’t see any of the issues with it. Of course, it might not be PM at all. Could be something else completely different between the kernels.

13

“bone kernel”

That’s important. The TI kernels are not usable for my application. I need to use the bone kernel. (At least for the 4.9 and 4.14 series… haven’t had time to test with the TI 4.19 series kernels)

Ah. I see. What sorts of differences are there between the TI kernels and
the Bone kernels? Is there some reason the Bone don't have the MCP23S08
module enabled? Wondering if a bug/feature request might make sense…

Just added..

Honestly, I have no idea what the “official” differences are and why some modules are available in one and not the other. Likely just someone requested something. At some point, a “diff” of the configs and unifying the optional modules of it may make sense, not really sure.

They've just evolved differently, from the same 3.8.x-bone base..
keeping them in-sync has been...<fun>.... The bone series goes thru
every kernel release, and i like to merge the good stuff back into the
-ti kernel, which it self has to deal with ti modules that don't like
optimizations (thumb2)

3.8.x-bone -> 3.9.x-bone -> ...... -> 4.9.x-bone -> ..... ->
4.14.x-bone -> ... 4.19.x-bone -> 4.20.x-bone...
     -> 3.14.x-ti -> 4.1.x-ti -> 4.4.x-ti -> 4.9.x-ti -> 4.14.x-ti -> 4.19.x-ti

In my particular case, I *believe* the power management stuff that is in the TI kernel is screwing up the timing to access anything in the L4_WKUP interconnect (which includes GPIO0). For folks that value the power management stuff, the TI kernel is much better. It contains the cpu IDLE driver and a bunch of other things that allow it to lower the power usage. In my case, I don’t care about any of that. Even with the bone kernel, I lock the CPU at 1ghz. I need more predictable and consistent access to the gpio pins (all of them). With the TI kernel, access to GPIO1-3 (via the PRU) is very consistent, but access to GPIO0 can have several hundred ns delays which I cannot have (relatively infrequent, once or twice a second, but still too often). I KNOW the CPU idle stuff in the TI kernel plays a large part of the problem. If I use cpupower to turn off the idle states, 90% of the delays go away (so once every 10 seconds or so). Anyway, the bone kernel doesn’t have a bunch of the PM things so I don’t see any of the issues with it. Of course, it might not be PM at all. Could be something else completely different between the kernels.

Regards,