i.MX 8 Full-Chip Virtualization — What We Know So Far (September 2018)

Published in

Hi-Z Labs

6 min readSep 8, 2018

i.MX 8 Quad Series Info (from Design the Car of the Future)

[Note: updates at the end, most recent 11/Sept/2018]

You know, I feel a little teased by i.MX 8. The decade is almost over, and even though i.MX 8 has been coming up in search results for most of it, we’re still using something else because the i.MX 8 boards aren’t available yet.

I suppose that’s not really true; there are i.MX 8M modules out there. But it seems like the prominent names have had “coming soon” listings up for years for i.MX 8 modules (I’m peeking at the sites of trusty Toradex and evasive Variscite right now). It’s not scientific at all — I just feel like these boards are never actually coming. Anyway, enough complaining, let’s talk about something interesting.

Recently a customer asked me about the full-chip virtualization features on the i.MX 8 processors, and honestly I hadn’t heard anything about it. But being a good consultant, I’d never leave it at that. So I got myself educated, at least enough to respond intelligently.

Applications can ‘sand-box’ operations by moving hardware IP such as GPU, display or peripherals to multiple firewalled domains at run time. — NXP i.MX 8 Family Fact Sheet

Wikipedia’s got some good timeline info on the i.MX page. Some things to note:

September 2013: i.MX 8 series development was announced, 5 years ago — so was the i.MX 7 series, actually. The i.MX6 series was announced only 2.5 years earlier. This suggests that the i.MX 8 is quite a bit more ambitious than the others/predecessors.
May 2016: the “Multisensory Enablement Kit (MEK)” became “available”. Good luck finding one. “Contact your NXP sales representative for details.”
October 2016: i.MX 8 series is announced to be available “Q1 2017”
January 2017: i.MX 8M series is announced to be available in limited sampling quantities Q2 2017 and generally available Q4 2017
September 2018: dev boards with i.MX 8M boards now generally available, but dev boards with i.MX 8 are not.

The inquiry posed to me came with a link to the i.MX 8 Family Fact Sheet, asking about the hardware-level “firewalling” between cores. The fact sheet mentions that “applications can ‘sand-box’ operations by moving hardware IP such as GPU, display or peripherals to multiple firewalled domains at run-time.” From there I drummed up some application info that yielded some additional nuggets that give us some idea as to how this all works.

Some key docs (NXP login may be required)

Some informative info regarding Linux, U-Boot, and Yocto support

Observations and Analysis

I’ll highlight the gems here, but do take a peek at some of the links, especially the first two under “Some key docs”. In Design the Car of the Future, NXP illustrates how they envision the hardware partitioning scheme to be used.

Honestly, if/when they deliver, this will be an amazing chip for industrial, automotive, and even avionics/aerospace. Where currently there would need to be complex supervisor systems monitoring and arbitrating redundant processors, it now can be done all on the chip. Sure, you’re still going to need to have something on top of that in safety-critical applications, but this does open up a number of applications where you just need a guarantee that some invalid memory access won’t corrupt a peripherial or crash another core running a different application.

For engineering types who need to think about how to actually apply the technology, the key nugget is the “i.MX 8 System Controller”. This is firmware that will run on one of the two Cortex-M4 cores, and provides an API that software on the other cores can (must?) use to access shared resources.

Now that we have a phrase we can type it into the Internet and see what’s out there. Introduction to the i.MX8 System Controller Unit peels away another layer.

The SCU…

handles boot management, power management, clock and reset management, IO configuration and multiplexing, and resource partitioning and access control
communicates with application domains via an API library that uses remote procedure calls based on an inter-processor communication mechanism
boots from ROM, loads firmware (from boot media??)
reads an initial loading region from the selected boot media (presumably selected by boot config pins). This region contains some startup config info (for initializing memory and whatnot), IP partitioning information, and boot data structures for each application domain
mediates boot process and starts other cores

i.MX8 High-level boot sequence (from Introduction to the i.MX8 System Controller Unit)

For an operating system to support the chip, it will need to use the SC API. We can see from the links under “…Linux, U-Boot, and Yocto support” that this work is already being done or (probably) is already finished. From what I can tell, the operating systems must use the SC API to access shared resources, so without this support baked into whatever OS you want to run, you won’t be running that OS on this chip.

Lastly, I direct our attention to the Toradex Apalis iMX8. Who knows how much it will cost, but probably a lot — at least when compared to those AllWinner modules that crash from overheat unless you clamp two pounds of aluminum to them and will be available until stock runs out or any time forever if you are willing to buy at least 50k units and — whoops, forgot to debounce the “COMPLAIN_ENABLE” switch. The Apalis iMX8 isn’t available yet, but they do specifically mention “multiple OS deployment with heterogeneous multi-core architecture”. If these guys are advertising this feature, then we can be pretty sure that once it comes out, it won’t be hard to use. Toradex is currently advertising “Q4 2018” release of the board.

Unanswered Questions

T̶h̶e̶ ̶s̶y̶s̶t̶e̶m̶ ̶c̶o̶n̶t̶r̶o̶l̶l̶e̶r̶ ̶f̶i̶r̶m̶w̶a̶r̶e̶…̶w̶i̶l̶l̶ ̶i̶t̶ ̶b̶e̶ ̶o̶p̶e̶n̶ ̶s̶o̶u̶r̶c̶e̶?̶ ̶(̶p̶r̶o̶b̶a̶b̶l̶y̶ ̶n̶o̶t̶)̶ ̶H̶o̶w̶ ̶w̶i̶l̶l̶ ̶w̶e̶ ̶g̶e̶t̶ ̶i̶t̶?̶ See updates section below. The SC firmware is closed source and will be available as binary only. There is at least one binary available in the wild now.
How complicated will the boot media be?
How granular is the access control? i.e. can individual GPIO pins be assigned?
What sort of guarantees are being built into the ‘sand-box’ operations/firewalled domains? How is it tested?

Tommy Boy understood guarantees. (from MemeGenerator)

Summary

I don’t know when we’ll be able to start building this into our products, but it promises some pretty cool possibilities. The failsafe applications demonstrated in Design the Car of the Future will both save a ton of hardware as well as make some designs feasible that would have been too expensive to build (if even possible). I for one can’t wait to get my hands on one of these boards.

Updates

September 11, 2018

The i.MX8QM looks to have a working name of i.MX8dv

The meta-freescale OE layer has updates for i.MX8QM

The imx-mkimage utility has support for i.MX8QM. Note “i.MX8dv” as well as scfw_tcm.bin (which is an interesting term to search)

[PATCH] imx8qxp_mek: add README

This patch is for testing i.MX8QXP patchset [PATCH V2 00/32] i.MX: Add i.MX8QXP support
https://lists.denx.de/pipermail/u-boot/2018-July/335079.html
The board is using B0 chip, A0 chip is not being supported.
Please help test if you are interested. I’ll post out V3 after collecting
more comments.
Sadly, I do not know where to download scfw_tcm.bin in public for B0 QXP.

AN12212: the system controller firmware is not open (and other technical details).

You can find the SC-firmware binary at tmp/work/imx8qxpmek-poky-linux/imx-sc-firmware/0.2- r0/imx-sc-firmware-0.2/. The source code is not open, and you use the binary directly. You need this binary, when you package the images using mkimage tool.

Trusty Toradex comes through for us: Build Apalis iMX8 Boot Image/Linux from Scratch. This link has actual build instructions and a link to a downloadable scfw_tcm.bin. What we don’t see yet is booting two independent OSs on one chip.