Unfortunately, an embedded system is not free of crashes. To analyze and log such crashes it is useful to have a file system where we can store such information between reboots. One interface which is meant to do that is pstore and its current single implementation ramoops. Ramoops can store log messages inside a reserved memory area in RAM. The nice thing about RAM is, that it should almost always be available when the CPU is still running.

Sometimes we need access to a device inside a kernel driver which isn’t exposed directly. Based on an LED I would like to show an example on how we can use the parent child relationship of the device tree and the driver to access a class device. To get a better understanding let’s check the following device tree entry: / { leds { compatible = "gpio-leds"; pwr_led: pwr { label = "pwr"; gpios = <&expgpio 2 GPIO_ACTIVE_LOW>; }; }; led-control { compatible = "led-control"; led = <&pwr_led>; }; }; From led-control we want to access pwr_led.

Sometimes we want to compile a kernel module for an embedded device without replacing the kernel. This article provides a summary of the steps which have to be taken to compile the module. For this article I use Ubuntu 20.10 on the build machine but it should work with other distributions too. Just use the right package manager for your distro. As an embedded device I use a Raspberry Pi 4 but the same concept works for TI AM335x, NXP iMX6/iMX8, etc.

While working on a bring up for a new embedded board I made some mistake in setting up the pinmuxing of U-Boot. For U-Boot everything was fine but later on I tried to start the Linux kernel. This carshed the kernel with the following messages: [ 0.000000] 000: printk: bootconsole [linflex0] enabled [ 0.000000] 000: SError Interrupt on CPU0, code 0xbf000002 -- SError [ 0.000000] 000: CPU: 0 PID: 0 Comm: swapper Not tainted 5.

It’s quite simple. We have an application with tons of dependencies and decide to move it inside a container for better maintainability. So we write a Dockerfile which installs all dependencies and the application. After we run the container image it will start the application as an isolated process. While experimenting with OpenWRT I figured out that when I start procd inside a container it will never receive netlink messages. How can that be?