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 (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 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.

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.


Weiterführende Links

umpf - Git on a New Level

Moderne Softwareentwicklung ohne begleitende Versionsverwaltung wie Git ist heutzutage unvorstellbar - Änderungen am Quellcode sollen schließlich nachvollziehbar dokumentiert und beliebige Verssionsstände jederzeit einfach reproduziert werden können. Für Arbeiten an komplexeren Projekten wie etwa dem BSP ("Board Support Package") eines eingebetteten Systems mit mehreren Entwicklungssträngen skaliert ein bloßes Aufeinanderstapeln der einzelnen Änderungen jedoch nicht.


FrOSCon 2023

In ein paar Stunden beginnt die 18. FrOSCon an der Hochschule Bonn-Rhein-Sieg. Pengutronix ist wieder mit einem kleinen Team vor Ort. An einem der Partner-Stände zeigen wir wieder einige unserer Aktivitäten in der Open Source Community. Dafür bringen wir unseren labgrid Demonstrator und die FPGA Demo mit.


DjangoCon Europe 2023

Django ist Pengutronix' Framework der Wahl für Software zur Abwicklung unserer Geschäftsprozesse. Diese internen Werkzeuge bieten zudem auch immer die Gelegenheit neuere Entwicklungen im Django-Universum auszuprobieren.


Chemnitzer Linux-Tage 2023

Nach der Corona-Pause finden am 11.+12.03.2023 die Chemnitzer Linux-Tage in diesem Jahr wieder vor Ort statt, und das Pengutronix Team ist mit acht (!) Vorträgen im Programm vertreten.


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.


Die Pengutronix Kernel-Beiträge in 2021

2022 hat begonnen, und obwohl Corona unsere Workflows stark verändert hat, hat das Pengutronix Team auch in diesem Jahr wieder etliche Beiträge zum Linux-Kernel geleistet. Das letzte Kernel-Release in 2020 war 5.10, das letzte in 2021 war 5.15 - schauen wir also, was sich dazwischen bei uns getan hat.


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


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.