RoadTest: MaaXBoard Single Board Computer + Accessories
Author: pphilippos
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Raspberry Pi 3 B/B+, Ultra96, Raspberry Pi 4
What were the biggest problems encountered?:
Detailed Review:
A Roadtest for the Maaxboard single board computer and a mini tutorial (Cortex-M4)
Introduction
At a first glance, this is a promising single board computer, with a numerous I/O ports and features, applicable to a variety of exciting projects. Performance-wise, it lays between a Raspberry Pi (RPi) 3B/3B+ and a RPi 4 (closer). This is because the featured system-on-chip (NXP i.MX 8M) combines four ARM A53 cores, which are considered mid-range, just like the RPi 3B/3B+ (plus a Cortex-M4, more on that later), while the RPi 4 features four A72 cores, which are higher-end. Maaxboard’s A53 cores are clocked in the middle between the two RPi 3 B iterations (at 1.3 GHz), while having more and faster memory, similarly performing to that of RPi4.
As seen from the picture, the layout seems well-thought overall, with a full-sized HDMI, two USB 3.0, gigabit Ethernet and a fast WiFi ac module. For embedded applications and hobbyist projects there are also the raspberry-pi GPIO, display and camera connectors, as well as an unusual high-fidelity connector for audio (SAI).
One consideration is that the SD card reader may be too close to the processor, which could impact the card’s lifespan. Additionally, while the GPIO is RPi-compatible, the pre-installed heatsink doesn’t leave room for Pi hats to be installed without an extension cable. I would recommend a small fan for keeping the operating temperature low.
Software
The only currently-available card image is Debian Linux. Android and Windows 10 IOT are coming soon. The default image comes with Weston as a Wayland-based desktop environment. As a Linux user myself, I found Weston to be incomplete in comparison with other environments, at least this version. So, I installed Xfce straight afterwards. Note that with Xfce (Xorg-based), you currently loose some video acceleration features.
It is convenient that it ships with Debian, having tens of thousands of available packages to install. One modification for the packager manager, needed to perform well world-wide, is to update the /etc/apt/sources.list file to the following. This allows it to search the best mirror rather than the default (in Tsinghua University, China).
deb http://deb.debian.org/debian buster main contrib non-free
deb-src http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian buster-backports main contrib non-free
deb-src http://deb.debian.org/debian buster-backports main contrib non-free
I personally prefer it to Raspbian. Although Raspbian is very well-maintained (see stats in https://repology.org/repositories/graphs ), I like it being close to the source distribution, and following more conventional configuration. For example, after installing Xfce, I had the opportunity to use the NetworkManager applet without any additional effort or relying on a manufacturer (rather than using the recommended bash routine). Another example on why this Linux image is better, is that it is a 64-bit operating out-of-the-box, while Raspberry Pi 4 is still trying to catch up for fully supporting its memory for its 4GB version (https://www.balena.io/blog/balena-releases-first-fully-functional-64-bit-os-for-the-raspberry-pi-4/ ). A straightforward way to verify that the user-space is 64-bit is to run the following command for an application (e.g. having installed gnuplot on some linux distribution): od -An -t x1 -j 4 -N 1 /usr/bin/gnuplot. A result of “1” would represent a 32-bit binary, “2” is for 64-bits. ( source: https://superuser.com/questions/791506/how-to-determine-if-a-linux-binary-file-is-32-bit-or-64-bit ). Nevertheless, for first-time users, Raspbian on a Raspberry would still be recomended for its user-friendliness.
Some issues probably relating to bugs requiring fixing: inability to resume from standby, WiFi hopping IP addresses, cannot use WiFi channel 13 and the USB3.0 transfers speeds are a bit suboptimal.
Performance
Maaxboard’s main CPU core cluster contains four ARM Cortex-A53 cores @ 1.3 GHz, which are considered mid-range and are featured in many similar boards. It also has a Cortex-M4 (see next section). I personally own a RPi 3B (SoC: Broadcom BCM2837 featuring 4 A53 @1.2 GHz), an Ultra96 (MPSoC: Xilinx ZU3EG with an FPGA + 4 Cortex-A53 @ 1.2 GHz + 2 Cortex-R5). If we ignore the real-time processing cores (R5, M4) and additional features (programmable logic, WiFi speed, etc.), we get a similar platform to run Linux on.
Theoretically, the CPU performance under Linux should be very similar across the three boards (Ultra96, RPi 3 B and Maaxboard) as the cores have the same micro-architecture. One exception in is Raspberry PI’s 512KB L2 cache, while the others have an 1MB of L2 cache. For the moment we can ignore the small difference in operating frequency. It could also be easily adjustable, with a similar mindset of overclocking a desktop PC (e.g. my Ultra96 is stable at 1.5 GHz, but not at 1.6).
However, the relatively-high-end RAM featured on Maaxboard can make a difference on memory-intensive applications. Therefore, it would be interesting to see how Maaxboard’s RAM configuration compares with similar boards. I used STREAM, “the de facto industry standard benchmark for measuring sustained memory bandwidth.” ( https://github.com/jeffhammond/STREAM ).
As we can see, Maaxboard achieves the best result across the tested boards and is faster by a large margin (~2x). Here, it is important to note that Ultra96 is specially configured for accommodating the FPGA, and I have seen it perform at 3.5 GB/s with a single direct memory access (DMA) engine on the FPGA. But as a Linux machine, Maaxboard seems the best option among the three.
This result for Maaxboard seems similar to the result of Raspberry Pi 4 from MagPi ( https://magpi.raspberrypi.org/articles/raspberry-pi-4-specs-benchmarks ) that used a similar benchmarking tool RAMspeed/SMP ( https://github.com/cruvolo/ramspeed-smp ). The “copy rate” from STREAM can be seen roughly as a combination of read and write speeds in one metric. From this set of results, we can also estimate that Maaxboard will also have around 2x the memory speed over RPi3B+ as well.
With respect to comparing CPU to CPU, I couldn’t find any benchmark suite that was practical/representative enough: open-source, multi-core, well-rounded, small-enough to fit on small SD cards, easy-to-install and without the necessity to buy a license for publishing results. For example, sysbench ( which was used by MagPi for similar purposes in the past https://magpi.raspberrypi.org/articles/raspberry-pi-3bplus-specs-benchmarks ) reported RPi3 being ~11.5x slower than Maaxboard, while other benchmarks ranked it similarly along with Ultra96, which is what someone would expect. If we ignore the L2 cache difference, such exploration should normally be “boring” for such a similar architecture.
Update: I also provide some indicative CPU benchmark results. The first suite is the C version of SciMark ( https://math.nist.gov/scimark2/download_c.html ) for floating-point/ single-thread performance, as run by the phoronix-test-suite ( https://openbenchmarking.org/test/pts/scimark2 ). There is also one set of results for a multi-threaded application, also using the same command as run by the phoronix-test-suite ( https://openbenchmarking.org/test/pts/stockfish-1.1.1 ). The GCC version is the same across all compilations (8.3.0).
The general observation is that the performance is relatively similar, with some exceptions probably relating to the working set/ cache size, as the RPi3 has half the L2 cache size, or from being memory-intensive, where MaaXBoard performs better.
Cortex-M4 core (mini-tutorial)
This is a "hidden gem" inside the Maaxboard, not found in most RPi-like SBCs. It is a real-time processor for signal processing (such as for building a low-latency music synthesizer (I am not sure if it has that power)) and it is well-integrated inside the rest of the system. For example, you could do embedded system development using FreeRTOS, at the convenience of using the rest of the 4 A53 cores for your everyday Linux experience. The core is specifically a M4F, where F stands for having a floating-point unit and runs with a clock frequency of up to 266 MHz (to be confirmed). Therefore, although a small core, there could be interesting applications, mainly purposed for prototyping.
For the hobbyist, it is nice that experimenting with a different kind of core is available at their fingertips. There is some additional effort required to access it, such as rebooting the board for loading an appropriately-compiled binary. Currently, there is no official support, so there are some modifications that need to be made. I currently managed to edit and load one of the demo programs for a similar board based on the same SoC. The only part missing for a complete demonstration would be to connect with the “M4 debug console”, which is supposed to communicate with another UART interface.
The first step is to generate a custom binary. In order to do that we need download some FreeRTOS demos for a similar platform (imx8m-som), named “Emcraft FreeRTOS BSP layer” from here ( https://www.emcraft.com/products/868#software ) (a free Emcraft account is required). We also need to download a customised SDK (MCUXpresso Software Development Kit) for another similar platform (e.g. evkmimx8mq) from here ( https://mcuxpresso.nxp.com/en/welcome ) (a free NXP account is required). After we extract both folders, we move the boards/imx8m-som folder from the BSP to the equivalent SDK hierarchy (inside SDK/board). The example that we are interested in is located inside the directory imx8m-som/multicore_examples/rpmsg_lite_str_echo_rtos/. The idea of this example is to repeat any text that it is sent to it, via Maaxboard’s kernel module “imx_rpmsg_tty”. My modification was in the file “main_remote.c”, where I added the following line inside the main loop to replace any string with a custom message.
strcpy(app_buf,"Hi Philippos!\0");
After we compile the binary (rpmsg_lite_str_echo_rtos_imxcm4.bin), we copy it to Maaxboard’s /boot/ directory. Being inside the /boot directory, is now the opportunity to manually edit the device tree (.dtb file) using the “device-tree-compiler” (can be found in apt-get). The following edit is required to enable the correct shared common memory region for the different cores to communicate with each other. We find and modify the rpmsg-related entries as shown below.
rpmsg@0x58000000 {
no-map;
reg = <0x00 0x58000000 0x00 0x400000>;
linux,phandle = <0x44>;
phandle = <0x44>;
};
[...]
imx_rpmsg {
compatible = "fsl,rpmsg-bus\0simple-bus";
ranges;
rpmsg {
compatible = "fsl,imx8qm-rpmsg";
status = "okay";
vdev-nums = <0x01>;
reg = <0x00 0x58000000 0x00 0x10000>;
};
};
The next step is to load the binary for running on the Cortex-M4 core. The idea is to interfere with the default U-boot routine, before the device starts to boot Linux. I used my Raspberry Pi as a headless server to access Maaxboard’s UART using a regular USB to TTL Serial Converter, as shown in the picture below ( inspired by https://www.hackster.io/monica/getting-started-with-maaxboard-headless-setup-24102b ).
By running the following command on the host (the Raspberry Pi in my case), we can gain access to the serial console through terminal.
sudo stty -F /dev/ttyUSB0 cs8 -cstopb -parenb -brkint cread crtscts ; sudo screen /dev/ttyUSB0 115200
We hit any key on the keyboard to enter the required command for loading the binary. Finally, we type “boot”, to continue with booting Linux.
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
u-boot=> fatload mmc 0:1 0x7e0000 rpmsg_lite_str_echo_rtos_imxcm4.bin; bootaux 0x7e0000
17088 bytes read in 17 ms (981.4 KiB/s)
## Starting auxiliary core at 0x007E0000 ...
u-boot=> boot
After Linux has booted, we load the appropriate kernel module and observe the output along other kernel messages, using dmesg. As soon as loading the driver (“imx_rpmsg_tty”), if everything went fine, we get some responses in the command line.
user@maaxboard:~$ sudo modprobe imx_rpmsg_tty
[sudo] password for user:
[ 79.040451] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: new channel: 0x400 -> 0x1e!
[ 79.049714] Install rpmsg tty driver!
user@maaxboard:~$ sudo bash -c "echo to_be_replaced > /dev/ttyRPMSG30"
[sudo] password for user:
user@maaxboard:~$ dmesg | tail -3
[ 79.060676] rpmsg_tty_cb48 69 20 50 68 69 6c 69 70 70 6f 73 Hi Philippos
[ 131.764612] rpmsg_tty_cb48 69 20 50 68 69 6c 69 70 70 6f 73 21 00 Hi Philippos!.
[ 131.769769] rpmsg_tty_cb48 69 Hi
By default, the driver sends a “hello world” string to the M4 core. This is the reason that we see two times the custom message in our example.
This was a first step towards developing for the M4 core using Maaxboard.
Conclusion
Maaxboard is a very interesting board, and adaptable to a variety of projects. It combines modern ports and connectivity with a more interesting set of cores than competitors. The close-to-upstream Linux distribution has its advantages, and more experienced users will find this platform ideal for many uses.
Disclaimer: There may be factual errors. If you find one, please mention it in the comments. Thanks
Top Comments
Nice road test report.
DAB