If you want to develop software for MNT Reform, there are a few things to consider. You can write software targeting the main CPU or modify firmware for the system controller and input devices. All of these have different architectures. Keep in mind that the main CPU is modular, though targeting 64-bit ARM (aarch64) is a good bet until upgrades with other architectures become available (for example, RISC-V). This chapter covers development for the default i.MX8MQ module and some general best practices to keep your software portable.
The i.MX8MQ SoC has the following CPU cores:
4x Cortex-A53 at 1.5 GHz
1x Cortex-M4F at 266 MHz
At the time of writing, the integration of the M4 core into mainline Linux is not production-ready.
Linux (or another operating system) runs on the four Cortex-A53 cores. Cortex-A53 is a power efficient in-order core. This makes it less performant but also immune to certain security weaknesses of out-of-order processors, for example Meltdown. 1
Optimizing your program to make use of multiple cores versus relying on single-core performance will pay off on MNT Reform. Also, make use of SIMD (NEON) optimizations. Try to keep memory usage and UI effects minimal. If your application runs well on MNT Reform, it will run well on a broad range of older PC hardware, but also on single board computers such as the Raspberry Pi.
A popular architecture for PCs and laptops is x86_64 (aka amd64). Binaries compiled for this architecture are incompatible with ARM processors. If you want to use binary software (or dependencies/modules), you have to make sure that these are built for aarch64. The vast majority of open-source software is available for aarch64, but there can be subtle problems when x86 is implicitly expected, for example:
Optimizations written in assembler (machine code), targeting specific SIMD/vector instructions
JIT (just-in-time) compilers
Docker images built for x86_64
Generally, instead of using inline assembler or targeting a single architecture directly, use cross-platform libraries and code-emitting backends. Examples are LLVM and GLM.
The embedded GPU in i.MX8MQ is a Vivante GC7000L. It can theoretically support OpenGL ES 3.1, but the open-source Etnaviv drivers (included in the Mesa project) don’t support this level at the time of writing. The safest target for 3D graphics is OpenGL ES 2.0. Desktop OpenGL 2.1 API support is good, too. There is no support for Vulkan nor OpenCL yet.
If you want to make sure your 3D application or game works well, target:
OpenGL ES 2.0, GLSL ES 1.00 (recommended)
OpenGL 2.1, GLSL 1.20
Tested and recommended libraries/frameworks are:
GTK 3/GTK 4
Qt 5/Qt 6
Godot Engine (targeting GL ES 2.0)
Text-based interfaces (TUIs)
Wayland works better than Xorg directly, but Xorg applications work well on top of Wayland through Xwayland or Xephyr.
i.MX8MQ includes hardware accelerators for decoding H.264, H.265, VP8 and VP9. At time of writing, support for H.264 decoder (“Hantro”) just landed in the Linux kernel with fully open source drivers, accessible through the gstreamer library.
The audio output defaults to 48KHz stereo. You can also sample from one microphone input channel (part of the CTIA standard TRRS headset jack) or the stereo Line In header on the motherboard (J21).
You can use the ALSA API directly or higher level APIs such as PulseAudio, Jack or OpenAL.
Applications that use web browser engines (such as Electron) can disappoint in terms of performance on MNT Reform. Programs using native toolkits will run faster, use less memory and provide a better user experience.