Device Tree 101 Device Tree 101 Organized in partnership with ST February 9, 2021 Thomas Petazzoni embedded Linux and kernel engineering [email protected] © Copyright 2004-2021, Bootlin. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome! - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/56 Who is speaking ? I Thomas Petazzoni I Chief Technical Officer at Bootlin I Joined in 2008, employee #1 I Embedded Linux & Linux kernel engineer, open-source contributor I Author of the Device Tree for Dummies talk in 2013/2014 I Buildroot co-maintainer I Linux kernel contributor: ≈ 900 contributions I Member of Embedded Linux Conference (Europe) program committee I Based in Toulouse, France - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/56 Agenda I Bootlin introduction I STM32MP1 introduction I Why the Device Tree ? I Basic Device Tree syntax I Device Tree inheritance I Device Tree specifications and bindings I Device Tree and Linux kernel drivers I Common properties and examples - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/56 Bootlin I In business since 2004 I Team based in France I Serving customers worldwide I 18% revenue from France I 44% revenue from EU except France I 38% revenue outside EU I Highly focused and recognized expertise I Embedded Linux I Linux kernel I Embedded Linux build systems I Activities I Training courses (≃ 20% revenue) I Engineering services (≃ 80% revenue) - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 4/56 Bootlin training courses - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 5/56 I Experienced trainers I Bootlin trainers are also engineers I Working on real engineering projects I Up-to-date and in-field experience I Worldwide recognized training courses I Taught 100s of sessions I To 1000s of engineers I For the past 15 years Why choose Bootlin training courses ? I Complete training materials freely available I Open-source license: Creative Commons I Allows to verify in detail the course contents I Shows Bootlin commitment to knowledge sharing I Unique in the training industry - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 6/56 I Worldwide recognized training courses I Taught 100s of sessions I To 1000s of engineers I For the past 15 years Why choose Bootlin training courses ? I Complete training materials freely available I Open-source license: Creative Commons I Allows to verify in detail the course contents I Shows Bootlin commitment to knowledge sharing I Unique in the training industry I Experienced trainers I Bootlin trainers are also engineers I Working on real engineering projects I Up-to-date and in-field experience - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 6/56 Why choose Bootlin training courses ? I Complete training materials freely available I Open-source license: Creative Commons I Allows to verify in detail the course contents I Shows Bootlin commitment to knowledge sharing I Unique in the training industry I Experienced trainers I Bootlin trainers are also engineers I Working on real engineering projects I Up-to-date and in-field experience I Worldwide recognized training courses I Taught 100s of sessions I To 1000s of engineers I For the past 15 years - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 6/56 Bootlin engineering services I Main activities I Linux Board Support Package development, update and maintenance I Linux kernel drivers development I Bootloader and Linux kernel porting I System integration: Yocto, Buildroot, boot time, secure boot, etc. I Upstreaming I Consulting and technical support I Focus on the low-level software stack I Customers I Silicon vendors: interested in U-Boot, Linux, Buildroot or Yocto support for their product, usually upstream I Embedded system manufacturers: complete BSP, specific drivers, debugging, optimization, consulting - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/56 Bootlin: open-source contributor I Bootlin 20th contributing company worldwide to the Linux kernel I 7600+ patches contributed, mainly around hardware support I Maintainers of several subsystems of the kernel: I3C, RTC, MTD, and several platforms I Key contributor to Buildroot: co-maintainer, 5000+ patches contributed I Contributor to the Yocto Project I Contributions to Barebox, Linux Test Project, etc. I Freely available training materials I Numerous talks at conferences to share technical knowledge - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 8/56 STM32MP157F system-on-chip - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 9/56 STM32MP1 system-on-chip family - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 10/56 STM32MP1 Discovery Kits I Discovery Kit 1 (DK1) I Discovery Kit 2 (DK2) I SoC: STM32MP157A I SoC: STM32MP157C I 512 MB DDR, microSD I Same as DK1 I 1G Ethernet, 1x USB-C, 4x USB-A, LEDs, I WiFi/Bluetooth buttons I Display + touchscreen I HDMI, audio codec, DSI connector I GPIO connectors, Arduino/RaspberryPi shields I On-board ST-Link - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 11/56 STM32MP1 DK2 partial block diagram - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 12/56 I But many hardware busses do not provide discoverability mechanisms I E.g: I2C, SPI, 1-wire, memory-mapped, etc. I One needs to know what is connected on those busses, and how they are connected to the rest of the system I Embedded systems typically make extensive use of such busses Discoverable vs. non-discoverable hardware I Some hardware busses provide discoverability mechanisms I E.g: PCI(e), USB I One does not need to know ahead of time what will be connected on these busses I Devices can be enumerated and identified at runtime I Concept of vendor ID, product ID, device class, etc. - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 13/56 Discoverable vs. non-discoverable hardware I Some hardware busses provide discoverability mechanisms I E.g: PCI(e), USB I One does not need to know ahead of time what will be connected on these busses I Devices can be enumerated and identified at runtime I Concept of vendor ID, product ID, device class, etc. I But many hardware busses do not provide discoverability mechanisms I E.g: I2C, SPI, 1-wire, memory-mapped, etc. I One needs to know what is connected on those busses, and how they are connected to the rest of the system I Embedded systems typically make extensive use of such busses - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 13/56 Hardware description for non-discoverable hardware Allows the operating system or bootloader to know things like: I This system-on-chip has: I 2 Cortex-A7 CPU cores I 2 memory-mapped UART controllers of this variant, one with registers at 0x5c000000 and IRQ 37, and another with registers at 0x4000e000 and IRQ 38 I 3 I2C controllers of that variant, with registers at those memory-mapped addresses, those IRQs and taking their input clock from this source I This board has a CS42L51 audio codec I Connected on the I2C bus 1 of the SoC, at slave address 0x4A I Connected to the SAI interface 2 of the SoC I With its reset signal connected to GPIO 67 of the SoC I ... → These details cannot be guessed by the operating system/bootloader. - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 14/56 2. Using ACPI tables 3. Using a Device Tree Describing non-discoverable hardware 1. Directly in the I Using compiled data structures, typically in C OS/bootloader I How it was done on most embedded platforms in Linux, code U-Boot. I Considered not maintainable/sustainable on ARM32, which motivated the move to another solution. - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 15/56 1. Directly in the OS/bootloader code 3. Using a Device Tree Describing non-discoverable hardware I On x86 systems, but also on a subset of ARM64 platforms 2. Using ACPI tables I Tables provided by the firmware - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 15/56 1. Directly in the OS/bootloader code 2. Using ACPI tables Describing non-discoverable hardware I Originates from OpenFirmware, defined by Sun, used on SPARC and PowerPC I That’s why many Linux/U-Boot functions related to DT have a of_ prefix I Now used most embedded-oriented CPU architectures that run Linux: ARC, ARM64, RISC-V, ARM32, PowerPC, Xtensa, MIPS, etc. 3. Using a Device Tree I Writing/tweaking a DT is now always necessary when porting Linux to a new board. I The topic of this talk ! - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 15/56 Device Tree: from source to