Embedded, Mobile and Automotive

ply: lightweight eBPF tracing

D.embedded
Frank Vasquez
<p>In this talk, I will show you how to build and deploy ply (a dynamic tracing language for eBPF) to a BeagleBone Black then write ply scripts to attach probes and tracepoints to a running kernel and application on that same target. eBPF has rapidly eclipsed all previous tracers for Linux. While eBPF has taken the cloud native community by storm, the technology has yet to make significant inroads within the embedded Linux ecosystem. I will explain the reasons for this current situation and demonstrate a possible way forward.</p> <p>The bpftrace dynamic tracing language relies on the LLVM-based BCC toolchain to compile scripts down to eBPF bytecode. Because of its dependency on LLVM, BCC only supports a few 64-bit CPU architectures, severely limiting the use of eBPF in embedded systems. Fortunately, the IO Visor Project offers a lightweight alternative to bpftrace called ply. Like bpftrace, ply’s syntax is inspired by both DTrace and awk. Unlike bpftrace, ply targets embedded CPU architectures like ARM and PowerPC making it possible to deploy eBPF to many more devices. Buildroot includes ply as of its 2021.02 LTS release.</p>

Additional information

Type devroom

More sessions

2/5/22
Embedded, Mobile and Automotive
Josef Holzmayr
D.embedded
<p>Once you start out in embedded linux, there is a lot to do. Some things are obvious, some less so. First and foremost, you can put your knowledge of using Linux on the desktop to good use, right? This approach feels like a natural progression, but it has its pitfalls - some of which this talk aims to help you understand and ultimately avoid.</p>
2/5/22
Embedded, Mobile and Automotive
Nicolas Caramelli
D.embedded
<p>DirectFB2 is a fork of DirectFB, a graphics library designed with embedded systems in mind that was widely used in the GNU/Linux embedded world. DirectFB2 comes with changes such as a Meson build system, a pure C implementation and a modularization of the source code.</p> <p>Access to the low-level display is based on a DRM/KMS system module (or possibly on a legacy Framebuffer system module), and depending on the platform, hardware-accelerated graphics rendering can be achieved using the ...
2/5/22
Embedded, Mobile and Automotive
Jean-Louis Thekekara
D.embedded
<p>I would like to share my experience bringing up various Automotive Ethernet Gigabit PHYs on an iMX8 platform.</p> <p>Agenda:</p> <ul> <li>PHY configuration CheckList (= What I need to know about my PHY, my schematic before starting the bring-up)</li> <li>SW implementation (= step-by-step SW integration + common pitfalls to avoid, mainly focused on Linux, but I talk also about U-Boot)</li> <li>Debug tips (= SW and HW tips)</li> </ul>
2/5/22
Embedded, Mobile and Automotive
Leon Anavi
D.embedded
<p>RAUC is a safe and secure open source software solution for A/B updates of embedded Linux devices. RAUC supports industry-leading build system: the Yocto Project and OpenEmbedded, Buildroot and PTXdist. Porting RAUC to a new device requires several advanced technical steps. Layer meta-rauc-community exists to speed up and simplify the integration process for Yocto and OpenEmbedded by providing examples for popular devices such as Rasperry Pi, Allwinner (Sunxi), NVIDIA Tegra and QEMU.</p>
2/5/22
Embedded, Mobile and Automotive
Eilís Ní Fhlannagáin
D.embedded
<p>In this talk, pidge will take a critical look at the places where meta-zephyr succeeds and fails in its original goals, the reasons behind that and the steps being taken to fix those issues.</p>
2/5/22
Embedded, Mobile and Automotive
Babar Khan
D.embedded
<p>FPGAs are increasingly being used in today's embedded systems. But they are notoriously complex for having a difficult programming model. In order to counter this complexity, there has been a growing focus to design FPGA hardware at a higher level of abstraction with new languages and compilers. This talk will serve as "one stop shop" for topics related to these developments.</p>
2/5/22
Embedded, Mobile and Automotive
Bernhard Rosenkränzer
D.embedded
<p>Sometimes it is useful to share code across multiple kernels -- in projects like the Oniro door lock blueprint, for the typical use cases a Cortex-M CPU running Zephyr is more than sufficient, but using its functionality as part of a larger project makes using Linux on Cortex-A an interesting option. Can we find a way to maximize code reuse despite the very different GPIO APIs?</p>