See original article by Thomas Petazzoni at bootlin.com

Enabling the I2C bus

An introduction to the Device Tree

In order to enable the I2C bus, we’ll need to modify the Device Tree, so we’ll first need to give a few details about what Device Tree is. If you read again our previous blog post in this series, we already mentioned the Device Tree. As part of the Buildroot build process, a file called stm32mp157c-dk2.dtb is produced, and this file is used at boot time by the Linux kernel: it is the Device Tree.

On most embedded architectures, devices are connected using buses that do not provide any dynamic enumeration capabilities. While buses like USB or PCI provide such capabilities, popular buses used on embedded architectures like memory-mapped buses, I2C, SPI and several others do not allow the operating system to ask the hardware: what peripherals are connected ? what are their characteristics ?. The operating system needs to know which devices are available and what their characteristics are. This is where the Device Tree comes into play: it is a data structure that describes in the form of a tree all the devices that we have in our hardware platform, so that the Linux kernel knows the topology of the hardware.

On ARM platforms, each particular board is described by its own Device Tree file. In our case, the STM32MP157 Discovery Kit 2 is described by the Device Tree file arch/arm/boot/dts/stm32mp157c-dk2.dts in the Linux kernel source code. This human-readable source file, with a .dts extension, is compiled during the Linux kernel build process into a machine-readable binary file, with a .dtb extension.

...

Important - Preparing Buildroot

For this tutorial to work as outlined in the text below we need to set up a new copy of buildroot and switch to a specific earlier version buildroot it. There's 
a strong dependence between buildroot, the linux kernel and kernel additions and modifications by ST Microelectronics. On top there's also 
a dependency regarding the build tools involved (gcc in particular) on the build host. In case of the current version of Lab Assignment 3 we need
a gcc version not newer than nine (gcc-9). Otherwise we'll run into problems when buildroot tries to compile the device tree parser.

• make sure your on a host with gcc-9 compiler (eda1, zaphod)
• consider using multiple host / spreading across servers - the build process will take a lot of time
• zaphod is faster than eda1 and has more memory

Create a new directory and clone the buildroot repository and switch to version 2020.05.3:

mkdir lab3
cd lab3
git clone git://git.buildroot.net/buildroot
cd buildroot
git checkout -b bme280 2020.05.3
make stm32mp157c_dk2_defconfig
make menuconfig
make

Enabling the I2C bus

An introduction to the Device Tree

In order to enable the I2C bus, we’ll need to modify the Device Tree, so we’ll first need to give a few details about what Device Tree is. If you read again our previous blog post in this series, we already mentioned the Device Tree. As part of the Buildroot build process, a file called stm32mp157c-dk2.dtb is produced, and this file is used at boot time by the Linux kernel: it is the Device Tree.

On most embedded architectures, devices are connected using buses that do not provide any dynamic enumeration capabilities. While buses like USB or PCI provide such capabilities, popular buses used on embedded architectures like memory-mapped buses, I2C, SPI and several others do not allow the operating system to ask the hardware: what peripherals are connected ? what are their characteristics ?. The operating system needs to know which devices are available and what their characteristics are. This is where the Device Tree comes into play: it is a data structure that describes in the form of a tree all the devices that we have in our hardware platform, so that the Linux kernel knows the topology of the hardware.

On ARM platforms, each particular board is described by its own Device Tree file. In our case, the STM32MP157 Discovery Kit 2 is described by the Device Tree file arch/arm/boot/dts/stm32mp157c-dk2.dts in the Linux kernel source code. This human-readable source file, with a .dts extension, is compiled during the Linux kernel build process into a machine-readable binary file, with a .dtb extension.

// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
/*
 * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
 * Author: Alexandre Torgue <alexandre.torgue@st.com> for STMicroelectronics.
 */

/dts-v1/;

#include "stm32mp157.dtsi"
#include "stm32mp15xc.dtsi"
#include "stm32mp15-pinctrl.dtsi"
#include "stm32mp15xxac-pinctrl.dtsi"
#include "stm32mp15xx-dkx.dtsi"

/ {
	model = "STMicroelectronics STM32MP157C-DK2 Discovery Board";
	compatible = "st,stm32mp157c-dk2", "st,stm32mp157";

	aliases {
		ethernet0 = ðernet0;
		serial0 = &uart4;
		serial1 = &usart3;
		serial2 = &uart7;
		serial3 = &usart2;
	};

	chosen {
		stdout-path = "serial0:115200n8";
	};
};

&cryp1 {
	status = "okay";
};

&dsi {
	status = "okay";
	phy-dsi-supply = <&reg18>;

	ports {
		port@0 {
			reg = <0>;
			dsi_in: endpoint {
				remote-endpoint = <&ltdc_ep1_out>;
			};
		};

		port@1 {
			reg = <1>;
			dsi_out: endpoint {
				remote-endpoint = <&panel_in>;
			};
		};
	};

	panel@0 {
		compatible = "orisetech,otm8009a";
		reg = <0>;
		reset-gpios = <&gpioe 4 GPIO_ACTIVE_LOW>;
		power-supply = <&v3v3>;
		status = "okay";

		port {
			panel_in: endpoint {
				remote-endpoint = <&dsi_out>;
			};
		};
	};
};

&i2c1 {
	touchscreen@38 {
		compatible = "focaltech,ft6236";
		reg = <0x38>;
		interrupts = <2 2>;
		interrupt-parent = <&gpiof>;
		interrupt-controller;
		touchscreen-size-x = <480>;
		touchscreen-size-y = <800>;
		status = "okay";
	};
};

&ltdc {
	status = "okay";

	port {
		ltdc_ep1_out: endpoint@1 {
			reg = <1>;
			remote-endpoint = <&dsi_in>;
		};
	};
};

&usart2 {
	pinctrl-names = "default", "sleep", "idle";
	pinctrl-0 = <&usart2_pins_c>;
	pinctrl-1 = <&usart2_sleep_pins_c>;
	pinctrl-2 = <&usart2_idle_pins_c>;
	status = "disabled";
};

This stm32mp157c-dk2.dts describes the hardware of our Discovery Kit 2 platform. In fact, it only describes what is specific to the Discovery Kit 2: the display panel, the touchscreen, the WiFi and Bluetooth chip. Everything else is common with the Discovery Kit 1 platform, which is why the stm32mp157c-dk2.dts file includes the arm/boot/dts/stm32mp157a-dk1.dts file. Indeed, stm32mp157a-dk1.dts describes the hardware on the Discovery Kit 1, which is the same as the Discovery Kit 2, without the display, touchscreen and WiFi/Bluetooth chip.

// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
/*
 * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
 * Author: Alexandre Torgue <alexandre.torgue@st.com> for STMicroelectronics.
 */

/dts-v1/;

#include "stm32mp157.dtsi"
#include "stm32mp15-pinctrl.dtsi"
#include "stm32mp15xxac-pinctrl.dtsi"
#include "stm32mp15xx-dkx.dtsi"

/ {
	model = "STMicroelectronics STM32MP157A-DK1 Discovery Board";
	compatible = "st,stm32mp157a-dk1", "st,stm32mp157";

	aliases {
		ethernet0 = ðernet0;
		serial0 = &uart4;
		serial1 = &usart3;
		serial2 = &uart7;
	};

	chosen {
		stdout-path = "serial0:115200n8";
	};
};

In turn, the stm32mp157a-dk1.dts includes three other Device Tree files:

• arm/boot/dts/stm32mp157c.dtsi, which describes all the devices inside the STM32MP157 system-on-chip. It will be used by all Device Tree files describing boards based on the STM32MP157 processor.
• arm/boot/dts/stm32mp157c-m4-srm.dtsi, which describes the Cortex-M4 resources, which we are not going to discuss further for the moment
• arm/boot/dts/stm32mp157cac-pinctrl.dtsi, which provides some pin-muxing related details, which are specific to the SoC package being used.

At this point, we won’t give much more generic details about the Device Tree, as it’s an entire topic on its own. For additional details, you could check the Device Tree for Dummies presentation from your author (slides, video) or the devicetree.org web site.

I2C controllers in the Device Tree

Zooming in to the topic of I2C, we can see that arm/boot/dts/stm32mp157c.dtsi describes 6 I2C controllers through six different nodes in the Device Tree:

...

For now, this doesn’t describe any device on the bus, but should be sufficient to have the bus enabled in Linux. The question now is how to make this modification in our Device Tree in the proper way ?

Changing the Linux kernel source code

When Buildroot builds each package, it extracts its source code in output/build/<package>-<version>, so the source code of our Linux kernel has been extracted in output/build/linux-custom/. One could therefore be tempted to make his code changes directory in output/build/linux-custom/, but this has a number of major drawbacks:

...

At this point, our linux/ folder contains the exact same source code as what Buildroot has retrieved. It is time to make our Device Tree change by editing arch/arm/boot/dts/stm32mp157c-dk2.dtsdts and at the end of it, add:

...

If you look closely at what Buildroot will do, it will do a rsync of the Linux kernel source code from your linux/ Git repository to output/build/linux-custom in Buildroot, and then do the build. You can check output/build/linux-custom/arch/arm/boot/dts/stm32mp157c-dk2.dtsto make sure that your I2C5 change is there!

If that is the case, then reflash output/images/sdcard.img on your SD card, and run the new system on the board. It’s now time to test the I2C bus!

Testing the I2C bus

After booting the new system on your Discovery board and logging in as root, let’s have a look at all I2C related devices:

...

Good, this matches the expected value according to the BME280 datasheet, so it seems like communication with our I2C device is working, let’s move on to enabling the BME280 sensor driver.

Enabling the sensor driver

As discussed earlier, this BME280 sensor already has a driver in the upstream Linux kernel, in the IIO subsystem. IIO stands for Industrial Input/Output, and this subsystems contains a lot of drivers for various ADCs, sensors and other types of measurement/acquisition devices. In order to use this driver for our BME280 device, we will essentially have to do two things:

1. Enable the driver in our Linux kernel configuration, so that the driver code gets built as part of our kernel image
2. Describe the BME280 device in our Device Tree so that the Linux kernel knows we have one such device, and how it is connected to the system

Adjusting the kernel configuration

In the previous blog post, we explained that the Linux kernel configuration used to build the kernel for the STM32 Discovery board was located at board/stmicroelectronics/stm32mp157-dk/linux.config. Obviously, we are not going to edit this file manually: we need to run the standard Linux kernel configuration tools.

...

We’re all set for the kernel configuration!

Describing the BME280 in the Device Tree

We now need to tell the Linux kernel that we have a BME280 sensor and how it is connected to the system, which is done by adding more details into our Device Tree. We have already enabled the I2C5 bus, and we now need to describe one device connected to it: this gets done by creating a child node of the I2C controller node.

...

&i2c5 {
	status = "okay";
	clock-frequency = <100000>;
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&i2c5_pins_a>;
	pinctrl-1 = <&i2c5_pins_sleep_a>;

	pressure@76 {
		compatible = "bosch,bme280";
		reg = <0x76>;
	};
};

Re-building the kernel

Let’s now ask Buildroot to rebuild the Linux kernel, with our Device Tree change and kernel configuration change. Instead of rebuilding from scratch, we’ll just ask Buildroot to restart the build of the Linux kernel, which will be much faster:

...

To regenerate the SD card image, write it on your SD card, and boot your system.

Testing the sensor

After booting the system, if we check /sys/bus/i2c/devices, a new entry has appeared:

...