Pengutronix TechWeek 2018: Cortex-M Coprocessor and MIPS

Running Linux on M4 Coprocessor on i.MX7

Several i.MX SoC versions, for example i.MX7D, i.MX6SX and the i.MX8 derivates are asymmetric multiprocessing (AMP) systems: They have at least one ARM Cortex A core and at least one ARM Cortex M core.

Most people run a small microcontroller operating system on it; however, there are usecases that make it interesting to run uCLinux instead: Linux has sophisticated drivers even for the more complex hardware units (think of ethernet and TSN, or digital audio cores), and technology is complex enough that we don't want to duplicate all bugs and challenges in different operating systems. Some years ago, Pengutronix brought Cortex-M support into the mainline kernel, but so far there are not many single-chip Cortex-M devices with enough RAM to make it useful. Modern AMP systems might change this.

Last year, at TechWeek 2017, I wrote an imx-remoteproc driver to allow starting some code on the Cortex M system as a proof of concept. To make it more interesting, thanks to effort of Uwe Kleine-König, we were able to run a second Linux image on the Cortex-M4 as well. However, the code was quite hacky; basically as there was no sane concept about sharing and distributing ressources like clocks and pinmux settings. So we went back to the blackboard and brainstormed about possible mechanisms. It turned out that a good design could work in a way that a 'primary' CPU takes care about all the clock and pinmux handling, while a 'secondary' CPU talks to it via some messaging API in order to claim clocks and pins.

My challenge for the current TechWeek was to prepare basic communication between two Linux instances. i.MX7D is providing a Messaging Unit (MU) that can be used as a doorbell with shared memory for huge messages, or as a pipe for 4 bytes which can be transferred over the MU HW directly.

I implemented a mailbox driver based on the kernel's mailbox framework for i.MX MU ( and used the same driver on both sides of the SoC. The mailbox-test driver was used on top of imx-mailbox driver to send a message over shared memory and MU doorbell.

In the screenshot on the left, Linux is running on the Cortex-A7 of an i.MX7D on the left side and a second linux instance is started with the help of the imx-remoteproc driver on the Cortex-M4 of the same i.MX7D SoC on the right sight. In this example, the message was transfered from the A7 to the M4.

The actual interface for pinmuxing and clock needs to be written, but as always, the idea of TechWeek projects is to have an incubator to demonstrate new technologies. Hopefully, we'll find a usecase in one of our next customer projects.


Another target of last TechWeek was my personal hobby project – Freifunk. Most of Freifunk hardware is usually based on some variant of Qualcomm Atheros Wireless SoCs running LEDE/OpenWRT modification. Most hardware support for this SoCs is not upstream which makes long term maintenance and kernel updates difficult. One of the reasons why many drivers and patches are still not in kernel mainline is the lack of a developer friendly environment. For example there is no unified boot loader combining the following futures:

  • maintained upstream, with working support of Qualcomm Atheros WiSoCs
  • support of latest MIPS UHI boot protocol
  • working with kernel images just produced by kernel vanilla source three without additional image preparation (for example converting to uImage).

While barebox was already ported to different Qualcomm Atheros WiSoCs and works as first stage boot loader, we still missed proper MIPS Kernel boot support. In the last days of the TechWeek, I prepared a minimalistic ELF parser with MIPS ELF boot handler which was accepted mainline just today (2018-06-08)

As a result of this work, we prepared a DPTechnics DPT-Board based on Atheros AR9331 WiSoC which should from now on be used as first ever MIPS based SoC tested within

Further Readings

Chemnitzer Linux-Tage 2023

After the Corona break, the Chemnitzer Linux-Tage will actully take place in real life again, and the Pengutronix team will have eight (!) talks there.

DSA in Barebox

The v2022.05.0 Release of barebox introduced initial support for the Distributed Switch Architecture (DSA) Framework. DSA is originally a subsystem from the Linux Kernel, which exposes the individual ports of a network switch IC as virtual network interfaces.

Netdevconf 0x16

After a longer time with online-only events, the Netdev 0x16, a conference about the technical aspects of Linux Networking, was organized as hybrid event: online and on-site at Lisbon.

Pengutronix at Electronica in Munich

This year Pengutronix again has a Booth at the Electronica trade fair in Munich, Germany. You find us in Hall B4 Booth 104 (map).

Pengutronix Kernel Contributions in 2021

2022 has started, and although Corona had a huge impact on our workflow, the Pengutronix team again made quite some contributions to the Linux kernel. The last kernel release in 2020 was 5.10, the last one in 2021 was 5.15, so let's have a look at what happened in between.

Pengutronix at FOSDEM 2021

"FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels. In 2021, they will gather online." -- FOSDEM

15 Years of i.MX in Mainline Linux

Today it has been 15 years since we mainlined support for Freescale/NXP's i.MX architecture in the Linux kernel! That was one small step for [a] man, one giant leap for (industrial Linux users') mankind :-) Here is some background about why it happened and what you might want to learn from history for your next embedded Linux project.

Foster mvebu Support in barebox

barebox works great on NXP's i.MX platforms. While there is some support for Marvell's mvebu platform, it is not even near being complete. The main limitation is in my eyes that there is no code to initialize RAM settings on these machines.

Bootstrapping Arria10 with OpenOCD and barebox

The Arria10 SoCFPGA can boot from multiple sources: SD Card, NAND flash, QSPI flash and eMMC, that can be selected via the BSEL pins. If the bootrom can not find a valid bootloader on that medium, it will fall back to JTAG. So for developing and testing, the BSEL pins can just be set to a medium that is non-existent. In case of bootstrapping, the bootrom falls back to JTAG anyway, as there is no valid bootloader, yet.