Open Source Summit Europe 2024 happened in mid September In Vienna and incorporated the Embedded Linux Conference. The Good Penguin sent a group over to participate to both network and also to keep up to date on what new developments are happening, not just in the Embedded Linux space but also the broader Linux and Open Source landscape. This blog posting shares some of the highlight talks that were seen by us (Marc Kelly and Adrian Sweet) over the 3 days.
How to Enable Android (AOSP) on Your Developer Board – Mattijs Korpershoek, BayLibre
We have recently had enquiries about the possibility of bringing up Android distros on customer hardware and with that in mind this talk seemed a very good starting point for gaining knowledge on the subject as a developer, myself, who has not had much direct exposure to Android in recent years. While the underlying systems of bootloader and Linux kernel are familiar, the build system is vastly different from my normal Yocto based work.
Mattijs presented an interesting journey through bringing up a new board from scratch, with all the steps and pitfalls that could be expected when trying to do this for the first time. He began with explaining the concept of the Cuttlefish virtual Android device before leading into the basics of configuring a new build target, which in this case was a Beagleboard BeaglePlay board. With the hardware configuration for the target done, he turned to the partition layout and the explanation of how Android handles the various partitions for booting and the user space side of the operating system. The major difference with Android over a normal Linux operating system distribution is how the kernel is treated, with Android using its own branches and not a direct upstream kernel. This means for some newer hardware there can be substantial backporting from mainline into the android kernel in order to support new hardware. While Android is working on direct support for the mainline, this is not there yet. The bootloader, u-boot, in this situation is less restricted and providing it supports the Android bootloader protocols it should work with any vendor version.
Overall his description on how to set up the build, the kernel, bootloader and then the basic android packages together with pointers at further configuration give a perfect overview for a beginner
See the schedule for the slides and further information. On more familiar ground with Yocto was the following talk…
Building and Maintaining Binary Distributions with Yocto – Michael Opdenacker, Root Commit
There was funding given by the Sovereign Tech Fund recently to the Yocto project to improve its support for being used as a binary distribution. The main goal of this type of work is to try to provide a Yocto that is prebuilt and reused in much the same way that a traditional Redhat, Debian, Ubuntu based one would be. This would allow updates to be performed on a per-package basis rather than the traditional whole file system methodology a traditional built from source Yocto would be.
The talk explained that Yocto does use binary packages internally, in one of three formats, rpm, deb or ipk. Those are used to create the rootfs, but no package data is included in the rootfs by default. Although easily added via a specific addition to IMAGE_FEATURES. The packages can also be easily exported into a package feed by the usage of “bitbake package-index” and then hosting the “tmp/deploy/<pkgtype>/” directory via a simple web server. A large portion of the talk then went on to explain how package versioning and the ability to differentiate newer packages is important, and by default not something Yocto does. The use of a PR (Package Revision) Server is needed to able to handle the task of tracking revision of rebuilds, and can determine if a new version is needed when the Hash of a package source changes. Ongoing work for the next release mentioned how there has been progress to allow nesting PR servers such that there is a concept of an upstream PR server that runs in Read-Only mode that generates the information for the default packages and then a local build would only need to generate the packages that have been changed. There are also patches in progress to allow the Yocto selfbuilder to test the functionality of performing package based updates for constant regression testing. Overall the progress towards a binary style distribution is going well, and has advantages for allowing quicker testing and bring up when trying to evaluate different new embedded boards.
See the schedule for the slides and further information.
The Cyber Resilience Act: Navigating Its Impact on Yocto-Based Products – Julien Bernet, Witekio
The upcoming Cyber Resilience Act is starting to cause ripples through the software and embedded industry as more details around the requirements and responsibilities becomes known across a broader audience. In his talk Julien detailed not just some of the important notes of the act but also went into some of the ways that open source authors and those using open source software in products are going to be required to both audit and maintain their output.
The requirement for manufacturers of end products to support their product for a minimum lifetime, and also, if they find a vulnerability in any open source component, they will be compelled to submit that back to the community. This seems like it would have a drastic effect on the way some large companies do business with their constant product updates, and dropping existing revisions from support after only 6-12 months. The level of documentation that needs to be produced by a device manufacturer, and what kinds of analysis is required was also touched on. Yocto can produce CVE lists for a build, however these often need extensive post processing to become relevant, and methods around this were examined.
The talk also spawned a rather lively debate after the end of the talk over the state of the upcoming law and the impact it would have.
See the schedule for the slides and further information.
Testing Your Yocto Proj: from Ptest & Testimage to LAVA – Clara Kowalsky & Florian Bezdeka, Siemens
This was a talk detailing how to use the Yocto test frameworks, how to integrate this into a CI/CD environment. As well as the presenters experiences in how well this functions, what Yocto provides, and how easy it is to customise for specific test environments.
The talk was split into two phases. The first part talked about Yocto’s testimage and ptest, and provided a simple overview of the tests already provided in Yocto and how to implement your own tests in python. The talk then proceeded to describe how Siemens have used these features from their CI/CD environment – and in particular how they enhanced and upstreamed new functionality to produce a junit test result .xml file from the pre-existing Yocto json file output log. The junit file is used by gitlabs and github to produce test result graphs for the run, and to track statistics over time.
The second part talked about LAVA (Linaro Automated Validation Architecture) system, and how it can help with managing test runs on physical hardware across multiple device farms. The talk went through a brief description of what LAVA provides, and how Siemens configure their lab devices (serial, power, LAN) to be fully controllable by the system. The talk went over how to configure and submit jobs into the LAVA system, what the LAVA system will then perform on the device (power on the device, interact with the device to boot the deployed artifacts, perform the tests, power off the device again), and, again, how this can feedback results into a CI/CD system.
The talk provided a good introduction to what is available in Yocto, and how this, with the help of LAVA, can be turned into a fully automated test environment with real hardware run through a CI/CD system. As well as showing how easy it can be to configure these systems for your individual setup.
See the schedule for the slides and further information.