Round-Up of the Yocto Project Summit 2023.11
Episode 51: Better Built By Burkhard
Dear Reader,
My OTA update project led me into the depths of u-boot as well as hardware and software watchdogs. A rootfs update is considered successful, if the new system passes some tests after the first start. A very simple test is that the main application runs for two minutes without crashing.
The test fails, if the Linux kernel or the systemd daemon do not start. Then, a hardware watchdog reboots the device. The test also fails, if the main application crashes, say, twice within 30 seconds. Then, the watchdog of the systemd service starting the main application reboots the device. You find a detailed description how to configure these watchdogs in the post systemd for Administrators, Part XV.
In case of a broken update, the two watchdogs would send the device into an infinite loop of rebooting. You certainly don’t want this. The remedy is to enable boot counting in u-boot (see slides 17-22 of the presentation Recovering from a failed upgrade). If the device reboots, say, for the fourth time, it doesn’t boot into the newly updated partition but falls back into the old, still working partition - using the alternate boot command altbootcmd.
The fallback mechanism is working reliably now. My next adventures will be delta updates and bootloader updates. I am sure that I’ll figure out even more ways to bork my board. Fortunately, I have become quite an expert in reanimating the board with the recovery SD card.
Happy reading,
Burkhard
My Content
A Yocto Recipe for Qt Applications Built with CMake (post)
I have seen many development teams struggle with building their Qt applications as part of the Yocto build. The teams simply don’t know how to write a Yocto recipe and a CMakeLists.txt file that work together properly in the Yocto build. It’s difficult because the interface between BitBake and CMake lacks documentation.
You need to understand how the BitBake tasks do_configure, do_compile and do_install call CMake and how the CMake install command passes back the files to be installed in the rootfs image. Step-by-step, I’ll walk you through the tasks defined in cmake.bbclass, through an example Yocto recipe and through an example CMakeLists.txt file.
Round-Up of the Yocto Project Summit 2023.11
You can find the schedule for the talks at the Yocto Project Summit 2023.11 here. Each talk summary provides a link to the slides. You can find the videos of the talks on YouTube.
Luca Ceresoli (Bootlin): Keep your layer simple - and here’s how (video)
Luca introduces a minimal Yocto project comprising only four layers: meta-kiss, meta-arm, openembedded-core and bitbake (see the repository simplest-yocto-setup for the source code). The project includes two machine configurations - one for each product of the KISS company - and a custom distro configuration. It uses a mainline u-boot and Linux kernel. The whole project has less than 330 lines of code (excluding the always lengthy Linux configuration defconfig). Now that is not just minimal but “micromal”!
Luca replaces the vendor layers for the SoCs (e.g., meta-freescale, meta-ti), for the SoMs (e.g., meta-toradex, meta-variscite) and for the HMI terminal by the mainstream meta-arm layer. He avoids using buggy, outdated and redundant code from all these layers. Especially, the layers provided by the terminal makers are often terribly out-of-date as I have documented in Episode 37.
I have certainly written my fair share of extensions, patches and outright hacks (e.g., excluding recipes) for these layers over the years. So, Luca’s approach resonates deeply with me. Currently, I have different not-so-KISSy layers for SoMs from different vendors but with the same SoC. Even for the same Yocto version, the vendor layers use different versions for the kernel, u-boot and other important packages. So, I’ll use Luca’s approach to reduce my maintenance costs and build times.
I have read the advice not to use the Poky distribution in production many times. To my shame, I must admit that I haven’t followed it. Now, I am running out of excuses. Luca shows how to write a three-line distro configuration that doesn’t depend on Poky. The main idea is to explicitly list the required DISTRO_FEATURES.
Anna-Lena Marx (Inovex): Building a Yocto CI Pipeline with KAS, GitHub Actions and AWS - What could possibly go wrong? (video)
Anna-Lena shows how to set up a CI pipeline with a self-hosted GitHub Actions Runner, which performs Yocto builds on an AWS instance. In the original setup (see timestamp 7:48), the Actions Runner creates an AWS instance and tells it exactly what to do. This setup doesn’t work because of too many indirections: the Actions Runner controls the kas container through the AWS instance.
The pipeline starts working, when Anna-Lena moves the Actions Runner into a custom AWS instance. The workflow looks roughly like this:
Define a custom Amazon Machine Image (AMI), which contains kas and the setup for a self-hosted Actions Runner (see A Basic Continuous Integration Pipeline with GitHub Actions for the local setup). I’d reckon that defining an AMI is similar to writing a Dockerfile.
Create an AWS instance from the AMI and keep it running.
When a developer changes anything in your custom Yocto layer or in your kas configuration, GitHub Actions triggers a Yocto build by calling
kas-container <image>.
I don’t know whether AWS bills you only if a Yocto build is running or also if the Actions Runner is waiting for a code change. If it’s the latter, your bill may get pretty high quickly. Then, you might want to buy a build server and run the pipeline on this server. I bought one 7 or 8 years ago for 7500 EUR. It was one of my best purchases ever. By the way, having your own server spares you the troubles Anna-Lena went through.
If you are wondering why you should set up a CI pipeline for Yocto builds, here is Anna-Lena’s answer:
[A CI pipeline provides] ready-to-use images for app devs, product owners, testers, … - without the need to touch Yocto at all.
Leon Anavi (Konsulko): Integrating VNC in Weston with the Yocto Project and OpenEmbedded (video)
Leon provides a demo video on his own web site, where the VNC server runs as a part of the Weston compositor on a Raspberry Pi and the open-source Vinagre VNC client runs on a Ubuntu laptop. You are free to use other VNC clients on other computers, tablets and smartphones. In the demo setup, the VNC server and client run in the same local network. The VNC server transfers roughly 18 frames per second (fps) to the VNC clients.
Using VNC for Remote Support in Agriculture
The VNC server mirrors the contents of a screen (e.g., the contents of a driver terminal in an agricultural machine) to a computer anywhere else in the world. So, the support technician in Germany sees the same screen as the harvester driver in Japan and can help him diagnose a sudden increase in diesel consumption.
In 2016, two developers from an Italian consultancy company and I built a remote support solution with VNC for the Krone forage harvesters. The Wayland protocol would have made it easier to “copy” the frame buffer contents to the VNC server. It controls the access to shared memory like the frame buffer with semaphores. However, NXP never supported Wayland on its iMX53 SoCs. So, we had to implement our own solution for controlling frame buffer access from the GUI application and the VNC server.
In 2017, this solution made it into the ISOBUS terminal CCI 1200, which is deployed on thousands of agricultural machines per year. Our VNC solution worked out of the box - happily ignoring the Wayland drivers available on the iMX6-based ISOBUS terminal. Our ignorance turned out to be the right decision, as it took the Wayland developers another 6 years to integrate VNC into the default Wayland compositor, Weston.
8 years ago, we were happy to have 1-5 fps on the maize fields. 2G or 3G mobile Internet connection were normal. 4G/LTE connections were the very rare exception. The low bandwidth and frame rates were enough, as the technicians would look at mostly static screens during remote support sessions.
Starting with version 12, Weston, the default Wayland compositor, comes with a VNC server (NeatVNC) integrated. The first Yocto version with Weston 12 is Yocto 4.3 (Nanbield), whose support ends in May 2024. The first LTS version (supported till April 2028) will be Yocto 5.0 (Scarthgap).
I doubt that Yocto 4.0 (Kirkstone, supported till April 2026) will ever support Weston 12. Your options are to move to Yocto 5.0 or to backport Weston 12 to Yocto 4.0. I’d reckon that moving to Yocto 5.0 is less time-consuming. I will know more soon, as I am going to implement remote support via VNC for a customer this year.
Leon describes in the slides Bitbaking Weston with VNC, Bitbaking NeatVNC for Weston with VNC, weston-init.bbappend, TLS security, Using VNC on Weston and VNC Automatic Startup, how to build Weston with VNC as part of your Yocto project. TLS provides end-to-end encryption for VNC connections. This allows you to use VNC over the open Internet.
Weston 12 comes with one important restriction. It only works with the open-source etnaviv GPU drivers. It doesn’t work with the proprietary Vivante GPU drivers yet.
The Qt VNC Server Module
Qt 6.4 saw the introduction of the Qt VNC Server module, which is only available under the Qt Commercial license. Qt VNC Server allows you to mirror QML applications or parts thereof from an embedded device to any remote computer. It actually mirrors the part of the QML application that has a VncItem as its root.
If the VncItem is the root item of the application, you’ll see the whole application on remote computers. If the VncItem is the root of a ListView, for example, you’ll only see the ListView on remote computers. In the special case, where the Wayland compositor is a QML application, you’ll see the full screen.
If you invert the above statements, you’ll understand what Qt VNC Server will not show on remote computers. Qt VNC Server cannot share any non-QML applications including QWidget-based applications. This is true for any application that is written with a GUI framework other than QML. As Weston is such an application, there is no easy way to share the full-screen Weston desktop - unless Weston always displays a QML application full-screen.
Qt VNC Server does not provide end-to-end encryption for VNC connections. It only provides password protection. So, you should only use Qt VNC Server in local networks or in VPNs.