As we reported in previous blog post, almost the entire Bootlin engineering team was at the Embedded Linux Conference Europe in Prague in June. In order to share with our readers more about what happened at this conference, we have asked all engineers at Bootlin to select one talk they found interesting and useful and share a short summary of it. We will share this feedback in a series of blog post: first post, this one being the second post.
Braiding wires into the Linux network stack – recent work on embedded networking
Talk by Oleksij Rempel, chosen by Bootlin engineer Michael Opdenacker
Oleksij Rempel, working for Pengutronix, is a kernel developer who wants to promote the use of Single Pair Ethernet (SPE). SPE, identified as “T1” in 10BASE-T1, 100BASE-T1 or 1000BASE-T1, allows to use Ethernet over a single pair of wires, instead of two. SPE was initially created for automotive applications, and allows to reduce the weight and cost of cabling. That’s this sustainability aspect that motivates Oleksij to promote this technology, and led him to merge multiple patches in recent Linux kernel versions to support it.
Oleksij explains that any Ethernet (MAC) controller can support SPE, provided it is associated with a suitable external PHY. That’s for example the case of the ASIX chipset, that Pengutronix / LinuxAutomation uses in the USB-T1L device they produce (see the Linux kernel support for this device).
To further minimize cabling costs, SPE also supports Power over Data Line (PoDL) which allows to supply up to 50W through the data lines. Note that the “L” (Long) variant supports distances of up to 1 km.
Last but not least, this technology can be used together with Energy Efficient Ethernet to reduce the power consumption of active links.
So, if you are interested in testing SPE and contributing to its support, you can get an embedded board supporting this technology, such as the BeaglePlay and on the other side of the cable, the USB-T1L device connected to another system.
Note: we were lucky to spend a little time chatting with Oleksij, giving more background about this topic. He also confirmed that the nice pictures in his presentation where AI generated (using DALL·E 2 from OpenAI).
Camera sensor compliance
Talk by Jacopo Mondi, chosen by Bootlin engineer Paul Kocialkowski
Modern embedded devices come with the complexity of the camera pipeline fully exposed to the system, unlike traditional cases such as USB UVC where the image pipeline is hidden behind a micro-controller that does the heavy lifting using its own (proprietary) firmware. This complexity involves caring about all components in the pipeline individually, including the camera sensor itself. The Linux kernel V4L2 subsystem provides support for these with the subdev API and numerous drivers are available in the mainline Linux tree. In addition the userspace-side libcamera is there to bridge the gap between applications that do not care about the hardware-specific topology and the complexity exposed by the kernel.
This talk highlights a number of common issues that affect sensor drivers in particular, especially when their data is provided in raw Bayer format. This overview is particularly interesting for developers of sensor drivers and benefits from the experience gathered when developing libcamera. It provides a list of best practices and pitfalls for these drivers in order to achieve proper V4L2 API compliance and make it possible to correctly support them in userspace. It also mentions a few cases where the API itself is not very well defined and should be used with care.
This talk was really enjoyable as it provides direct and useful technical information that is clearly explained and on-point, without spending too much time on general considerations.
Kernel locking engineering
Talk by Daniel Vetter, chosen by Bootlin intern, soon engineer, Romain Gantois
Daniel Vetter is an engineer at Intel with more than 10 years of experience in maintaining graphics code in the kernel. His talk was centered around good and bad locking practices. He clearly had a good deal of experience in this subject so it was interesting to hear him talk about it. At the start of his presentation, he listed three priorities when using locks in code:
- Make it simple
- Make it correct
- Make it fast
He emphasized that if you tried to make the design correct before considering simplicity, then you might end up with a design that is difficult to change. He also warned against creating custom locking or concurrency primitives. we thought that this was sound advice, it reminded us of the old saying: “don’t roll out your own crypto”. Similarly to cryptography, locking seems like a complex topic where mistakes are easily made and tend to go under the radar. He then listed some locking engineering patterns, ranked by how desirable they were:
- Level 0: No Locking
- Level 1: Big Dumb Lock
- Level 2: Fine-grained Locking
- Level 2.5: … because Performance
- Level 3: Lockless Tricks
We thought that this was an interesting way of presenting things, since some projects require stranger designs than others and require compromise. For each one of those patterns, Daniel went into the technical details of some relevant concepts like kref_put_mutex and RCU. Overall, the presentation had a clear outline that allowed to grasp the main ideas.
Evaluation of PREEMPT_RT in virtualized environments
Talk by Jan Altenberg, chosen by Bootlin engineer Thomas Petazzoni
PREEMPT_RT is widely used to allow Linux to meet real-time constraints in a number of contexts. Increasingly, some of the use-cases in the industry also require the use of virtualization, for a number of reasons. Therefore, the interaction of PREEMPT_RT and its real-time guarantees together with virtualization is an interesting topic to study. Jan Altenberg, who works at the Open Source Automation Development Lab (OSADL), has precisely conducted such a study and his talk was a report from his findings.
He evaluated several technologies:
- “Software containerization”, with Docker containers
- “Hardware virtualization”, with both KVM and Jailhouse as hypervisors
First, with the containers solution, Jan’s conclusion is that you get the same latencies between the “guest” (container) and the host system, as expected due to how containers work. However, there is no isolation between the host and the guest: if there is misbehaving code on the host, real-time latencies in the guest are affected as well.
With the KVM solution, configured with isolated CPUs (3 CPUs for the host, 3 CPUs for the guest) on an x86-64 system, running a guest does not have an influence on the latencies in the host. It means that if you’re running your real-time workload on the host, while having a guest to run non-real-time workload, you’re fine. However, there is a relatively significant impact on the latencies in the guest. In terms of isolation: misbehaving code in the host affects both the host and guest, but misbehaving code in the guest does not affect the real-time latencies in the host. Which again means that the use-case of running the real-time workload in the host, and have non-real-time workloads in guests is a functional use-case.
Finally, Jan discussed the Jailhouse solution, tested on an ARM64 i.MX8MP platform. His conclusion is that the real-time latencies are as good in the host (“root cell” in Jailhouse speak) as in the guest (“inmate” in Jailhouse speak). And more than that: disruptions in the host do not have any effect on the real-time latencies in the guest. This certainly makes Jailhouse an interesting hypervisor technology to explore.
Overall, we found this talk very well documented, giving clear results and conclusions, that come from convincing and useful experiments.
