Marcus Folkesson

Embedded Linux Artist

chroot and user namespaces

chroot and user namespaces When playing around with libcamera [1] and br2-readonly-rootfs-overlay [2] I found something.. well.. unexpected. At least at first glance. What happened was that I encountered this error: 1 $ libcamera-still 2Preview window unavailable 3[0:02:54.785102683] [517] INFO Camera camera_manager.cpp:299 libcamera v0.0.0+67319-2023.02-22-gd530afad-dirty (2024-02-20T16:56:34+01:00) 4[0:02:54.885731084] [518] ERROR Process process.cpp:312 Failed to unshare execution context: Operation not permitted Failed to unshare execution context: Operation not permitted... what? I know that libcamera executes proprietary IPAs (Image Processing Algorithms) as black boxes, and that the execution is isolated in their own namespace.

Streamline your kernel config

Streamline your kernel config When working with embedded systems, it's not that uncommon that you need to compile your own kernel for your hardware platform. The configuration file you use is probably based on some default configuration that you borrowed from the kernel tree, a vendor tree, a SoM-vendor or simply from your collegue. As the configuration is somehow generic, it probably contains tons of kernel modules that is not needed for your application.

Power button and embedded Linux

Power button and embedded Linux Not all embedded Linux systems has a power button, but for consumer electronic devices it could be a good thing to be able to turn it off. But how does it work in practice? Physical button It all starts with a physical button. At the board level, the button is usually connected to a General-Purpose-Input-Output (GPIO) pin on the processor. It doesn't have to be directly connected to the processor though, all that matters is that the button press can somehow be mapped to the Linux input subsystem.

br2-readonly-rootfs-overlay

br2-readonly-rootfs-overlay This is a Buildroot external module that could be used as a reference design when building your own system with an overlayed root filesystem. It's created as an external module to make it easy to adapt for your to your own application. The goal is to achieve the same functionality I have in meta-readonly-rootfs-overlay [1] but for Buildroot. Why does this exists? Having a read-only root file system is useful for many scenarios:

Expose network namespace created by Docker

Expose network namespace created by Docker Disclaimer: this is probably *not* the best way for doing this, but it's pretty good for educational purposes. During a debug session I wanted to connect an application to a service tha ran in a docker container. This was for test-purposes only, so hackish and fast are the keywords. First of all, I'm not a Docker expert, but I've a pretty good understanding on Linux internals, namespaces and how things works on a Linux system.

Mutex guards in the Linux kernel

Mutex guards in the Linux kernel I found an interresting thread [1] while searching my inbox for something completely unrelated. Peter Zijistra has written a few cleanup functions that where introduced in v6.4 with this commit: commit 54da6a0924311c7cf5015533991e44fb8eb12773 Author: Peter Zijlstra <peterz@infradead.org> Date: Fri May 26 12:23:48 2023 +0200 locking: Introduce __cleanup() based infrastructure Use __attribute__((__cleanup__(func))) to build: - simple auto-release pointers using __free() - 'classes' with constructor and destructor semantics for scope-based resource management.

Test packages in Buildroot

Test packages in Buildroot When writing packages for Buildroot there are several conditions that you have to test your package against. This includes different toolchains, architectures, C-libraries, thread-implementations and more. To help you with that, Buildroot provides the utils/test-pkg script. Nothing describes the script better than its own help text [1]: test-pkg: test-build a package against various toolchains and architectures The supplied config snippet is appended to each toolchain config, the resulting configuration is checked to ensure it still contains all options specified in the snippet; if any is missing, the build is skipped, on the assumption that the package under test requires a toolchain or architecture feature that is missing.

Git version in cmake

Git version in CMake All applications have versions. The version should somehow be exposed in the application to make it possible to determine which application we are actually running. I've seen a plenty of variants on how this is achieved, some are good and some are really bad. Since it's such a common thing, I thought I'd show how I usually do it. I use to let CMake determine the version based on git describe and tags, the benefit's that it is part of the build process (i.

Burn eFuses for MAC address on iMX8MP

Burn eFuses for MAC address on iMX8MP The iMX (iMX6, iMX7, iMX8) has a similiar OCOTP (On-Chip One Time Programmable) module that store, for example the MAC addresses for the internal ethernet controllers. The reference manual is not clear either on the byte order or which bytes belong to which MAC address when there are several. In fact, I had to look at the U-boot implementation [1] to know for sure how these fuses is used: cover

Loopback with two (physical) ethernet interfaces

Loopback with two (physical) ethernet interfaces Imagine that you have an embedded device with two physical ethernet ports. You want to verify the functionality of both these ports in the manufacturing process, so you connect an ethernet cable between the ports, setup IP addresses and now what? As Linux (actually the default network namespace) is aware of the both adapters and their IP/MAC-addresses, the system see no reason to send any traffic out. cover