Marcus Folkesson

Embedded Linux Artist

Versioning with SWUpdate

Versioning with SWUpdate TLDR; It is now possible to let SWUpdate manage the sw-versions file entirely thanks to the --gen--swversions feature I've been working on. SWUpdate SWUpdate [1] is a project I've been using for a very long time for updating firmware on embedded systems. The update service is a critical part of any embedded system, so having a well-tested, flexible, competent and ready-to-use solution is so much worth. Too many times I've seen custom made update services that contain bugs, is not flexible enough or using slots for whatever software that could be updated. cover

Flattened Image Tree (FIT) with Yocto

Flattened Image Tree (FIT) with Yocto Long time ago, I wrota a post [1] that compared the legacy Image format against Flattened Image Tree Format (FIT) [2] and highlighted the benefits of using it. The benefits is still valid and FIT images is my preferred way to boot a Linux kernel. Dispite that, I almost never see that FIT images is used in examples nor Board Support Packages (BSPs). cover

Working on U-boot from Yocto (iMX8)

Working on U-boot from Yocto (iMX8) I have been asked a couple of times how to quickly make changes for U-Boot in Yocto. Those who asked have used to rebuild and flash an entire image each time, which takes an unnecessarily which is not a fast procedure. To rebuild U-Boot is`nt significantly different from any other recipe, but one difference is that imx-mkimage must also be built to generate a bootable image.

Increase the quality of your commits with pre-commit

Increase the quality of your commits with pre-commit pre-commit [1] is a framework for managing and maintaining pre-commit hooks for git. By running hooks before any commit, many small pitfalls could be avoided before being pushed and will spare reviewers time and energy. Such hooks could for example check that commit messages follow a specific format or that the code pass a lint test for a specific type of file. cover

Changing the root of your Linux filesystem

Changing the root of your Linux filesystem After my previous post [1], I've got a few questions from people about the difference between chroot, pivot_root and switch_root, they all seems to do the same thing, right? Almost. Lets shed some light on this topic. Rootfs First of all, we need to specify what we mean when we say rootfs. rootfs is a special instance of a ram filesystem (usually tpmfs) that is created in an early boot stage.

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: $ libcamera-still Preview window unavailable [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) [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.