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 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.
Further Readings
Pengutronix at FrOSCon 2024
On August 17th and 18th, 2024, it's that time again: FrOSCon will take place at the Bonn-Rhein-Sieg University of Applied Sciences in Sankt Augustin - and Pengutronix will be there again as a Partner.
Pengutronix at Embedded World 2024
Meet Pengutronix at the Embedded World 2024 in Nurnberg! You find us, as always, in hall 4, booth 4-261. As usual, we will be showing demonstrators on current topics at our exhibition stand.
umpf - Git on a New Level
Modern software development is commonly accompanied by a version control system like Git in order to have changes to the source code being documented in a traceable manner. Furthermore, any version state should be easily reproducible at any time. However, for work on complex projects such as the BSP ("Board Support Package") of an embedded system with its multiple development aspects, the simple stacking of the individual changes on top of each other does not scale.
FrOSCon 2023
In a few hours, the 18th FrOSCon will begin at the Bonn-Rhein-Sieg University of Applied Sciences. Pengutronix will be there again with a small team. At one of the partner booths we will show some of our activities in the open source community. We will bring our labgrid demonstrator and the FPGA demo.
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.
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
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.