i.MX 6ULL Based Modules

Both versions of the Colibri iMX6ULL modules (256MB without Wi-Fi and 512MB with Wi-Fi) share the same SoC-level device tree file (imx6ull.dtsi) and there are dedicated files to each module.

Pinmux (iMX6ULL)

The i.MX 6ULL SoC allows multiplexing pins through its Input/Output Multiplexer Controller (IOMUXC). Beside multiplexing pins, this controller allows also to set pin configuration such drive strength. There are two largely independent controllers: the IOMUXC and the IOMUXC LPSR (low-power pin controller). The SoC level device trees define the driver node for each of this controller which bind to the pinctrl-imx6ul driver and defines the labels iomuxc and iomuxc_lpsr to give lower-level device tree access to the node.

To configure a pin, a device tree node inside the pin controller node with the property fsl,pins is required. Cells need to be assigned to the property, each pin requires 5 cells. However, the first four are usually given by a pre-processor macro (see arch/arm/boot/dts/imx6ull-pinfunc.h or arch/arm/boot/dts/imx6ull-pinfunc-lpsr.h respectively), only the last cell need to be provided. This last cell contains the pin settings in a hexadecimal notation. Additionally, the last cell's bit 30 is used to give the setting of the SION bit, bit 31 prevents the iomuxc from changing the pad control register (see here for details). Since i.MX 6ULL SoC shares pin assignments with the i.MX 6UL SoC, various pin assignments for both processors are in the file arch/arm/boot/dts/imx6ul-pinfunc.h, which is included to arch/arm/boot/dts/imx6ull-pinfunc.h.

&iomuxc {
...
    pinctrl_can_int: canintgrp {
        fsl,pins = <
            MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04    0x13010 /* SODIMM 73 */
        >;
    };
...
};

The bitwise definition for the last cell is given by the PAD Control Registers of the i.MX 6ULL Input/Output Multiplexer Controller.

For further details see Chapter 4 of the Toradex Colibri iMX6ULL datasheet or/and Chapters 4 and 32 of the NXP^®/Freescale i.MX 6ULL application processor reference manual.

i.MX 7 Based Modules

The modules Colibri iMX7S/iMX7D use independent device tree binaries, but due to the high intersection, most of the logic is in shared device tree source files.

Pinmux (iMX7)

The i.MX 7 SoC allows multiplexing pins through its Input/Output Multiplexer Controller (IOMUXC). Beside multiplexing pins, this controller allows also to set pin configuration such drive strength. There are two largely independent controllers: the IOMUXC and the IOMUXC LPSR (low-power pin controller). The SoC level device trees define the driver node for each of this controller which bind to the pinctrl-imx7 driver and defines the labels iomuxc and iomuxc_lpsr to give lower-level device tree access to the node.

To configure a pin, a device tree node inside the pin controller node with the property fsl, pins is required. Cells need to be assigned to the property, each pin requires 5 cells. However, the first four are usually given by a pre-processor macro (see arch/arm/boot/dts/imx7d-pinfunc.h or arch/arm/boot/dts/imx7d-pinfunc-lpsr.h respectively), only the last cell need to be provided. This last cell contains the pin settings in a hexadecimal notation. Additionally, the last cell's bit 30 is used to give the setting of the SION bit, bit 31 prevents the iomuxc from changing the pad control register (see here for details).

&iomuxc {
...
    pinctrl_can_int: canintgrp {
        fsl,pins = <
            MX7D_PAD_SD1_RESET_B__GPIO5_IO2     0x14 /* SODIMM 73 */
        >;
    };
...
};

The bitwise definition for the last cell is given by the PAD Control Registers of the i.MX 7 Input/Output Multiplexer Controller.

For further details see Chapter 4 of the Toradex Colibri iMX7 datasheet or/and Chapter 8 of the NXP^®/Freescale i.MX 7 application processor reference manual.

i.MX 8 Family Based Modules

Pinmux (i.MX 8 Family Based Modules)

The i.MX 8 family SoCs allow multiplexing pins through its Input/Output Multiplexer Controller (IOMUXD). Beside multiplexing pins, this controller allows setting pin configuration such as drive strength. The SoC level device trees define the driver node for this controller.

All pinmuxing/drive strength etc. is controlled in the System Controller Unit, a dedicated M-Core running the System Controller Firmware (SCFW). Linux's IOMUXC driver has no direct access to IOMUXC registers but uses the SCU driver to communicate with its firmware (SCFW).

To configure a pin, a device tree node inside the pin controller node with the property fsl,pins is required. Integers need to be assigned to the property, each pin requires 3 integers. However, the first two are usually given by a #define (see include/dt-bindings/pinctrl/pads-imx8qm.h). With this define the SoC pin and its desired function is specified. In the example down below for example the pin FLEXCAN0_TX is muxed to the function DMA_FLEXCAN0_TX.

The third integer then defines the pin settings in hexadecimal notation. On the example below 0x21 means that Bit 0 and Bit 5 is set. Bit 0 sets high or low drive strength in this example with 1 meaning low drive strength. With Bit 6-5 the pull-up or pull-down behaviour is controlled with '01' meaning pull-up.

For a detailed description and table of possible pin-settings, look them up in the Reference Manual for the i.MX 8 family. At the time of writing this, the chapter for FLEXCAN0_TX pin settings was located at chapter 9.2.5.1.160.4

The possible muxings can be found in chapter 4 in the datasheet or with our Pinout Designer pinout.torizon.io.

Note: The meaning of these bits depends on the pin and has to be looked up for every pin in the Reference Manual. Thus we can not give a table here.

&iomuxc {
...
        apalis-imx8qm {
                pinctrl_flexcan1: flexcan0grp {
                        fsl,pins = <
                                IMX8QM_FLEXCAN0_TX_DMA_FLEXCAN0_TX              0x21
                                IMX8QM_FLEXCAN0_RX_DMA_FLEXCAN0_RX              0x21
                        >;
                };
        };
...
};

i.MX 8X Based Modules

• 

  iMX8X Modules

Pinmux (i.MX 8X Based modules)

The i.MX 8X SoC allows multiplexing pins through its Input/Output Multiplexer Controller (IOMUXD). Beside multiplexing pins, this controller allows setting pin configuration such as drive strength. The SoC level device trees define the driver node for this controller.

All pinmuxing/drive strength etc. is controlled in the System Controller Unit, a dedicated M-Core running the System Controller Firmware (SCFW). Linux's IOMUXC driver has no direct access to IOMUXC registers but uses the SCU driver to communicate with its firmware (SCFW).

To configure a pin, a device tree node inside the pin controller node with the property fsl,pins is required. Integers need to be assigned to the property, each pin requires 3 integers. However, the first two are usually given by a #define (see include/dt-bindings/pinctrl/pads-imx8qxp.h). With this define the SoC pin and its desired function is specified. In the example down below for example the pin FLEXCAN0_TX is muxed to the function DMA_FLEXCAN0_TX.

The third integer then defines the pin settings in hexadecimal notation. On the example below 0x21 means that Bit 0 and Bit 5 is set. Bit 0 sets high or low drive strength in this example with 1 meaning low drive strength. With Bit 6-5 the pull-up or pull-down behaviour is controlled with '01' meaning pull-up.

For a detailed description and table of possible pin-settings, look them up in the Reference Manual for i.MX 8X. At the time of writing this, the chapter for FLEXCAN0_TX pin settings was located at chapter 9.2.5.1.115.4.

The possible muxings can be found in chapter 4 in the datasheet or with our Pinout Designer pinout.torizon.io.

Note: The meaning of these bits depends on the pin and has to be looked up for every pin in the Reference Manual. Thus we can not give a table here.

&iomuxc {
...
        colibri-imx8qxp {
                pinctrl_flexcan1: flexcan0grp {
                        fsl,pins = <
                                IMX8QXP_FLEXCAN0_TX_ADMA_FLEXCAN0_TX            0x21
                                IMX8QXP_FLEXCAN0_RX_ADMA_FLEXCAN0_RX            0x21
                        >;
                };
        };
...
};

i.MX 8M Mini Based Modules

• 

  i.MX 8M Mini Modules

Pinmux (i.MX 8M Mini Based modules)

The i.MX 8M Mini SoC allows multiplexing pins through its Input/Output Multiplexer Controller (IOMUXD). Beside multiplexing pins, this controller allows setting pin configuration such as drive strength.

To configure a pin, a device tree node inside the pin controller node with the property fsl,pins is required. Integers need to be assigned to the property, each pin requires 6 integers. However, the first 5 are usually given by a #define (see arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h). With this define the SoC pin and its desired function is specified. In the example down below, for example, the pin GPIO1_IO06 is muxed to the function GPIO1_IO06 (Which is pretty obvious but GPIO1_IO06 could also be muxed to USDHC1_CD_B with the define MX8MM_IOMUXC_GPIO1_IO06_USDHC1_CD_B for example).

The third integer then defines the pin settings in hexadecimal notation. On the example below 0x1c4 means that Bit 2, 6, 7 and Bit 8 are set. With Bit 0-2 one can set the drive strength. In this example, only Bit 2 is set which is meaning drive strength X2. Bit 6 means "Select pull-up resistors", Bit 7 "Select Schmitt input" and Bit 8 "Enable pull resistors".

For a detailed description and table of possible pin-settings, look them up in the Reference Manual. At the time of writing this, the chapter for PAD_GPIO1_IO06 pin settings was located at chapter 8.2.5.166.

The possible muxings can be found in chapter 4 in the datasheet or with our Pinout Designer pinout.torizon.io.

&iomuxc {
...
        pinctrl_can1_int: can1intgrp {
                fsl,pins = <
                        MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6        0x1c4
                >;
        };
...
};

Vybrid Based Modules

The device tree files for the Colibri VF50/VF61 modules are quite similar, hence the common device tree nodes have been factored out to vf-colibri.dtsi and vf-colibri-eval-v3.dtsi. Click on the box to see the current version of the respective device tree file.

A device tree for a custom carrier board can also implement this extra dtsi for the common nodes between Colibri VF50/VF61. If the carrier board will only use Colibri VF50 or only Colibri VF61 anyway, the nodes of the common device tree file (vf-colibri-eval-v3.dtsi) can also be included in the main carrier board device tree (e.g. vf500-colibri-eval-v3.dts).

The Vybrid default boot scripts in U-Boot load the device tree file by combining multiple environment variables: ${soc}-colibri-${fdt_board}.dtb. The soc environment variable is detected according to the module type the boot loader runs on (vf500/vf610). The fdt_board is a static environment variable set to eval-v3 by default. If you provide your own carrier board device tree, you can make use of this environment variable to select the correct device tree:

setenv fdt_board mycarrier
saveenv

Pinmux (Vybrid)

Pin configurations such as pinmux or drive strength settings are defined by the pinctrl-vf610 driver. The base device tree vfxxx.dtsi defines the base configuration and allows these entries to be extended through the iomuxc label.

To configure a pin, a device tree node inside the pin controller node with the property fsl,pins is required. Cells need to be assigned to the property, each pin requires 5 cells. However, the first four are usually given by a pre-processor macro (see arch/arm/boot/dts/vf610-pinfunc.h), only the last cell needs to be provided. This last cell contains the pin settings in a hexadecimal notation.

pinctrl_additionalgpio: additionalgpios {
    fsl,pins = <
        VF610_PAD_PTA17__GPIO_7     0x22ed
    >;
};

The bitwise definition for the last cell is given by the registers of Vybrids Input/Output Multiplexer Controller. Refer to the following table for their meaning:

For further details see Chapter 4.2 of the Colibri VFxx datasheet or/and Chapter 6 of the NXP^®/Freescale Vybrid reference manual.

GPIO (Vybrid)

On Vybrid almost all pins can be used as a GPIO. To be able to use a pin as a GPIO, a valid GPIO pinmux must be present in the device tree. Our default device tree contains such a pinmux entry for all pins which are defined as being a GPIO by default (refer to the datasheet). For the other pins, make sure no driver is requesting them and create a proper pinmux configuration according to the Pinmux chapter.

There are 5 GPIO ports on Vybrid, represented by the node references gpio0 through gpio4. Each of which can address up to 32 GPIOs. Which GPIO port is used is defined by the GPIO node reference, the GPIO number within the port is the first cell. The assignment of the to Colibri pins to the GPIO blocks/numbers can be found in the Colibri VFxx Datasheet, Chapter 4.4 List Functions, GPIO port column. The GPIO polarity cell needs to be chosen according to the drivers/electronics needs. There are also preprocessor macros which can be used instead of the numbers (GPIO_ACTIVE_HIGH/GPIO_ACTIVE_LOW).

E.g. to reference the pin Colibri SO-DIMM 133 (according to the Colibri VFxx Datasheet connected to Vybrids PORT2[24]) one needs to use this GPIO specification:

gpios = <&gpio2 24 GPIO_ACTIVE_HIGH>

Note: Vybrid starts counting its GPIO banks with 0, hence the first bank is available under the label gpio0.

User-space

To use a SO-DIMM as GPIO using the sysfs interface (see GPIO (Linux)), a valid pinmux configuration is required. Most GPIOs have a valid configuration in the vf-colibri.dtsi device tree under the node additionalgpios.

If there is no pinmux for the pin in question, the sysfs layer will respond with a "Invalid argument" error:

# echo 0 > /sys/class/gpio/export
-sh: echo: write error: Invalid argument

In this case, add a Pinmux entry as described above.

In case the pin is already in use by a different driver, the error code would be "Device or resource busy".

# echo 42 > /sys/class/gpio/export
-sh: echo: write error: Device or resource busy

Make sure the SO-DIMM pin in question is not in use by any driver. In case a driver is referencing it, you can disable the driver.