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 resources 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 (https://www.spinics.net/lists/arm-kernel/msg656955.html) 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 transferred 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.

MIPS

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 kernelci.org.