The MarS single board computer is a solid, though more expensive, alternative to the BeagleBone Black and Raspberry Pi for your DIY hardware needs. At a minimum, it offers two headers, each with two columns of pin holes — perfect for just playing around. Another stand out feature is the touch screen kit which makes the MarS a great platform on which to build a custom tablet, for example.
At the heart of the MarS is a dual core Freescale i.MX6 Cortex-A9 with the Vivante GC2000 graphics processor. The board has 1 gigabyte (GB) of RAM and 4 GB of eMMC storage, many screen outputs including LVDS and HDMI, multiple USB 2.0 ports, gigabit LAN, and many other ways to interact through its headers like SPI. With the MarS kit, LVDS is a first class citizen, with a 9.7-inch LVDS multi-touch screen available.
We’ll take a look at the combination kit, which includes the MarS board with an additional 9.7-inch LCD that runs at 1024×768 and is capable of multi-touch input. The MarS itself goes for about $100 while the combination kit is around $290.
The 9.7-inch screen comes in what some might consider to be a tablet shell. The single LVDS cable is enough to provide both signal and power to the display. The multi-touch information is also sent back over the LVDS cable making it a single cable solution.
This might be a great combination for somebody who wants to build a custom tablet including a small board of chips that are accessed from the expansion headers of the MarS. Just add a battery and strap things to the back of the screen to build a rather thick, but custom and inclusive tablet! This leaves open the possibility of getting dual display on the LVDS and HDMI going at the same time so you can drive external screens as needed.
Android on the MarS
I took a look at what came already loaded onto the 4 GB of eMMC by connecting an HDMI screen, plugging in the MarS and letting it boot. This presented Android version 4.0.4 with a model number of ICS AOSP on imx6q. Turning things off, plugging in the external 9.7-inch touch screen, and powering on again I got a red light in the top right of the screen enclosure and some backlight but no signal. A power down and disconnect of the main HDMI didn’t magically move the primary Android display over to the external 9.7-inch toucscreen. You have to do a tiny bit of tinkering on the serial console to get the LVDS screen going with Android.
The mini USB port next to the network connector can be used to get a serial console to your MarS board. Hitting a key during the 3-second count down before boot, you can adjust the boot parameters. To get the 9.7-inch touch screen working you have to interrupt the boot procedure and run the below modification which I’ve mostly taken from the MarS user manual. There are seven different screen settings shown in the user manual for a few different external screen sizes (smaller LCDs and the 9.7-inch LVDS touch panel) and also HDMI. If you are running Android the manual also mentions support for running both an external screen and HDMI at the same time in a dual display mode. This setting is stored into persistent memory by the MarS, you can reset it to the default with the run clearenv command.
Board: MX6Q-MARSBOARD:[ WDOG] Boot Device: I2C I2C: ready DRAM: 1 GB MMC: FSL_USDHC: 0,FSL_USDHC: 1 ... Net: got MAC address from IIM: 00:00:00:00:00:00 ----enet_board_init: phy reset FEC0 [PRIME] Hit any key to stop autoboot: 0 MX6Q MARSBOARD U-Boot > setenv no_console_suspend 1 MX6Q MARSBOARD U-Boot > setenv bootargs console=ttymxc1,115200 init=/init rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 fbmem=10M vmalloc=400M androidboot.console=ttymxc1 MX6Q MARSBOARD U-Boot > saveenv MX6Q MARSBOARD U-Boot > boot
The updated Android image is still version 4.0.4 of Android. Multitouch on the LVDS screen works as expected and zooming images in the gallery is nice and responsive. You will have to copy over any images for testing as the default Android distribution for the MarS is quite spartan.
With the MarS running Android, I plugged a USB cable into the OTG mini USB port on the MarS and the other end into a desktop Linux machine and I could then mount the MarS as a filesystem. So getting data to and from the MarS became fairly simple. Unfortunately, once the device goes into sleep mode I couldn’t work out how to bring it back to life other than using the reset button. While the screen has positions for some side buttons, without any hardware buttons I couldn’t think of a simple way to wake up stock Android again. There are apps for allowing wake up without hardware buttons of course.
Loading Linaro onto the MarS
The latest official release for the MarS is Linaro 11.10 (development branch).
Unfortunately the procedure for using a desktop Linux machine to update the MarS to a newer version of Android or changing the MarS over to Linaro isn’t shown in the MarS manuals. I used the mfgTool program to write the Linaro image to the flash on the MarS board. The tools are also available from Embest Tech. A word of caution here: If you were using the serial console to log in to the MarS you need to move the mini USB cable over to the OTG port (next to the HDMI port) in order to use mfgTool to update the MarS. I left the USB cable on the serial port and it took a while to work out this mistake.
To load an image, one of the jumpers (D2) on the MarS has to be switched to “On” and the board reset. After flashing, you need to reset that jumper back to “Off” and reset the MarS to boot into your new system. Refer to about page 30 of the User Manual for more information.
While there is nothing wrong with mfgTool, it would be nice to be able to flash the Linux image on the MarS from a desktop Linux machine.
Getting touchy under Linaro
Although the MarS documentation doesn’t mention support for running the LVDS under Linaro, I found that the above command which enabled the display on Android also enabled it on Linaro. Though at first I had no touch screen ability.
Digging around the git repository for the kernel used by the MarS I found the following commit:
commit 4006c19c6beda96a0bd5855a1ab27a7b2e380cb5 Author: luofuchong Date: Thu Oct 24 15:10:09 2013 +0800 Add single touch support for LCD8000-97C using on ubuntu & emmc fix to mmcblk0.
Unfortunately the most recent Linux image for the MarS was from Sept. 17, 2013, so to test out single touch I had to compile and install a new kernel for the MarS. Hopefully a new Linux image will be released soon and you won’t be faced with having to do a kernel compile right off the bat to use the screen as a touch screen.
... The kernel version of the last updated images for the MarS. $ uname -a Linux linaro-ubuntu-desktop 3.0.15-01361-g6cd3d53-dirty #2 SMP PREEMPT Wed Aug 28 13:42:52 CST 2013 armv7l armv7l armv7l GNU/Linux
The MarS user manual recommends setting up Ubuntu in a virtual machine and cross compiling your Linux kernel for the MarS. Since the MarS board is capable enough hardware to compile its own kernel I decided to compile on the MarS itself. I had to make the below links so that the compiler was found:
# ls -l /usr/bin/arm-fsl* lrwxrwxrwx 1 root root 2 2014-03-27 23:55 /usr/bin/arm-fsl-linux-gnueabi-ar -> ar lrwxrwxrwx 1 root root 3 2014-03-27 23:52 /usr/bin/arm-fsl-linux- gnueabi-gcc -> gcc lrwxrwxrwx 1 root root 2 2014-03-27 23:54 /usr/bin/arm-fsl-linux- gnueabi-ld -> ld lrwxrwxrwx 1 root root 2 2014-03-28 01:17 /usr/bin/arm-fsl-linux- gnueabi-nm -> nm lrwxrwxrwx 1 root root 7 2014-03-28 01:06 /usr/bin/arm-fsl-linux- gnueabi-objcopy -> objcopy lrwxrwxrwx 1 root root 7 2014-03-27 23:54 /usr/bin/arm-fsl-linux- gnueabi-objdump -> objdump
Then the below commands will grab the latest kernel from the same branch as the one that was already running. That kernel also happens to contain the touch interface update. It does take a long time, on the order of easily over an hour to compile the kernel, so if you are doing development on the kernel then the cross compile environment would likely be the way to go.
$ git clone https://github.com/embest-tech/linux-imx.git $ cd ./linux-imx $ git checkout embest_imx_3.0.15_12.04.01 $ make imx6_defconfig $ make KALLSYMS_EXTRA_PASS=1 uImage ... Image arch/arm/boot/uImage is ready $ ls -l arch/arm/boot/uImage -rw-rw-r-- 1 ben ben 3645672 2014-03-28 01:24 arch/arm/boot/uImage
Although there is an uImage file in /boot that is not the kernel that the MarS is using. If you look at the partition table for the 4 GB of flash on the MarS you will see that there is a gap left before the only partition. That gap is where the boot loader and currently running Linux kernel are loaded from.
root@linaro-ubuntu-desktop:~# fdisk -l /dev/mmcblk0
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 20480 7798783 3889152 83 Linux
Watching the boot up procedure on a serial terminal you can see the exact location from which the U-Boot bootloader loaded the Linux kernel. The following dd command will grab the current Linux kernel from the flash memory and use od to display it in a more human readable format. Notice that starting at byte 32 (40 octal) the Linux kernel version is stored.
root@linaro-ubuntu-desktop:/tmp# dd if=/dev/mmcblk0 of=test bs=1024 count=10000 skip=1024 10000+0 records in 10000+0 records out 10240000 bytes (10 MB) copied, 0.319027 s, 32.1 MB/s root@linaro-ubuntu-desktop:/ tmp# od -t c test > test.od ^c root@linaro-ubuntu-desktop:/ tmp# vi test.od ... 0000040 L i n u x - 3 . 0 . 1 5 - 0 1 3 0000060 6 1 - g 6 c d 3 d 5 3 - d i r t
I ran the below command to copy my updated /boot/uImage to the on board flash at the location that U-Boot expected it to be stored. Of course I took a good back up of the whole start to mmcblk0 first and then ran the above command to verify that the new “L i n u x” and so on version string appeared at the expected location with the expected value. Make sure you have a backup and recovery plan before playing with fixed offsets and dd like this. I wasn’t sure what state my MarS would be in after I ran the command, and was prepared to reuse mfgTool to reflash the MarS and try again.
# dd if=/boot/uImage of=/dev/mmcblk0 bs=1024 seek=1024
After a reboot I was running my updated kernel and had single touch working on the screen. I had also updated the X Server a little bit, too, in preparation for touch using the below commands.
$ uname -a Linux linaro-ubuntu-desktop 3.0.15-01365-ge16f9b9 #1 SMP PREEMPT Fri Mar 28 01:17:29 UTC 2014 armv7l armv7l armv7l GNU/Linux # apt-get remove xserver-xorg-input-synaptics # apt-get install xserver-xorg-input-tslib libts-bin
There is one downside to doing single touch on Linux this way, when you press down and move your finger it is equivalent to holding down a mouse button and dragging the mouse around. So if you are used to scrolling a web browser on a tablet for example, then you will be a little surprised when you start selecting text in Firefox using the single touch interface. I suspect this can be worked around for the browser by an extension but the same unexpected (non scrolling) behavior will be waiting in other applications. You’ll probably want to set up a soft keyboard under Linaro as well so you can type on the screen. On the other hand the single touch should work well for custom QtQuick user interfaces.
Hardware Interaction
Running Linux on the MarS board exposes the GPIO pins using the /sys/class/gpio directory. This is the same method I have shown in a previous article on the BeagleBone Black. Likewise, interrupts on GPIO pins should also work the same way as on the BeagleBone Black. There are also three TWI device files created in /dev, though I am still working out how to make a /dev/spi appear.
root@linaro-ubuntu-desktop:~# ls -l /sys/class/gpio/ total 0 --w------- 1 root root 4096 1970-01-01 01:09 export lrwxrwxrwx 1 root root 0 1970-01-01 01:09 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 1970-01-01 01:09 gpiochip128 -> ../../devices/virtual/gpio/ gpiochip128 lrwxrwxrwx 1 root root 0 1970-01-01 01:09 gpiochip160 -> ../../devices/virtual/gpio/ gpiochip160 lrwxrwxrwx 1 root root 0 1970-01-01 01:09 gpiochip192 -> ../../devices/virtual/gpio/ gpiochip192 lrwxrwxrwx 1 root root 0 1970-01-01 01:09 gpiochip32 -> ../../devices/virtual/gpio/ gpiochip32 lrwxrwxrwx 1 root root 0 1970-01-01 01:09 gpiochip64 -> ../../devices/virtual/gpio/ gpiochip64 lrwxrwxrwx 1 root root 0 1970-01-01 01:09 gpiochip96 -> ../../devices/virtual/gpio/ gpiochip96 --w------- 1 root root 4096 1970-01-01 01:09 unexport
Performance
Bonnie wants to create files which are twice the size of the available memory on the system to avoid disk caches from interfering with the benchmark. The MarS has 1 GB of RAM and I didn’t have a full 2 GB of storage free so I decided to limit the size of the files to a few hundred megabytes. The command is shown below and is the same command used to test the flash storage on the BeagleBone Black.
user@mars:~/test$ /sbin/bonnie++ -f -m mars -s 200 -r 100 -d `pwd`
The MarS got 4.7 megabyte/ second (MB/s) for output and 3.5 MB/s for rewrite. In contrast the BeagleBone Black got 4.2 MB/s and 4.5 MB/s respectively and the ODroid-U2 quad core ARM got 16 MB/s and 12 MB/s respectively. I was a bit surprised by the performance on the MarS as it feels like a fairly fast machine; after running bonnie the MarS was using 150 MB for disk cache. Perhaps the 1 GB of RAM allowed more overall disk cache than some machines and helped with the perceived speed of the MarS board.
To test 2d graphics performance I used version 1.0.1 of the Cairo Performance Demos. The gears test runs three turning gears; the chart runs four line graphs; the fish is a simulated fish tank with many fish swimming around; gradient is a filled curved edged path that moves around the screen; and flowers renders rotating flowers that move up and down the screen. For comparison I used a desktop machine running an Intel 2600K CPU with an NVidia GTX 570 card which drives two screens, one at 2560×1440 and the other at 1080p. It is interesting that the MarS was so much faster on the gradient but considerably slower on the fish demo.
BBB fps Mars fps desktop 2600k/nv570
at 720p LVDS at two screens.
1024x768
gears 26 18 140
chart 2 2 16
fish 4 0.3 188
gradient 10 17 117
flowers 1 2 170
The Octane 2.0 Javascript benchmark measures how well your Web browser performs various tasks. I used Firefox version 20.0+build1-0ubuntu0.11.10.3 that came with the updates to the Linaro for the MarS to run Octane, giving 930 for Splay, 60 for Regexp, 1011 for pdf.js. Unfortunately the test slowed to a crawl during Box2DWeb so the overall figure is not available. To contrast, the BeagleBone Black got 827, 88, and 401 respectively for Splay, Regexp, and pdf.js.
Power Usage
With the 9.7-inch LVDS touch panel connected and sitting at an idle Linaro desktop, the MarS consumed around 5.4 Watts (W). Running a two parallel task build on openssl 1.0.1e ranged up to 7.7 W of power. When the 9.7-inch screen goes to sleep but the MarS is still running power drops to 3.3 W. Running glxgears with the screen on used 8.9 W, so the 3D stuff was using 4.5 W all by itself.
With the power draw for OpenGL I used a Scythe USB temperature sensor to see how the chip was doing. The table near the MarS measured 32.4 C. After running glxgears for a while I measured 62 C on the CPU. Looking around for temperature monitors on the MarS itself, I found the file /sys/devices/virtual/thermal/
Wrap up
The dual core MarS board offers 1 GB of RAM, a large enough on-board flash to still have over a gigabyte free after Linaro is installed, and a bunch of headers to play with. The LVDS screen works well once the software is set up. The main remaining issue is how to set up multitouch input under Linux. The network connection being at gigabit speed may also make the MarS the right choice if you need a fast network connection. The MarS also has a nicer CPU (dual core) and memory specification (1 GB) relative to the BeagleBone Black and Raspberry Pi. Of course, the MarS board is more expensive than the BeagleBone Black and Raspberry Pi as well.
Given that the location of the Linux kernel is known and the only other filesystem contains the Linaro installation, it will be interesting to see what other and newer Linux installations can be made for the MarS. I’m still tinkering with getting a Linux desktop across both the the LVDS and HDMI screens.
We would like to thank element14 for providing review hardware for this article.
