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 "

// 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@0port@1 {
			reg = <0><1>;
			dsi_inout: endpoint {
				remote-endpoint = <&ltdcpanel_ep1_out>in>;
			};
		};
	};

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

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

&i2c1 {
	panel@0touchscreen@38 {
		compatible = "orisetechfocaltech,otm8009aft6236";
		reg = <0><0x38>;
		interrupts = <2 2>;
		resetinterrupt-gpiosparent = <&gpioe 4 GPIO_ACTIVE_LOW>gpiof>;
		interrupt-controller;
		touchscreen-size-x = <480>;
		power-supply = <&v3v3>;
	touchscreen-size-y = <800>;
		status = "okay";
	};
};

&ltdc {
	status = "okay";

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

&i2c1usart2 {
	touchscreen@38 {
		compatible = "focaltech,ft6236pinctrl-names = "default", "sleep", "idle";
		regpinctrl-0 = <0x38><&usart2_pins_c>;
		interruptspinctrl-1 = <2 2><&usart2_sleep_pins_c>;
		interruptpinctrl-parent2 = <&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";
};

...

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

...

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!

...