Skip to main content

Basic AMP on the i.MX8M Mini with Rpmsg

giant-gd1d82756c_640.jpg

In a recent post, I described the basics to execute code on the Cortex M4 micro controller inside the i.MX8M Mini SoC. However there was no communication going on between Linux on the Cortex A cores and the application running on the M4. In this post, I will look at an example using the remoteproc and rpmsg (Remote Processor Messaging) frameworks for communication between the processors. The remoteproc subsystem implements basic house keeping for co-processors in Linux and the rpmsg framework implements the actual data channels.

Read more… (12 min remaining to read)

Using the M4 MCU on the i.MX8M Mini

giant-gd1d82756c_640.jpg

Over the last few years, SoCs targeted at embedded GNU/Linux applications became heterogenous architectures. Instead of adding more identical copies of CPU cores (Cortex-A class), a small companion micro controller core (Cortex-M class) was added. Compared to the complex architecture of Cortex-A systems, including their multi-layer caches, those cores are usually deterministic and thus predestined for low-latency "real time" jobs. NXP's first such SoC is the i.MX6 Solo X device featuring an Cortex-M4 next to an Cortex-A9 core. The i.MX8 family moved the Cortex-A cores into the 64 bit world and there are different combinations of Cortex-M companion micro controllers, but all of them do feature them as they are pretty "cheap" in terms of die space and transistor count.

From what I can see, it is still uncommon to use those micro controllers in actual projects though. Today I want to take a short look on how to run simple programs on the Cortex-M4 of the i.MX8M Mini SoC, especially we will use the official i.MX8M Mini EVK.

Read more… (21 min remaining to read)

Testing Preempt RT on the i.MX8MM SoC in 15 minutes

preempt-rt-logo.png

Looking at the kernel sources for NXP's i.MX8M SoCs, I noticed branch names like "lf-5.10.72-rt-2.2.0" and I wondered if NXP finally was going to offer RT preempt support within their BSP. Some other vendors have started supporting the patch set already a while ago but for NXP this is new.

In this post we are going to run this real-time enabled kernel on the i.MX8M-Mini evaluation board from NXP to get a first hand impression of what is required on the kernel level. We will not use the Yocto build system as this is only a wrapper around the distribution agnostic kernel development.

Read more… (8 min remaining to read)

Bmaptool - the forgotten joker

gnome-terminal-logo.png

The Yocto project has become a de-facto standard for Embedded GNU/Linux Systems and on many embedded systems the final image will be written to an SD card to be tested on the target board. Those images are meant to be written in one go and thus contain a partition table and multiple file systems. In preparing them, one usually chooses a suitable maximum size for the file system partitions and this will be the lower limit of the final image size no matter how much of this space is actually used. So without further tooling we will always be writing a lot of zeros not relevant for the system itself to the target medium.

Luckily enough there exists tooling for this use case and in this blog post I will show how easy it is to use bmaptool from the bmap-tools project to save time and wear on the SD card. On Debian systems installing the package is as easy as sudo apt install bmap-tools.

Read more… (4 min remaining to read)

Switching to maildir in Debian Bullseye

maildir.png

Although e-mail has lost some of its importance by the advent of secure messaging platforms like Signal, from time to time I still get the itch to improve my existing setup. Recently I wondered why I am still using a single file mbox instead of the more Unixy maildir format on my Debian desktop and how difficult it would to be switch. As we will see, the transition is pretty straight forward.

Read more… (3 min remaining to read)

Excursion into LXC containers

lxc1.png

As I like to live on the bleeding edge by using Debian testing (currently Bookworm), from time to time I run into situations that are not ease to solve from within the distribution. For example currently its impossible to install the yarn package manager:

dzu@krikkit:~$ sudo apt install yarnpkg
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 node-esprima : Depends: nodejs:any
E: Unable to correct problems, you have held broken packages.
dzu@krikkit:~$ 

As I do not see an easy way to fix this and as I am pretty sure that this will work in Debian stable, let's try spinning up an LXC Debian Bullseye container and work from there instead. The ultimate goal for today is to locally build and view the GNOME Javascript guide from a git clone to locally test modifications.

Read more… (9 min remaining to read)

Extending Bash Commandline with Bash Scripts

Bash logo

This blog post will show a very elegant way on how to easily extend the Bash command line with Bash scripts, or basically any command. The pivotal feature for all of this is the innocent looking function shell-expand-line accessible from GNU Readline used by Bash.

As we will see, this allows us to elegantly extend the Bash command line with our own hot keys. The screencast below shows a demo to archive a document just downloaded through Firefox tagged with a current date stamp. While entering the mv command, two hot keys are used:

  • Alt-l: Paste the least recently used file in GNOME

  • Alt-d: Insert a date-stamp at cursor position

Read more… (4 min remaining to read)

GSettings from GUI to Command Line

GNOME Logo

In GNOME, the user preferences are under the control of the GSettings subsystem. As GNOME is a graphical desktop, the usual form to interact with this is (doh) through a GUI. Recently I decided I want to mess with those settings also from the command line. Namely I wanted to quickly switch between disabling the screen blanking behaviour and its regular delay before activation. Changing this setting through the GNOME control center, requires me to grab the mouse, locate the control center, sift through all the menu options there trying to remember that it is below "Power" and finally changing it by using a drop-down menu. What I really want is a script called screenblank-toggle somewhere in my path. With such a script, I just type screenb <TAB> <Enter> without having to point the mouse or visually parse anything. The output tells me if the new situation is what I want and if not, <Arrow Up> <Enter> fixes it for good.

So to implement this, I need to find out what GSetting I am looking for.

dzu@krikkit:~$ gsettings list-recursively | wc -l
2662
dzu@krikkit:~$

Hm, maybe I can limit the search somewhat:

dzu@krikkit:~$ gsettings list-recursively | grep screen | wc -l
84
dzu@krikkit:~$

As I am too lazy to go through this individually, this small blog post shows a shortcut from the GUI to the command line without guessing names or reading documentation (ha ha).

Read more… (2 min remaining to read)

Taming The Serial Console

USB Debug port

Embedded Linux boards usually can be controlled through a serial port driven directly by a UART block of the SoC (System-On-Chip) at the heart of the board. Without hardware flow control, this interface uses only 2 pins (RX and TX) and the clock itself (baud rate) is generated independantly at both ends. Where such a port was usually exposed through a D-sub connector on older boards, modern boards use a USB-to-serial converter and expose the port on a regular USB micro plug. It is still a serial port, so this post applies to it equally well.

Once the boot-up sequence successfully reaches Linux shell, problems sometimes occur when the command line is very long and the terminal emulator window is larger or smaller than the standard 80 columns by 24 lines. In such situations, the display gets messed up and it is basically impossible to tell what command will be executed on pressing enter. Using ssh to login to a remote board, all of these problems will not even show up - so if you can use ssh you will circumvent the problems described in this post.

On a desktop Linux one usually fixes the problem of a mismatch between the internal representation of the terminal window size and the actual size like this:

dzu@krikkit:~$ eval `resize`
dzu@krikkit:~$

Unfortunatly, the resize program belongs to the xterm package and is thus usually not available on ressource limited embedded boards.

I pushed a small Python tool to codeberg.org which fixes the problem when you have Python3 available on the board.

Read more… (1 min remaining to read)

Too Many SSH Keys

Working with development boards in my local network, ssh started to act up on me when I try to log into one of them:

dzu@krikkit:~$ ssh user@ls1012afrwy
Received disconnect from 192.168.44.102 port 22:2: Too many authentication failures
Disconnected from 192.168.44.102 port 22
dzu@krikkit:~$

This blog post explains why this is caused by seemingly unrelated actions and how to fix it. Before going into the details I will examine the context leading up to this problem.

Read more… (3 min remaining to read)