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.
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.
Wir wollen zum Bundesweiten Digitaltag am 18.6.2021 das Thema "Smarte Städte" ein bisschen von der technischen Seite beleuchten, aber keine Angst: es bleibt für alle verständlich.
"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
Now that, due to the COVID-19 pandemic, everyone has gotten used to digitalisation and online conferences - it has never been easier to organise a conference and bring together all experts and interested parties for a few hours of intensive exchange of ideas on a certain topic.
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.
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.
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.
One of our projects required the addition of board support for the Digi ConnectCore 6UL SBC Pro to the Barebox bootloader. This article outlines the used development setup and required additions to the bootloader to support a board with a well supported processor. Development of the board support was done live during the monthly talks at Stratum 0, the hackerspace in Braunschweig. The video (in German) is embedded at the end of the article.
Some days ago, Greg Kroah-Hartmann wrote a great blogpost about Which Stable Kernel One Should Use?. I fully agree with his position; however, I'd like to make some additions for the industry device manufacturer use case and some common pitfalls and misunderstandings we see in that area.