Easier Embedded Linux learning experience with PinMux

I recently had the chance to participate in a workshop on Kernel Drivers given
by my colleague Arnout Vandecappelle. We used the BeagleBone Black board for practical exercices. Something that I experienced myself in the past is that newcomer to the Embedded Linux world can struggle with Device Tree definition.

In all honesty, it makes sense. Just for pin muxing there are a multitude of ways to define the same function. The following definition

&am33xx_pinmux {
    spi0_pins: spi0_pins {
        pinctrl-single,pins = <
            0x150 0x30
            0x154 0x30
            0x158 0x10
            0x15c 0x10
        >;
    };
};

Is the same as the next definition.

&am33xx_pinmux {
    spi0_pins: spi0_pins {
        pinctrl-single,pins = < AM33XX_IOPAD(0x950, PIN_OUTPUT_PULLUP | MUX_MODE0); /* SPI0_SCLK */ AM33XX_IOPAD(0x954, PIN_OUTPUT_PULLUP | MUX_MODE0); /* SPI0_D0 */ AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | MUX_MODE0); /* SPI0_D1 */ AM33XX_IOPAD(0x95c, PIN_INPUT_PULLUP | MUX_MODE0); /* SPI0_CS */ >;
    };
};

To make it worse, the directives to use are different for different SoC families. The above example is clearly specific for the TI AM33XX family.

Of course, you can see in include/dt-bindings/pinctrl/omap.h that AM33XX_IOPAD just subtracts the 0x800 offset from the first argument of AM33XX_IOPAD. But a newcomer who just wants to play a bit with Linux will Google something like “How to enable an SPI bus on a BeagleBone” and see different blog posts with different answers, which makes it really confusing.

Inspired by tools such as pinout.xyz or vendor specific ones (TI PinMux),
I thought I could implement a better solution for the BeagleBone platform that would solve the need to verify the information on multiple charts and tables to define the board pin mode. That small project is available on pinmux.mind.be and its AGPL-3.0 licensed source is on our github.

So what now ? The framework to support different board definitions is already written. Currently only the BeagleBone Black has been implemented, but it’s possible to add different boards or SoCs. All we need to do is start writing them. Supporting Zephyr Device Tree could also be on the roadmap.