Initially planned to take place in Dublin, Ireland, the unique edition this year of the Embedded Linux Conference will take place in Seattle, US and virtually from September 27 to September 30, 2021. See also the conference website. Bootlin CEO Thomas Petazzoni is again a member of the program committee for this edition of ELC.
This kind of event is only possible thanks to the talks proposed by its participants! As detailed on the Call For Papers, the last date to submit your proposals is June 13, 2021. There is really a wide range of suggested topics, and ELC is an excellent place to talk about advancements in the Linux kernel for embedded platforms, in user-space libraries and stacks relevant to embedded, about practical experiences in using Linux in embedded devices, about real-time, boot time, power management, build systems, open hardware, and more.
Bootlin has been offering for several years a Buildroot system development course, which allows engineers interested in learning and understanding the Buildroot embedded Linux build system to get up to speed very quickly.
In addition to updating to a newer Buildroot version, we also use newer U-Boot and Linux versions for the practical labs on BeagleBone Black Wireless. The slides were also updated to document some new features that appeared between 2020.02 and 2021.02. If you’re interested, check out the materials on the training page.
We have one seat left for this training course next week, which will be taught by long-time Buildroot contributor and developer Thomas Petazzoni. Register now and take the last seat!
The schedule for the next edition of Live Embedded Event has been published! This 100% online and free conference will take place on June 3rd, 2021. Thanks to the proposals received, the event will feature 4 tracks during the entire day, covering a wide range of topics: hardware for embedded systems, embedded Linux, RTOS, IoT, FPGA, RISC-V, and more.
Bootlin is once again part of the organization team for this event, and in addition 5 talks proposed by Bootlin have been selected into the schedule. See below the details of our talks.
Understanding U-Boot Falcon Mode and adding support for new boards, Michael Opdenacker
The Falcon Mode is a U-Boot feature that allows to directly load the operating system kernel from the first stage of U-Boot (a.k.a. “SPL”), skipping the second stage of U-Boot. Doing this can save up to 1 second in the boot process, and this way, you can keep a full featured U-Boot that you can still fall back to for maintenance or development needs. However, using Falcon Mode is not always easy, as it requires extra code that most boards supported by U-Boot don’t have yet. At Bootlin, we had to add such support to U-Boot for several boards. This presentation will explain how Falcon Mode booting actually works in U-Boot and the implementation and usage choices made by U-Boot developers. It will show you how to add such Falcon Mode support to U-Boot for your own board.
In embedded systems, deploying firmware updates in the field has now become an obvious requirement, to ensure that security vulnerabilities are addressed, that bugs are fixed, and new functionalities can be delivered to the users. Among a range of different open-source solutions, RAUC provides an interesting firmware update mechanism for embedded system. In this talk, we will introduce the main features of RAUC, its integration in build systems such as Buildroot or the Yocto Project, as well as its integration with the U-Boot and Barebox bootloaders. Finally we will explore some common update scenarios that are fully supported by RAUC features.
Security vulnerability tracking tools in Buildroot, Thomas Petazzoni
Buildroot is a popular and easy to use embedded Linux build system. With the increasing concern around security vulnerabilities affecting embedded systems, and the need to keep them updated, Buildroot has been extended with new tooling for security vulnerability tracking. This tooling allows to monitor the CVEs that affect the packages present in Buildroot. In this talk, we will introduce the principle of CVEs and CPEs, present the tools now available in Buildroot to help keep track of the security vulnerabilities, show how they can be used for a project and identify the current limitations of this tooling.
Secure boot in embedded Linux systems, Thomas Perrot
Secure boot is a integrity mechanism, based on signature verification, that allows to detect software corruption or malicious code, during the boot process. Implementing secure boot is not always obvious, as it requires multiple stages of verification, at the bootloader, Linux kernel and root filesystem level, as well as integration into the build system, CI infrastructure, firmware upgrade mechanism, and more. Based on a recent experience to bring secure boot on an NXP i.MX8 platform, Thomas will present how to implement the chain of trust from the SoC ROM code to the root filesystem, as well as other considerations related to the implementation of secure boot. While the presentation will use the i.MX8 as an example, most of the discussion will apply to other platforms as well.
Device Tree overlays and U-boot extension board management, Köry Maincent
In this talk, we will start by introducing the mechanism of Device Tree Overlays, which are a way of extending the Device Tree itself to describe additional hardware. We will show how Device Tree Overlays are written, compiled, and applied to a base Device Tree, and what is the status of Device Tree Overlays support in U-Boot and Linux. We will take the example of the BeagleBoard.org project, showing how Device Tree overlays are used to make CAPE extension boards compatible with different boards. Finally, we will describe our proposal, already submitted to the community, to add an extension board management facility to U-Boot, which automatically detects, loads and applies the appropriate Device Tree Overlays depending on the extension boards that are detected.
Bootlin recently received a beta prototype of the BeagleV Starlight featuring a RISC-V 64 bit SoC capable of running Linux, designed by StarFive This early version is not available to the general public, but several of us at Bootlin volunteered to join the beta developer program to assist with upstream software development. BeagleBoard.org has a public BeagleV forum that everyone can join for future updates on the project.
Two days after my colleague Thomas Petazzoni received his board, he managed to submit a patch for the mainline version of Buildroot to add support for this new board. Actually, compiling an image with Buildroot and preparing an SD card is easier than downloading and flashing the initial Fedora image offered for this beta board.
If you are just interested in testing the software on your board, you may directly get our binaries from our Build results paragraph.
The following instructions are derived from the board/beaglev/readme.txt file in Thomas’ proposed patch.
How to build
First, clone Buildroot’s git repository if you haven’t done it yet:
$ git clone git://git.buildroot.net/buildroot
Then add a remote branch corresponding to Thomas Petazzoni’s own tree, as his changes haven’t made their way into the mainline yet, and checkout a local copy of his beaglev branch:
You just need to insert your micro SD card into a card reader (assuming the /dev/sdX device file is used), and type the below command:
$ sudo dd if=output/images/sdcard.img of=/dev/sdX
Preparing the board
To prevent the experimental board from overheating, connect the BeagleV fan to the 5V supply (pin 2 or 4 of the GPIO connector) and GND (pin 6 of the GPIO connector).
To access a serial console, connect a TTL UART cable to pins 6 (GND), 8 (TX) and 10 (RX):
Insert your SD card and power-up the board using a USB-C cable.
Flashing the bootloader
The bootloader pre-flashed on the BeagleV has a non-working fdt_addr_r environment variable value, so it won’t work as-is. Reflashing the existing bootloader with the bootloader image produced by Buildroot is therefore necessary.
When the board starts up, a pre-loader shows a count down of 2 seconds. Interrupt it by pressing any key. You should then reach a menu like
ddr 0x00000000, 1M test
ddr 0x00100000, 2M test
DDR clk 2133M,Version: 210302-5aea32f
*************** FLASH PROGRAMMING *****************
select the function:
Press 0 and Enter. You will now see C characters being displayed. Ask your serial port communication program to send the fw_payload.bin.out file using the Xmodem protocol (with the sx command). For example, here’s how to do it with picocom…
picocom should be started as:
$ picocom -b 115200 -s "sx -vv" /dev/ttyUSB0
When you see the C characters on the serial line, press [Ctrl][a] [Ctrl][s]. Picocom will then ask for a file name, and you should type fw_payload.bin.out.
After a few minutes, reflashing should be complete. Then, restart the board. It will automatically start the system from the SD card, and reach the login prompt:
Welcome to Buildroot
buildroot login: root
# uname -a
Linux buildroot 5.10.6 #2 SMP Sun May 2 17:23:56 CEST 2021 riscv64 GNU/Linux
Here are useful resources for people who already have the Beagle V board:
BeagleBoard’s beaglev-starlight: GitHub repository containing hardware design files, links to source code repositories (Linux, U-Boot, OpenSBI…) and useful documentation.
Typical embedded Linux systems include a wide number of software components, which all need to be compiled and integrated together. Two main approaches are used in the industry to integrate such embedded Linux systems: build systems such as Yocto/OpenEmbedded, Buildroot or OpenWrt, and binary distributions such as Debian, Ubuntu or Fedora. Of course, both options have their own advantages and drawbacks.
One of the benefits of using standard binary distributions such as Debian or Ubuntu is their widespread use, their serious and long-term security maintenance and their large number of packages. However, they often lack appropriate tools to automate the process of creating a complete Linux system image that combines existing binary packages and custom packages.
In this blog post, we introduce ELBE (Embedded Linux Build Environment), which is a build system designed to build Debian distributions and images for the embedded world. While ELBE was initially focused on Debian only, Bootlin contributed support for building Ubuntu images with ELBE, and this blog post will show as an example how to build an Ubuntu image with ELBE for a Raspberry Pi 3B.
ELBE base principle
When you first run ELBE, it creates a Virtual Machine (VM) for building root filesystems. This VM is called initvm. The process of building the root filesystem for your image is to submit and XML file to the initvm, which triggers the building of an image.
The ELBE XML file can contain an archive, which can contain configuration files, and additional software. It uses pre-built software in the form of Debian/Ubuntu packages (.deb). It is also possible to use custom repositories to get special packages into the root filesystem. The resulting root file system (a customized Debian or Ubuntu distribution) can still be upgraded and maintained through Debian’s tools such as APT (Advanced Package Tool). This is the biggest difference between ELBE and other build systems like the Yocto Project and Buildroot.
As mentioned in this blog post introduction, Bootlin contributed support for building Ubuntu images to ELBE, which led to the following upstream commits:
Creating your initvm should take at least 10 to 20 minutes.
In case you rebooted your computer or stopped the VM, you will need to start it:
$ elbe initvm start
Create an ELBE project for our Ubuntu image.
To begin with, we will base our image on the armhf-ubuntu example. We create an ELBE pbuilder project and not a simple ELBE project because we later want to build our own Linux kernel package for our board:
The project identifier is written to rpi.prj. We save the identifier to a shell variable to simplify the next ELBE commands:
$ PRJ=$(cat rpi.prj)
Build the Linux package
As explained earlier we want to use ELBE to build our package for the Linux kernel. ELBE uses the standard Debian tool pbuilder to build packages. Therefore, we need to have debianized sources (i.e sources with the appropriate Debian metadata in a debian/ subfolder) to build a package with pbuilder.
First clone the Linux repositories:
$ git clone -b rpi-5.10.y https://github.com/raspberrypi/linux.git
$ cd linux
Debianize the Linux repositories. We use the elbe debianize command to simplify the generation of the debian folder:
$ elbe debianize
Fill the settings in the UI as follows (make sure you reduce the font size if you don’t see the Confirm button):
Make sure you set Name to rpi. Otherwise, you won’t get the output file names we use in the upcoming instructions.
The debianize command helps to create the skeleton of the debian folder in the sources. It has been pre-configured for a few packages like bootloaders or the Linux kernel, to create the rules to build these packages. It may need further modifications to finish the packaging process. Take a look a the manual to have more information on debianization. In our case, we need to tweak the debian/ folder with the two following steps to cross-build the Raspberry Linux kernel without error.
Append the below lines to the debian/rules file (use tabs instead of spaces):
To tell ELBE that the XML file has changed, you need to send it to the initvm:
$ elbe control set_xml $PRJ examples/armhf-ubuntu.xml
Then build the image with ELBE:
$ elbe control build $PRJ
$ elbe control wait_busy $PRJ
Finally, if the build completes successfully, you can retrieve the image file from the initvm:
$ elbe control get_files $PRJ
$ elbe control get_file $PRJ sdcard.img.tar.gz
Now you can flash the SD card image:
$ tar xf sdcard.img.tar.gz
$ dd if=sdcard.img of=/dev/sdX bs=1M
And boot the board with root and foo as login and password:
Ubuntu 18.04.1 LTS myUbuntu ttyAMA0
myUbuntu login: root
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 5.10-rpi armv7l)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
Note: Ubuntu cannot be built for Raspberry A, B, B+, 0 and 0W according to https://wiki.ubuntu.com/ARM/RaspberryPi, as Ubuntu targets the ARMv7-A architecture, while the older RaspberryPi use an ARMv6 processor.
You can find our talk about ELBE at the ELCE 2020 conference: PDF slides, video.