The Zephyr Developer Summit, hosted under the first-ever Embedded Open Source Summit in Prague, Czech Republic, on June 27-30 included presentations, BoFs, and training designed for real time problem solving and deep discussions. More than 1,300 people registered for the EOSS conference – representing 375 organizations across 56 countries around the globe. Zephyr had 75+ technical sessions (in-person and on-demand) for 3 tracks focused on users of Zephyr, developers contributing upstream, and maintainer-specific topics.
All of the videos from the Zephyr Developer Summit can be found on the Zephyr Youtube Channel. Each week, we’ll highlight a few videos in a blog for easy access. Today, we’re featuring a few sessions focused on developer tools for debugging including, “Overview of Logging,” “Tokenized Logging with Pigweed,” “Adding Coredumps to Your Debugging Toolkit,” and “Using Customerized QEMU Co-simulation for Development and Test of Zephyr Applications.”
Overview of Logging – Aastha Grover, Software Engineer at Intel Corporation
The logging subsystem has various capabilities that we can use to our advantage in integrating embedded software into the underlying hardware. Loggers can process both messages issued by developers and trace date, both of which can be used for analysis and debugging. This presentation gives an overview of the logging subsystem in general and talks about different logging formats (MIPI SyS-t, dictionary, text, etc.), their usage, and how they provide better ways to debug and log. It will also show users how to enable/disable logging and switch formats at runtime.
Tokenized Logging with Pigweed – Al Semjonovs, Software Engineer at Google
For space saving, Zephyr’s logging subsystem can be enabled to provide a dictionary based logging system. This creates a JSON database file in the build directory which contains information to correctly parse log data. This database file only works with the build it’s generated with. Other builds cannot use the same database file as strings are mapped to their address. At Google, we’re opting to use Pigweeds (PW) tokenizer logging module. Instead of mapping strings to addresses, PW tokenizer maps strings to a hash. When log format strings stay the same between builds, the hash stays the same. Any new strings are appended to the hash database. Addresses are almost entirely unpredictable between builds. This reduces friction for developers in viewing logs when making changes while also reducing image size. We’re working on making pigweed as an additional Zephyr module which can be linked in with KConfig options. The hash database will be updated and stored as an artifact of each build.
Adding Coredumps to Your Debugging Toolkit – Eric Johnson,Firmware Solutions Engineer at Memfault