In our never ending quest to handle the question of “How do I program this thing”, we’ve added a new tool to U-Boot. A new routine and command has just been acked by the U-Boot community, we’ll very soon have support for gzwrite() (which stands for gunzip and write) in our boot loaders.
The purpose of the utility is to allow filesystems to be programmed quickly to block devices in an environment where removal of the device is impractical. Of course, this applies most directly to eMMC or other soldered-on storage, but also may apply in environments where an SD card slot is not exposed, but a USB Host or OTG port is available.
The routine and command act on a gzip-compressed image in memory and allow it to be decompressed and written to a block device in one pass. This often allows a typical 4 GiB storage device to be programmed entirely from RAM, even on boards with only 1GiB. In fact, every one of the images listed in our i.MX6 builds page can fit within RAM on a Nitrogen6X or BD-SL-i.MX6 (SABRE Lite) board.
For the impatient
If you have a file named my.img.gz on SD card mmc 0, you can load it into RAM and program it to the eMMC on a Nitrogen6_Max like so:
write buffer size (default 1MiB). The decompress operation will allocate buffer this size and flush to the block device when filled.
0
start offset in bytes on the block device
The last parameter can be used to decompress multiple parts of an image piecewise if the source is too big to fit into RAM.
U-Boot and its’ stack and heap live at the tail-end of memory as described here, so images have to be pretty big before we worry about that. (You can likely program a gzipped image up to DDR size-20 MiB)
Availability
The gzwrite command has been enabled for all of our boards on the staging branch of our Github repository with commits like this one for Nitrogen6x, but will become a standard feature in all future releases.
If you want to test things out before then, we placed a package with our current staging binaries on-line here:
The gzwrite() routine supports the use of call-backs to represent progress, so you can customize things to provide something fancy. Extracting a 4GiB image to eMMC generally should take under 6 minutes, but that’s a long time to wait without letting a user know that things are moving forward.
If your display is supported by U-Boot, you’ll probably want this on the screen, and can accomplish that by setting the stdout variable:
U-Boot > setenv stdout serial,vga
Use in a boot script
Wrapping this up in a boot script is very straightforward. If you paste this into our on-line boot script compiler, you’ll get a binary that you can place onto a USB stick or SD card that will automagically program my.img.gz to eMMC (or the top SD card slot
on Nitrogen6X/BD-SL-i.MX6):
When we put together our post on use of the Debian installer, we intended it as a learning exercise as much as anything. We described the steps needed to create and compile a kernel and use a couple of variations of boot script to use standard Debian tools to craft an image.
Based on your feedback, that’s not what many of you were after. Instead, you just wanted an image to run, and wanted us to support the kernel.
We hear you.
Since that time, we’ve gained the expertise to properly bundle kernels and in the case of Ubuntu, to package the GPU and VPU acceleration bits into easy-to-use images.
So, without further ado, here are a couple of images of Debian Jessie:
The images are slightly-less-than-4GiB image files containing the partition table, so you can copy it to an SD card or SATA drive on /dev/sdc using zcat and dd like so:
Note that the links above don’t require acceptance of a EULA because they don’t include support for acceleration of either the GPU or VPU (the Freescale proprietary content).
We do plan to add that support, but not in the context of the current 3.10.17 kernel.
What’s supported
Since the images above include our stable 3.10.17 kernel, essentially everything but the GPU and VPU are supported, including Wi-Fi and Bluetooth, all of our storage devices (SD card, eMMC, SATA, USB sticks) and all of our supported touch panels.
The kernel packaging is also done in the normal Debian way, so apt-get update/dist-upgrade will keep your image up and running the latest as patches come out.
Usernames and passwords
Two users are defined for use on the system: debian and root. The password for each is Boundary (with a Capital B).
An ssh server is configured on the system, though it does not allow password-based authentication for user root.
User debian has sudo privileges, so you can place your ssh public key (normally $HOME/.ssh/id_rsa.pub) to the system like so:
debian@nitrogen:~$ sudo mkdir /root/.ssh
[sudo] password for debian:
debian@nitrogen:~$ sudo nano /root/.ssh/authorized_keys
... paste content of $HOME/.ssh/id_rsa.pub here
debian@nitrogen:~$ sudo chmod 600 /root/.ssh/auth*
debian@nitrogen:~$ sudo chmod 600 /root/.ssh/
Bluetooth settings on XFCE (only Nitrogen6_Max and Nitrogen6x boards)
In the notification area (top-right corner) you can see the Bluetooth applet icon :
The Bluetooth Manager’s Devices window pops up. Push the [Search] button, and you’ll see the available devices.
If you select a device from the list, you can connect and pair with them.
Bluetooth settings on console (only Nitrogen6_Max and Nitrogen6x boards)
Handling bluetooth is easier on a headless Debian system than on Ubuntu, since Debian uses the newest 5.23 bluez package, while Ubuntu uses 4.101 .
Debian has a great cmd-line utility for bluetooth, named bluetoothctl with many more options than hci-tools. For example pairing a device from the shell. You have to run it as root :
debian@jessie-dev:~$ sudo bluetoothctl
[NEW] Controller 84:DD:20:DA:B1:8F jessie-dev [default]
[bluetooth]# help
Available commands:
list List available controllers
show [ctrl] Controller information
select Select default controller
devices List available devices
paired-devices List paired devices
power Set controller power
pairable Set controller pairable mode
discoverable Set controller discoverable mode
agent Enable/disable agent with given capability
default-agent Set agent as the default one
scan Scan for devices
info Device information
pair Pair with device
trust Trust device
untrust Untrust device
block Block device
unblock Unblock device
remove Remove device
connect Connect device
disconnect Disconnect device
version Display version
quit Quit program
[bluetooth]# scan on
Discovery started
[CHG] Controller 84:DD:20:DA:B1:8F Discovering: yes
[NEW] Device 0C:1D:AF:A2:E3:78 Redmi
[bluetooth]# info 0C:1D:AF:A2:E3:78
Device 0C:1D:AF:A2:E3:78
Name: Redmi
Alias: Redmi
Class: 0x5a020c
Icon: phone
Paired: no
Trusted: no
Blocked: no
Connected: no
LegacyPairing: no
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb)
UUID: PANU (00001115-0000-1000-8000-00805f9b34fb)
UUID: NAP (00001116-0000-1000-8000-00805f9b34fb)
UUID: Handsfree Audio Gateway (0000111f-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
[bluetooth]# quit
[DEL] Controller 84:DD:20:DA:B1:8F jessie-dev [default]
debian@jessie-dev:~$
Connecting to Wi-Fi Network (only Nitrogen6_Max and Nitrogen6x boards)
In the notification area (top-right corner) you can see the Network Manager applet icon (rightmost icon, it looks like a white Magnum icecream), please push it :
Type your password, and Wi-Fi is configured, that was all ! Simple, isn’t it ?
Other notes
The Debian project is more conservative but more stable than Ubuntu, and Jessie (8.0) is the next release, and still in the testing phase. In these images gcc 4.9 compiler was installed. It has coloured output now : errors, warnings , messages, info have different colours in the console window. We installed some useful indicator applets on the XFCE desktop’s bottom panel, a network applet is showing download and upload speeds of the ethernet interface, and a CPU graph indicator showing the utilization of cores in percent :
Our i.MX6 platforms have great multimedia features and this post will describe how to leverage them using the most used multimedia framework Gstreamer along with a Buildroot filesystem.
What is it?
Gstreamer: This is a pipeline-based multimedia framework written in the C programming language with the type system based on GObject.
Gstreamer-imx: This is a set of GStreamer 1.0 plugins for Freescale’s i.MX platform, which make use of the i.MX multimedia capabilities.
Buildroot: Buildroot is a nice, simple, and efficient embedded Linux build system. You can learn more about this project by looking at this presentation from the ELC2014: Dive into Buildroot core.
For the impatient
If you just want to boot up Buildroot with gstreamer1, we’ve uploaded an image that will run on our BD-SL-i.MX6 (SABRE Lite), Nitrogen6x or Nitrogen6_Max board.
The image contains Freescale-licensed content, so you will need to register on our web-site and log in before you can accept the license agreement and download the image from here:
Buildroot generates partition files which requires the block device, SDCard or SATA drive, to be partitioned already. Here is a command that allows to create a full size partition to the device:
Below is an example of a pipeline leveraging the VPU for the video decoding, the IPU for cropping the video output as well as capturing the stream from the Camera and the GPU that converts and display the Camera stream
This tool will also allow you to easily troubleshoot issues by adding some log using the GST_DEBUG shell variable. It will then change the log level whose value range between 0 and 5 (5 will show all messages).
This release will be pushed to the master branch of the FSL-Community BSP shortly, but there are some very notable changes from earlier releases that we’ll discuss below.
Or you can use Alex Page’s USB Image Tool under Windows.
What works (and what doesn’t)
In short: everything works. Or at least, everything we’ve tried works at the kernel level. Because we based the image on the Yocto master branch, there are some quirks in the image above, notably:
Actually, that’s not quite right. There are features of some of our custom boards and peripherals like HDMI input, composite video input and output which have not been tested, but are also not in widespread use.
We don’t have the Bluetooth stack configured properly, and
We don’t have Wi-Fi configured properly
Both of these have to do with the use of systemd and connman in the latest Yocto layers. In the case of Bluetooth, we’ve tested against the BlueZ 5.0 stack of our Debian Jessie images by Ubuntunizing the kernel. We’ll follow up with Debian and Ubuntu images based on this kernel very soon.
In the case of Wi-Fi, we had to kill the supplicant started by dbus and start things up by hand like so:
Then, after using wpa_cli to configure the network as described in this post, we had to run udhcpc manually like so:
root@nitrogen6x:~/$ udhcpc -f -q -n -i wlan0
udhcpc (v1.23.1) started
Sending discover...
Sending select for 192.168.4.42...
Lease of 192.168.4.42 obtained, lease time 600
/etc/udhcpc.d/50default: Adding DNS 192.168.0.254
/etc/udhcpc.d/50default: Adding DNS 192.168.2.1
We’ll address these issues with a more full-featured image with the upcoming Fido release of Yocto.
Display support
You might have thought that 3.10.53 to the previous 3.10.31 release would be a minor update.
We did, and we were wrong.
Lots of changes in a variety of subsystems required re-work of our over 400 patches to the kernel tree, and the most notable (and visible) are in the area of display handling.
Specifically, the LVDS Display Bridge (LDB) driver underwent a major restructuring (for the better) and broke our scheme of building up a kernel command-line with multiple video= clauses for the kernel command line (bootargs variable in U-Boot). Instead, the LVDS displays are defined in the device tree in a much more explicit fashion.
This problem is fairly specific to our off-the-shelf boards and our desire to make each of our standard displays operate in a plug and play fashion, but this change necessitated some re-thinking of our strategy.
For your production applications, the answer is much easier. You can simply cut the bits out of your device trees for displays that you aren’t using. After doing so, you can essentially ignore the displays in your boot script.
In short, we’ve almost completely re-written our boot script to change a build up bootargs process to one that prunes the device tree using the fdt rm command in U-Boot.
The following two snippets show the difference. The old boot script did this to add a video= clause for an HDMI monitor:
if i2c probe 0x50 ; then
setenv bootargs $bootargs video=mxcfb${nextcon}:dev=hdmi,1280x720M@60,if=RGB24
setenv fbmem "fbmem=28M";
setexpr nextcon $nextcon + 1
else
echo "------ no HDMI monitor";
fi
In 3.10.53+, this turns into the following:
if i2c probe 0x50 ; then
echo "------ have HDMI monitor";
else
fdt rm hdmi_display
echo "------ no HDMI monitor";
fi
The earlier bits of the 3.10.53 boot script have loaded the DTB and we now prune or remove (rm) the unused nodes.
The new boot script
The new boot script is currently only available for use with Yocto and is available here:
Loads the device tree early. Our previous boot scripts tried to do the right thing for DT-enabled kernels and earlier versions.
Doesn’t set enable_wait_mode=off. This kernel switch is no longer supported or necessary because the device tree can indicate whether the ENET IRQ is available for use. Note that if you’re using a SABRE Lite or Nitrogen6x board and aren’t using the parallel camera interface, we can help you tweak your device tree to support the ENET_IRQ on GPIO 6.
Doesn’t pass fbmem to the kernel. This is no longer needed or supported.
Added variable lvds_1080p to allow the use of a 1080P LVDS display using dual-channel LVDS on Nitrogen6_Max. The details are in this test in the boot script.
Added support for LVDS1 on Nitrogen6_Max. Since we only have a single I2C touch screen connector, this isn’t auto-detected, but we added a variable lvds1_panel that allows you to select which panel you have connected as shown in this block of script.
Added support for Nitrogen6_Lite and Nitrogen6_VM. Both our Nitrogen6_Lite and Nitrogen6_VM boards have on board touch controllers that can confuse the auto-detection code. By adding a variable ignore_lcd to this section of the boot script, you can disable this if you’re only using the LVDS or LCD channels.
Between all of these, the Nitrogen6_Max can support four simultaneous displays (HDMI, RGB, 2xLVDS) and auto-detect all except the second LVDS channel.
The panel=LDB-WXGA variable is still needed to distinguish between the 1024×600 and 1280×800 displays with the FocalTech controller as described in this post.
Again, please note that all of this complexity comes from a desire to plug and play. Once you’ve determined what displays you’ll be using, you should create a custom device tree and a custom boot script that skips all of this. Let us know if you need help with that.
Testing details
The following check-list was used during testing of the kernel. If you find a piece that’s missing, please let us know.
As mentioned earlier, there are some components of especially custom boards which have not yet been tested. If you have one of these and want to push forward to the latest kernel, please contact us.
Along with the Qt World Summit 2015, The Qt Company is hosting the North America Qt Roadshow with ICS where key players in the industry collaborate with technology managers & developers on innovations that change how developers and consumers experience a phenomenal UI/UX and uncompromised performance.
The event series will take place in key technology centers around the US & impact the industry on a global scale, The Qt Roadshow is a future forward event where you can rub elbows with technologists and move technology ahead.
Do your customers think of your product more like computer or a toaster?
The software driving our Linux-based systems has roots in mini-computers, where the systems lived in data centers with raised floors, un-interruptible power supplies and staff to handle backups and maintenance.
That’s probably not the case for your products. They likely boot directly into your application and have an easily accessible power cord, but not an easily identified “shutdown” button.
In this post, we’ll describe a tool (overlayfs) that can help make your systems more reliable in the event of abrupt system power-off.
The images are slightly-less-than-4GiB image files containing the partition table, so you can copy it to an SD card or SATA drive on /dev/sdc using zcat and dd like so:
The image above, and all future releases of Debian Ubuntu will contain overlayfs support, but they will not be pre-configured to use it. To install and configure it, you’ll need to take the following steps:
Make sure you have the kernel 3.10.53 or later installed, and at least ABI >= 7 :
Install the overlayfs script. This script runs in the initial ramfs disk (initramfs) at boot time, and constructs an overlayfs stack that includes your read-only root and a RAM-disk top level filesystem (more details below).
ubuntu@trusty-dev:~$ sudo apt-get install overlayfs-script1 && sync && sudo reboot
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
overlayfs-script1
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 3274 B of archives.
After this operation, 47.1 kB of additional disk space will be used.
Get:1 http://linode.boundarydevices.com/repos/apt/ubuntu-rel/ trusty/main overlayfs-script1 armhf 1.0.0-1 [3274 B]
Fetched 3274 B in 0s (16.0 kB/s)
Selecting previously unselected package overlayfs-script1.
(Reading database ... 52288 files and directories currently installed.)
Preparing to unpack .../overlayfs-script1_1.0.0-1_armhf.deb ...
Unpacking overlayfs-script1 (1.0.0-1) ...
Setting up overlayfs-script1 (1.0.0-1) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.103ubuntu4.2) ...
update-initramfs: Generating /boot/initrd.img-3.10.53-7-boundary-7t5
Enable your read-only filesystem by setting U-Boot environment variables:
The first line enables the overlayfs-script. The second line sets the size of the overlafs system as 20% of the available system RAM. If ofs-size is not set, the overlayfs system will default to 50%, which is excessive in most cases.
Note that memory for the RAM disk is not pre-allocated, and will only be used as writes to the filesystem occur.
Poking around after booting
After booting you can check the mounted partitions:
ubuntu@trusty-dev:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=382632k,nr_inodes=95658,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102956k,mode=755)
/dev/disk/by-path/platform-2198000.usdhc-part1 on /mnt/root-RO/mnt/root-RO type ext4 (ro,relatime,data=ordered)
tmpfs-root on /mnt/root-RO/mnt/root-RW type tmpfs (rw,relatime,size=154432k)
overlayfs-root on /mnt/root-RO type overlayfs (rw,relatime,lowerdir=/mnt/root-RO,upperdir=/mnt/root-RW)
tmpfs-root on /mnt/root-RW type tmpfs (rw,relatime,size=154432k)
overlayfs-root on / type overlayfs (rw,relatime,lowerdir=/mnt/root-RO,upperdir=/mnt/root-RW)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/cgroup type tmpfs (rw,relatime,size=4k,mode=755)
none on /sys/fs/fuse/connections type fusectl (rw,relatime)
none on /sys/kernel/debug type debugfs (rw,relatime)
none on /sys/kernel/security type securityfs (rw,relatime)
none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
none on /run/shm type tmpfs (rw,nosuid,nodev,relatime)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755)
ubuntu@trusty-dev:~$
Note that the root mount point is the overlayfs (line 11:overlayfs-root on /), and that the lowerdir and upperdir options specify the overlay stack.
Also note that we modified the file /etc/fstab to include a reference to the read-only rootfs and some comments about how to re-mount it as read-write:
ubuntu@trusty-dev:~$ sudo cat /etc/fstab
# This fstab is in RAM, the real one can be found at /mnt/root-RO/etc/fstab
# The original entry for '/' and all swap files have been removed. The new
# entry for the read-only the real root fs follows. Write access can be
# enabled using:
# sudo mount -o remount,rw /mnt/root-RO
# re-mounting it read-only is done using:
# sudo mount -o remount,ro /mnt/root-RO
#
/dev/disk/by-path/platform-2198000.usdhc-part1 /mnt/root-RO ext4 ro,relatime,data=ordered 0 1
# remaining entries from the original /mnt/root-RO/etc/fstab follow.
#
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
#
The resulting filesystem acts like a regular read-write filesystem. You can add, copy, install, and remove files as you want, your old system appears to work unchanged.
But your changes will not be persistent: they will stay around only until the next reboot!
After reboot you get back the original image, just like if it were an unchangeable CD.
The advantage is obvious: users can’t harm to the system by handling it improperly (without graceful shutdown), because actually they don’t and they can’t write anything to SD card, because the SD card is mounted as read-only.
The resulting image is invincible, (not fireproof or waterproof though, I never said that) it becomes immune to the rough users, and the toaster will always work.
Where the magic happens
The key to making all of this happen comes from the fact that our Debian and Ubuntu images boot first to a RAM disk (the initramfs image). The overlayfs-script1 script we installed above is executed in the context of that RAM disk to locate and create the two-layer stack of writeable top layer and a read-only bottom layer.
To understand the details, you can grab the sources using apt-get source:
ubuntu@trusty-dev:~$ apt-get source overlayfs-script1
ubuntu@trusty-dev:~$ sudo grep -A 10 /proc/cmdline overlayfs-scripts-1.0.0/overlayfs-script1
for CMDLINE_OPT in $(cat /proc/cmdline); do
case ${CMDLINE_OPT} in
overlayfs=*)
OVERLAYFS=${CMDLINE_OPT#overlayfs=}
;;
ofs-size=*)
OFS_SIZE=${CMDLINE_OPT#ofs-size=}
;;
esac
done
Modifying the read-only filesystem:
Of course after you made your system read-only, its configuration, updating, upgrading, any kind of persistent modification is not so simple.
You can disable the overlayfs-script temporarily from the U-Boot prompt :
U-Boot > setenv overlayfs no
U-Boot > boot
Note that we didn’t use saveenv, so this will only affect a single boot.
After this, you can change anything in the image, and the modifications you make will be persistent.
If you want to make the change permanent, and go back to using a read-write root, you can change the variable using the fw_setenv program as described in this post about accessing the boot flash under Linux.
About overlayfs
OverlayUnion filesystems have a long history in Linux, with Unionfs back in 2004, AUFS in 2006. Their uses varied, but were driven by a desire to run systems off of inherently read-only media like CD-ROMs, and many Linux distributions have used them to distribute Live CDs that allow you to boot completely off of CD.
Overlayfs is the latest in the category and the first to gain acceptance into the Linux kernel source tree.
It can be used with more than two partitions in the stack and in general, updates will occur in the top-most layer of the stack which contains a given directory and is writeable.
Care must be taken when references to older, read-only inodes are held when updates are made to upper layers of the stack, so it is not fully transparent to applications.
We’ve done extensive testing of this release, and it brings quite a few new features which we hope you’ll enjoy.
Because of this, we’re now recommending that this release be used for all new designs and that customers using KK4.4.2 for our off-the-shelf platforms consider migrating.
We will continue to support KK4.4.2 and JB4.3 for existing customers, but our efforts there will be limited to bug fixes and security updates.
UPDATE: those images have been updated for various OTA and display fixes (from 20150429 to 20150511). UPDATE-2: images updated again for better external storage management and file manager app (from 20150511 to 20150610).
As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.
What’s new?
The following are the highlights of the updates in this release.
Kernel
Linux kernel bumped to version 3.10.53
The kernel is based on Linux kernel 3.10.53 with support for device tree. This makes it easier to customize for new hardware or other use cases as described in our “What’s a board” post.
The main difference users will notice is the addition device tree files (.dtb files) in the boot partition next to the kernel (uImage).
Wi-Fi & Bluetooth
Wi-Fi and BT support for all platforms
Both TiWi-BLE (WL1271) and Ampak GB86xx (BCM4330) modules, respectively for Nitrogen6x/Max and Nit6xLite, are supported in this version.
Testing has been limited to connecting to another Wi-Fi Direct device (Moto G). This should enable the use of Miracast devices allowing to cast the entire screen to a wireless display.
Testing showed that a couple of audio and video codecs were missing from our releases. Everything is now handled in hardware for the best performance. As usual, we recommend the Tears of Steel high quality videos for testing.
We also included the Cactus Player into our build for an easy-to-use video player.
Auto-mount of USB drive and SD card as external storage
A USB drive is now automatically mounted as /storage/udisk/ and an SD card will be mounted under /storage/extsd/ if not used as booting device. Both need to be formatted as FAT, otherwise they will not be recognized properly.
The image configures /dev/block/mmcblk2 as the external drive. This is:
the top (micro) SD connector on Nitrogen6x
The micro SD connector on Nitrogen6_Max
The bottom (full-size) SD connector on BD-SL-i.MX6 (SABRE Lite)
If you haven’t built our Android software from sources, there are multiple steps to the process to fulfill some of the licensing agreements. You’ll first need to:
Note that this will download over 15GiB of source code and tools, so it will take a while.
If you’re not familiar with repo, you should check out the notes in the AOSP documentation. It’s a very nice tool for consolidating multiple source code repositories into a single project, and has lots of features for tracking changes across the various packages. The file .repo/manifests/default.xml consolidates the almost 400 packages that comprise our Android release.
You can see the structure here in our Github repository:
The next step is to choose the target board and build:
~/myandroid$ source build/envsetup.sh
~/myandroid$ lunch
... choose Nitrogen6x or Nit6xlite from the list of boards and then build
~/myandroid$ make 2>&1 | tee build-kk.out
A full build will take upwards of 3 hours, but incremental builds are pretty speedy if you’re changing things.
Useful tips
If your latest modifications only affect kernel, ramdisk or bootscript, you do not need to start a full build but use the bootimage target instead.
~/myandroid$ make bootimage
This will only update the components under the boot/ output folder which then can be updated as follows as an example:
Those modifications require a reboot in order to take effect:
~/myandroid$ adb reboot
If on the other hand the modification only affect a specific package, you can rebuild only that latter by issuing:
~/myandroid$ mmm hardware/libhardware_legacy/
You can even force the rebuild in case the Android.mk doesn’t see any obvious change that require re-building:
~/myandroid$ mmm -B hardware/libhardware_legacy/
Then the Android build process allows you to just send over changes to a USB-connected board using adb sync which requires to remount the system partition first:
~/myandroid$ adb remount
~/myandroid$ adb sync
If you’re changing system components, the best is to reboot as explained above but you could stop and restart the Android GUI.
~/myandroid$ adb shell 'stop && start'
As always, let us know your experiences (both good and bad) when you test out this image.
This is the first of a series of posts about Android security. This one will describe the security around the applications, their signature/certificates as well as their permissions.
Introduction & Theory
Signature
Android requires that each application be signed with the developer’s digital keys to enforce signature permissions and application requests to use shared user ID or target process.
The core Android platform uses four keys to maintain security of core platform components:
platform: a key for packages that are part of the core platform.
shared: a key for things that are shared in the home/contacts process.
media: a key for packages that are part of the media/download system.
testkey: the default key to sign with if not otherwise specified.
In our builds, we use the keys located under device/fsl/common/security/ as specified in device/fsl/imx6/imx6.mk. Because those keys are part of a publicly available source tree, they should never be used for production devices. Instead, you should generate your own private keys for building your production images.
Each key comes in two files: the certificate, which has the extension .x509.pem, and the private key, which has the extension .pk8. The private key should be kept secret and is needed to sign a package. The key may itself be protected by a password — a reasonable strategy is to store your keys in source control along with the code — but keep them protected by a password known only to the people who make final releases. The certificate, in contrast, contains only the public half of the key, so it can be distributed widely. It is used to verify a package has been signed by the corresponding private key.
Let’s start with the file permissions which are related to your process User Identifier (UID) and Group Identifier (GID). Looking at the serial nodes for instance we can see:
The above means that ttymxc2 can only be accessed by a process having a bluetooth UID or the net_bt_stack GID. Those nodes permissions are set in the ueventd.rc.
Now looking at the process list:
~/$ adb shell 'ps | grep bluetooth'
bluetooth 190 1 956 204 800edf18 76efb8bc S /system/bin/uim-sysfs
bluetooth 832 194 714732 23564 ffffffff 2b071834 S com.android.bluetooth
This means that only those two applications can read/write for that node.
What about a standard JAVA application UID? Android’s package manager creates a unique user id (UID) and group (GID) when it installs an application and these are retained until the application is un-installed.
This output shows a typical UID assigned to a standard application (u0_a27), however some critical apps can require a specific UID such as system:
~/$ adb shell 'ps | grep keychain'
system 1136 194 688724 18220 ffffffff 2b071834 S com.android.keychain
These parts (UID and GID) allow the kernel to enforce restrictions on files and devices. It is possible (and tempting) to allow “World” access to particular files, and we do it on occasion (see /dev/ttymxc0 in ueventd.rc), but this is somewhat dangerous.
The proper way to communicate to a driver in Android is for the JAVA application to call a standard API that uses a system service with the right permissions for the hardware. This brings us to the more Android-specific API permissions.
A basic Android application has no permissions associated with it by default, meaning it cannot do anything that would adversely impact the user experience or any data on the device. To make use of protected features of the device, you must include in your AndroidManifest.xml one or more tags declaring the permissions that your application needs.
Here is an example, if an application needs to get frames from the camera, it needs to ask for the CAMERA permission in its AndroidManifest.xml.
However, looking at the list of permissions you can notice that some permissions are marked as “Not for use by third-party applications“. This means that said permission can only be requested by a “system application” which means that it need to be signed with the platform keys. A good example is the REBOOT permissions which we are glad not every application can use.
Practical questions
It is assumed below that you are in possession of our last release source tree under your ~/myandroid folder.
Once this is done, you can either overwrite the keys located under device/fsl/common/security/ or copy them in your own device folder and modify the PRODUCT_DEFAULT_DEV_CERTIFICATE variable in device/fsl/imx6/imx6.mk.
How do I re-sign an application with my keys?
In the source tree resides a JAVA tool that allow to sign/re-sign applications and package. This tool, signapk.jar, is built automatically when building any target available. It can be used as follows to sign an application:
As said in the first section, an application considered a system app when signed with platform keys. It has nothing to do with its UID nor its location. Many people only suggest to copy the apk file from /data/app to /system/app but it doesn’t make it a system application per se. Here is an example to sign with the keys used in our build:
It is actually very simple, you just need to add one line to your AndroidManifest.xml.
android:sharedUserId="android.uid.system"
However this also requires your application to be signed with the platform keys.
Should all my apps be signed with platform keys then?
Signing with the platform keys gives access to many API that can be dangerous so you have to be careful. Moreover, it depends if your application is to be used across many different platforms or just one. As soon as your application requires to be signed with the platform keys, it will either only work to this specific platform or need to be re-sign for other products.
Remember that with great power comes great responsibility.
What about root uid?
A JAVA application cannot have a root UID but as you may have seen in the past, some applications rely on the su binary to execute some commands with root permissions. A su solution as been integrated in our latest release.
But it is to be noted that the init process has a root uid which means that any process forked from it would have the same uid by default. So if you have a native process that requires root permissions, declare it as a service in init.rc in order to be forked with the right permissions.
Test application
In order to demonstrate was has been said above, a repository containing a test application has been created:
Why two different branches? Because we don’t want people to be confused about the “system app” term that doesn’t mean system uid. But we still wanted you to witness the system uid and how simple it is. So here is a step-by-step process to try the app:
You can see the application crashed as expected because the application requires a permissions that only system app. It is time to sign it with the proper key:
From this moment on, our application can access any API marked as “Not for use by third-party applications“. The README under the security folder of android-tests also describes how to get Android Studio to automatically sign your application with the platform keys.
But we know some customers are interested in having an app with system uid, here is the procedure to achieve it.
Build the application and sign it with platform keys as described above
Same you have to first un-install the previous app as Package Manager would otherwise complain that the uid changed
Start the application and check the process uid
~/android-tests$ adb shell 'ps | grep boundary'
system 1371 194 834036 26272 ffffffff 2b0b3834 S com.boundarydevices.rebootapp
Finally, for those who do not have Android Studio but the AOSP source tree, an Android.mk has been added to build that single package easily, see the Useful Tips from our latest release.
This second security post will describe how to leverage the update feature available in our KitKat 4.4.3 release.
Android devices in the field can receive and install over-the-air (OTA) updates to the system and application software. Devices have a special recovery partition with the software needed to unpack a downloaded update package and apply it to the rest of the system.
The goal of this post to for customers to understand how to generate and apply OTA updates as well as knowing the security behind this process. It will describe the structure of these packages and the tools provided to build them.
For the impatient
We’ve updated our KitKat 4.4.3 releases to support OTA, and will be releasing updates through the normal Over-The-Air process. This feature will be present if you load a version dated 2015-05-11 or newer.
A typical OTA update contains the following steps:
Device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.
Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in /system/etc/security/otacerts.zip. User is prompted to install the update.
Device reboots into recovery mode, in which the kernel and system in the recovery partition are booted instead of the kernel in the boot partition.
Recovery binary is started by init. It finds command-line arguments in /cache/recovery/command that point it to the downloaded package.
Recovery verifies the cryptographic signature of the package against the public keys in /res/keys (part of the RAM disk contained in the recovery partition).
Data is pulled from the package and used to update the boot, system, and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.
Device reboots normally.
The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.
As part of normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in /system). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)
The system update is complete!
Update generation
It is assumed below that you are in possession of our KitKat 4.4.3 release source tree under your ~/myandroid folder.
Full updates
A full update is one where the entire final state of the device (system, boot, and recovery partitions) is contained in the package. The Android build system includes a default target for OTA package generation:
~/myandroid$ . build/envsetup.sh && lunch nitrogen6x-eng
~/myandroid$ make dist
The output package will be located under out/dist/nitrogen6x-ota-.zip.
Our previous security post explains the signing process and keys, please refer to it if you wish to specify which keys to use for the update package.
Incremental updates
An incremental update contains a set of binary patches to be applied to the data already on the device. This can result in considerably smaller update packages:
Files that have not changed don’t need to be included.
Files that have changed are often very similar to their previous versions, so the package need only contain an encoding of the differences between the two files.
Note: incremental hasn’t been tested yet and might require some work due to our Boundary-specific modifications.
It can happen that you need to apply an update which hasn’t been signed for your platform. As explained in our previous security post, a simple command allows you to re-sign an existing package:
edify script that describes actions to perform during the update
system/ or boot/ or other files
files to be used / copied / extracted during the update
How can I make my own?
Sometimes you might need to add only one file to an existing image and don’t want to go into the hassle of creating an incremental update for it. This section will describe how to make a minimalistic update which will add a ota_test.log file to /system/.
All you need to create a package are update-binary and updater-script. The former is an output of the build while the latter can be easily made by hand.
First prepare the script that will define you update, create an updater-script file with the following content:
~/myandroid$ cd update/ && zip -rq ../update_unsigned.zip * && cd -
~/myandroid$ java -jar out/host/linux-x86/framework/signapk.jar -w \
device/fsl/common/security/testkey.x509.pem device/fsl/common/security/testkey.pk8 \
update_unsigned.zip update_signed.zip
The package is ready to be applied! See next sections to know the different options.
Applying system updates over-the-air
This section relies on the FSLOta application provided by Freescale to fetch system updates from a distant server. This app has been included into our release with its default configuration that needs to be tweaked for your needs.
The OTA application settings are located in the file /system/etc/ota.conf which contains:
Update server address
Update server HTTP port
In order to have Boundary’s servers by default, please edit ota.conf as follows:
Feel free to modify FSLOta application to fit your needs as well as creating your own update server (installing lighttpd for example). This application is clearly target full system update only, a more flexible version check might need to be implemented to manage incremental updates.
Also, as an example, you could have the application starting at every boot, to do so you would need to listen to the BOOT_COMPLETED Intent.
Here are the steps to apply an update using adb sideload which requires the Android buttons board for Nitrogen6x, BD-SL and Nitrogen6_max. Unfortunately, this procedure won’t work on Nit6xlite boards because of the lack of buttons.
Boundary Devices announces the availability of the new Nit6_SoloX – a Single Board Computer based on the Freescale i.MX6 SoloX processor. The i.MX6 SoloX is a multi-purpose processor based on the very popular i.MX6 family. The i.MX6 SoloX features an ARM Cortex-M4 core which provides additional versatility to the i.MX6 family. The i.MX6 SoloX is a variant of the i.MX6 Solo, but it is not pin-compatible with the standard i.MX6 offerings. The Nit6_SoloX was designed to take advantage of the main features of the SoloX processor: Dual Gigabit Ethernet, integrated NTSC camera, Dual CAN Bus and additional peripherals. The Nit6_SoloX has on-board eMMC, LVDS display support, and a variety of connectivity options. The board is available in industrial as well as commercial temperature variants. Boundary Devices has also designed a daughter board that contains WiFi+BT, HDMI, camera, as well as a variety of I/O interfaces such as I2C and SPI. Details of the daughter board will be available soon. Contact us for more information: http://boundarydevices.com/product/nit6_solox-imx6/
List of specifications:
i.MX 6 SoloX ARM Cortex-A9/ARM Cortex-M4(Cortex-A9 @ 1GHZ, Cortex-M4 @200MHZ)
GuruCE has expanded its Freescale i.MX6 support of WindowsCE7 and CE2013 to include BD-SL-i.MX6 (formerly SABRE Lite), Nitrogen6X and Nitrogen6X-SOM. The GuruCE iMX6 BSP is a high quality, well structured, stable, full source BSP for WEC7 and WEC2013 supporting any board containing a Freescale iMX6 Solo, Dual-Lite, Dual or Quad processor. Here is a link for the download: https://guruce.com/imx6-bsp-releases/imx6-r406
Here are the main benefits of the GuruCE iMX6 BSP compared to the other iMX6 BSP offerings on the market today (from GuruCE Website):
Stability Our initial iMX6 BSP release is all about stability. We have done extensive testing to make sure the entire BSP is stable, in multi-core and single-core configurations, with or without caching, at stress and at rest. We have completely rewritten all of the low-level initialization code, all the timing code (CCM, system & performance counters), all of the cache code, all of the SMP (symmetric multiprocessing/multi-core) code and most of the interrupt handling code.
Performance
We have implemented all the cache optimizations possible for the iMX6 Cortex-A9 in combination with the PL310 L2 Cache Controller and we have configured DDR3 per board at the most optimal, fully stress tested, settings.
No more data corruption!
We have done extensive testing to make sure there are no more data corruption problems when copying large files (on SATA, USB Storage or USDHC) or when sending large amounts of data over the network.
One BSP for all iMX6 variants
Our BSP supports the iMX6 Solo, Dual Lite, Dual and Quad processor range, so you can scale your HW design up or down without any software development investment!
One BSP supporting WEC7 and WEC2013
Full drop-in support for WEC7 and WEC2013. Not a single code change required in the BSP.
Super easy BSP configuration
Very easy configuration of board, bootloader, CPU, cache and page table BSP options through the catalog.
Production Quality Code
All hardware definitions name-synchronized with the iMX6 Reference Manuals and IOMUX tool. A large amount of Freescale code re-factored, cleaned up & bug fixed, and all redundant code removed and restructured. No more searching for driver code distributed throughout the BSP in different folders. Now the BSP is easily maintainable, well-structured & production ready. If you have worked with BSPs from Freescale or some of our competitors before you know what this means and why this is so important. Code quality and BSP structure is everything
SPI Flash/SD/MMC/SATA Bootloader
Our iMX6 bootloader offers many more configuration options and features, like selecting the serial debug port to use, blowing fuses, configuring the Ethernet settings to be used in Windows Embedded Compact and starting the kernel with a clean registry hive. It also fully supports booting from SPI Flash, SATA, SD and MMC, and has full support for formatting and partitioning SATA, SD and MMC and erasing/writing SPI Flash.
PCIe bus driver
Full support for PCIe included in the BSP.
Full support for LCD8000-97C 1024×768 LVDS, WSVGA 1024×600 LVDS and various capacitive touch screens
The BSP includes full support for various LVDS displays, including support for a number of touch controllers.
Hive based registry support
Destination fully configurable through the catalog. No registry modifications required.
GPIO driver + SDK library
Control any (free) GPIO pin from your application.
FlexCAN driver + SDK library
Fully configurable FlexCAN driver. Access and control 2 separate CAN buses from your application with full configuration and timing control. Our High Performance FlexCAN driverfor real busy CAN buses is available for iMX6 as well.
ECSPI driver + SDK library
Fully configurable, DMA enabled, Enhanced Configurable SPI driver. All functionality offered by the iMX6 is supported and configurable in our driver. Unfortunately the iMX6 still contains the same silicon bug as on the iMX53, but at least our driver warns you when you hit this condition.
Complete bootloader independence
The low-level kernel initialization code takes care of everything needed by Windows Embedded Compact. It does not depend on any configuration done by the bootloader. This means you can choose whatever bootloader you fancy. You can use our included and feature-rich eboot, or any other bootloader you like better.
We are proud to be a Silver Sponsor of the Freescale Technology Forum June 22-June 25 in Austin, TX. Come visit our booth #111 in the Technology Lab to see the latest demos of our i.MX6 SoloX design, Nitrogen6_MAX utilizing an i.MX6 Quad-Plus processor, and our i.MX6 System on Modules. FTF is a great event for current or potential i.MX6 users because of the significant hands-on technical workshops available. More details of FTF can be found here
This release went under the same testing as our KitKat release.
We now recommend either KitKat 4.4.3 or Lollipop 5.0.0 for new designs. The selection will depend on customer preferences, knowing that Lollipop offers the latest API with a shiny UI but is also more memory hungry.
As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.
What’s new?
First of all, this release includes all the features that were previously available in our last Android 4.4.3 release. We will only describe the changes brought either by the OS update itself or changes in features that have been enabled in last release.
A security blog post will be created to cover this subject in detail. This section will try to summarize the main differences between KitKat and Lollipop releases and how to work with SELinux enforcement.
SEAndroid was also enabled in KitKat, but most of the security domains were set to be permissive, and denials were logged but not actually applied. All domains are enforced in Lollipop, so the policies must be configured properly for the system to behave as expected.
Check out this link to look at the different policies we’ve created.
Since SELinux can impede development, we’ve added a trigger to the boot script that allows you to disable enforcement during development.
If you want to be permissive (denials logged in dmesg but not enforced)
U-Boot > setenv selinux permissive
If you want to disable selinux completely (no logs)
You may not have noticed, but you had a choice of Java virtual machines in Kitkat, and could choose between the new “Android runtime” VM (ART), and the Dalvik VM used in previous versions of Android. In Lollipop, ART is the only choice.
NOTE: Android disables WiFi STA mode when the tethering is enabled. The use case tested is to have a connection available from the Ethernet port which is then shared through the hotspot.
WiFi Direct status
After some more testing on this feature, it appeared that on the TiWi-BLE module, used on Nitrogen6x and Nitrogen6_max, enabling the WiFi Direct feature may cause the Bluetooth not to perform normally (disconnection, sound cutting off etc…).
Therefore, for those experiencing Bluetooth issues that may come from this, we’ve added an option to disable WiFi Direct without having to re-build an image. It only requires to set a persistent property and reboot the device:
Just like last release, this one has OTA updates enabled for our platforms. However it is to be noted that upgrading from KitKat to Lollipop using OTA for various reasons:
boot and recovery partitions have been switched to ext4 instead of FAT for convenience
Recovery console doesn’t provide any mechanism to re-partition a device during update
OTA in lollipop uses block-based updates which cannot be applied on KitKat
Although this application has been added to a recent update of the KitKat release, here is a note about the open-source Cyanogenmod CMFileManager which is now a default application to our builds. This is intended to help customers navigate through their storages (internal or external). It can also be used to edit a text file as well as installing an .apk application or even start playing a video.
As mentioned above, Lollipop is more memory hungry than KitKat was so we wanted to share memory consumption at boot up:
Nitrogen6x/BDSL: 450MB used (378MB in KK)
Nit6xlite: 400MB used (340MB in KK)
As you can see, there is about 20% increase of used memory at boot up.
Browser capabilities
Lollipop brings an updated libwebviewchromium which means the Browser and more generally any webview-based application supports more features.
Here is a non-exhaustive list of benchmarks showing the evolution of the Browser between both releases:
html5test.com: 477/555 (396/555 in KK)
octane benchmark: 2294 (2092 in KK)
test.webrtc.org; webcam and microphone features now working
Easter egg
As usual, this Android version comes with its own Easter egg, this time it is a flappy bird-like game. We let you discover how to access it, feel free to share your highest score.
If you haven’t built our Android software from sources, there are multiple steps to the process to fulfill some of the licensing agreements. You’ll first need to:
Note that this will download over 15GiB of source code and tools, so it will take a while.
If you’re not familiar with repo, you should check out the notes in the AOSP documentation. It’s a very nice tool for consolidating multiple source code repositories into a single project, and has lots of features for tracking changes across the various packages. The file .repo/manifests/default.xml consolidates the almost 400 packages that comprise our Android release.
You can see the structure here in our Github repository:
The next step is to choose the target board and build:
~/myandroid$ source build/envsetup.sh
~/myandroid$ lunch
... choose Nitrogen6x or Nit6xlite from the list of boards and then build
~/myandroid$ make 2>&1 | tee build-kk.out
A full build will take upwards of 3 hours, but incremental builds are pretty speedy if you’re changing things.
As always, let us know your experiences (both good and bad) when you test out this image.
In our Lollipop release blog post, we mentioned that SELinux is now enforced for all the domains starting with Lollipop. This blog post will provide some details about the technology behind SELinux, its Android implementation as well as the different options to create, extend or remove policies. The content below mainly comes from Android website but we tried to shorten it to get to the point and to give examples from our BSP.
What is SELinux?
Mandatory Access Control (MAC)
SELinux is a mandatory access control (MAC) system for the Linux operating system. As a MAC system, it differs from Linux’s familiar discretionary access control (DAC) system. In a DAC system, a concept of ownership exists, whereby an owner of a particular resource controls access permissions associated with it. This is generally coarse-grained and subject to unintended privilege escalation. A MAC system, however, consults a central authority for a decision on all access attempts.
SELinux has been implemented as part of the Linux Security Module (LSM) framework, which recognizes various kernel objects, and sensitive actions performed on them. At the point at which each of these actions would be performed, an LSM hook function is called to determine whether or not the action should be allowed based on the information for it stored in an opaque security object. SELinux provides an implementation for these hooks and management of these security objects, which combine with its own policy, to determine the access decisions.
Become familiar with the following terms to understand how SELinux can be implemented to varying strengths.
Permissive – SELinux security policy is not enforced, only logged.
Enforcing – Security policy is enforced and logged. Failures appear as EPERM errors.
This choice is binary and determines whether your policy takes action or merely allows you to gather potential failures. Permissive is especially useful during implementation.
Unconfined – A very light policy that prohibits certain tasks and provides a temporary stop-gap during development. Should not be used for anything outside of the Android Open Source Project (AOSP).
Confined – A custom-written policy designed for the service. That policy should define precisely what is allowed.
Unconfined policies are available to help implement SELinux in Android quickly. They are suitable for most root-level applications. But they should be converted to confined policies wherever possible over time to restrict each application to precisely the resources it needs.
Ideally, your policy is both in enforcing mode and confined. Unconfined policies in enforcement mode can mask potential violations that would have been logged in permissive mode with a confined policy. Therefore, we strongly recommend partners implement true confined policies.
Labels, rules and domains
SELinux depends upon labels to match actions and policies. Labels determine what is allowed. Sockets, files, and processes all have labels in SELinux. SELinux decisions are based fundamentally on labels assigned to these objects and the policy defining how they may interact. In SELinux, a label takes the form: user:role:type:mls_level, where the type is the primary component of the access decisions, which may be modified by the other sections components which make up the label. The objects are mapped to classes and the different types of access for each class are represented by permissions.
The policy rules come in the form: allow domains types:classes permissions;, where:
Domain – A label for the process or set of processes. Also called a domain type as it is just a type for a process.
Type – A label for the object (e.g. file, socket) or set of objects.
Class – The kind of object (e.g. file, socket) being accessed.
Permission – The operation (e.g. read, write) being performed.
And so an example use of this would follow the structure:
allow appdomain app_data_file:file rw_file_perms;
Android implementation
The Android security model is based in part on the concept of application sandboxes. Each application runs in its own sandbox. Prior to Android 4.3, these sandboxes were defined by the creation of a unique Linux UID for each application at time of installation. Starting with Android 4.3, Security-Enhanced Linux (SELinux) is used to further define the boundaries of the Android application sandbox. SELinux enhances Android security by confining privileged processes and automating security policy creation.
SELinux is set up to default-deny, which means that every single access for which it has a hook in the kernel must be explicitly allowed by policy. This means a policy file is comprised of a large amount of information regarding rules, types, classes, permissions, and more.
Main differences
Although SELinux is a security module available in standard Linux kernel, it had to be modified specifically for Android. This is due to the use of Binder as the IPC mechanism, some hooks needed to be created in order for the security module to control Binder communications.
Android provides the necessary patches as part of its own Linux kernel:
Regarding the labels, it has been said above they contain four different fields. Only two of them are actually used in Android: role and type. The other fields still exist but user is set to u and mls_context to s0. Also, the role is always set to r for domains (processes) or to object_r for objects.
Key files
Apart from the kernel modifications listed above, all the SELinux tools and policies are located in one location: external/sepolicy.
Here are the files you must create or edit in order to implement SELinux:
New SELinux policy source (*.te) files – Located in the /device/manufacturer/device-name/sepolicy directory. These files define domains and their labels. The new policy files get concatenated with the existing policy files during compilation into a single SELinux kernel policy file.
Important: Do not alter the app.te file provided by the Android Open Source Project. Doing so risks breaking all third-party applications.
Updated BoardConfig.mk makefile – Located in the directory containing the sepolicy subdirectory. It must be updated to reference the sepolicy subdirectory once created if it wasn’t in initial implementation.
file_contexts – Located in the sepolicy subdirectory. This file assigns labels to files and is used by various userspace components. As you create new policies, create or update this file to assign new labels to files. In order to apply new file_contexts, you must rebuild the filesystem image or run restorecon on the file to be relabeled. On upgrades, changes to file_contexts are automatically applied to the system and userdata partitions as part of the upgrade. Changes can also be automatically applied on upgrade to other partitions by adding restorecon_recursive calls to your init.board.rc file after the partition has been mounted read-write.
genfs_contexts – Located in the sepolicy subdirectory. This file assigns labels to filesystems such as proc or vfat that do not support extended attributes. This configuration is loaded as part of the kernel policy but changes may not take effect for in-core inodes, requiring a reboot or unmounting and re-mounting the filesystem to fully apply the change. Specific labels may also be assigned to specific mounts such as vfat using the context= mount option.
property_contexts – Located in the sepolicy subdirectory. This file assigns labels to Android system properties to control what processes can set them. This configuration is read by the init process during startup and whenever the selinux.reload_policy property is set to 1.
service_contexts – Located in the sepolicy subdirectory. This file assigns labels to Android binder services to control what processes can add (register) and find (lookup) a binder reference for the service. This configuration is read by the servicemanager process during startup and whenever the selinux.reload_policy property is set to 1.
seapp_contexts – Located in the sepolicy subdirectory. This file assigns labels to app processes and /data/data directories. This configuration is read by the zygote process on each app launch and by installd during startup and whenever the selinux.reload_policy property is set to 1.
mac_permissions.xml – Located in the sepolicy subdirectory. This file assigns a seinfo tag to apps based on their signature and optionally their package name. The seinfo tag can then be used as a key in the seapp_contexts file to assign a specific label to all apps with that seinfo tag. This configuration is read by system_server during startup.
Tools
In order to be able to take advantage of SELinux, several tools are available. Here is a non-exhaustive list:
chcon: changes a file security context
getenforce: gives the current SELinux mode
ls -Z: displays the security context of files
ps -Z: display the security context of processes
restorecon: restores the security context of a file
runcon: runs a program in the specified secrutiy context
setenforce: sets the enforcing mode
How to work with it?
How to create/extend a policy?
The first step is to be able to identify the denials from. If SELinux is set to be permissive or enforcing, you can simply look at the kernel logs.
$ adb shell dmesg | grep avc
Some tools exist to generate policies directly from the above logs.
Once the policy has been generated, it needs to be included to the SELinux system configuration.
The first rule to add a policy is to NEVER modify the external/sepolicy project. Instead your BoardConfig.mk should specify some BOARD_SEPOLICY_DIRS directories from which policy can be overridden or unionised. In our BSP, every BoardConfig.mk include sepolicy.mk which specify the .te files location/
Since SELinux can impede development, it might be useful to disable it during debugging phase. For a runtime disablement, you can use setenforce.
$ adb shell setenforce 0
For a more permanent option, we’ve added a trigger to the boot script that allows you to disable enforcement from U-Boot.
If you want to be permissive (denials logged in dmesg but not enforced)
U-Boot > setenv selinux permissive
If you want to disable selinux completely (no logs)
U-Boot > setenv selinux disabled
Use case: uim-sysfs
In order to have a practical approach to this whole SELinux architecture, we will detail the changes made for uim-sysfs to work. Indeed, when first porting the BSP to Lollipop, uim-sysfs wasn’t working for several reasons.
First of all, uim-sysfs is a daemon provided by TI to manage the HCI connection to their WL12xx chips. As it didn’t have any domain set, init was complaining about it. To fix this issue, a domain must be defined to the service using the seclabel in init.rc. Looking at the sepolicy folder, hci_attach seemed like a good fit to this daemon:
Once the domain is set, the binary itself must have a security context that defines it as a hci_attach_exec. Also, this binary needs to access the char device /dev/hci_tty which therefore be declared as en hci_attach_dev.
As the security context of a file is stored in his file-system when it can (possible with ext4 for instance), the uim-sysfs file context must be updated manually or the system must be re-flashed for the change to happen.
This image contains Freescale-licensed content, so you will need to register on our web-site and log in before you can accept the license agreement and download the image from here:
This image contains support for all of our publicly available i.MX6 boards, though using it with the Nitrogen6 Lite requires a couple of tweaks (described below).
Programming the image
The image is a slightly-less-than-4GiB image file containing the partition table, so you can copy it to an SD card or SATA drive on /dev/sdc using zcat and dd like so:
The Linux kernel was upgraded to 3.10.53 ( meta-package name: linux-boundary-7t5 )
GPU driver was upgraded to Vivante 5.0.11p4.4 ( meta-package name: imx-gpu-viv-7t5-<backend> )
OpenGL ES v3.0 support was added
Khronos GLES 3.0 API
The 5.x driver is compatible with the 4.x driver. Applications developed using 4.x drivers can run on the 5.x driver without any changes.
Application’s performance on the 5.x driver will be better than or equal to that with the 4.x driver
Apitrace X11 tools added to trace OpenGL, OpenGL ES, Direct3D and DirectDraw API’s
VPU driver was updated to 3.10.53 and multimedia libraries to 4.0.2 ( meta-package name: imx-vpu-cnm-7t )
Added Real Networks parser and codec
Qt5 support added for X11, Wayland, and Framebuffer backends
Many-many bugfixes, and refinements… no place here to list all of them.
Usernames and passwords
Two users are defined for use on the system: ubuntu and root. The password for each is Boundary (capital B).
An ssh server is configured on the system, though it does not allow password-based authentication for user root.
User ubuntu has sudo privileges, so you can place your ssh public key (normally $HOME/.ssh/id_rsa.pub) to the system like so:
ubuntu@nitrogen:~$ sudo mkdir /root/.ssh
[sudo] password for ubuntu:
ubuntu@nitrogen:~$ sudo nano /root/.ssh/authorized_keys
... paste content of $HOME/.ssh/id_rsa.pub here
ubuntu@nitrogen:~$ sudo chmod 600 /root/.ssh/auth*
ubuntu@nitrogen:~$ sudo chmod 600 /root/.ssh/
What’s supported
Since the images above include our stable 3.10.53 kernel, essentially everything is supported. This includes Wi-Fi and Bluetooth, all of our storage devices (SD card, eMMC, SATA, USB sticks, GPU and VPU acceleration) and all of our supported touch panels.
The kernel packaging is also done in the normal Ubuntu/Debian way, so apt-get update/dist-upgrade will keep your image up and running the latest as patches come out.
GPU development libraries
The package imx-gpu-viv-7t5-dev ( development headers and libraries for OpenGL / ESv2 / ESv3 / Khronos ) is installed by default now. You have to set the headers path, before any other headers, or you might include the mesa headers first, and you don’t want to do that. For example :
export CFLAGS="-I/usr/include/vivante ${CFLAGS}"
If you would like to develop with the original mesa libraries, you have to uninstall the imx-gpu-viv-7t5-dev package, at least temporarily
Our i.MX6 boards support up to four displays, and we’ve been asked a number of times about dual display in Android.
At long last, we now have a dual display demo using our latest Android Lollipop 5.0 release that shows separate applications on each display.
We want to thank Dariusz Kluska for his OkienkaTest app that runs multiple activities in Android Lollipop as shown below. The appplication uses ActivityView for embedding multiple activities inside one application to create multiwindow solutions for Android.
We built upon this app to use the secondary display API introduced back in JellyBean that allows a single app displaying different content on the available screens:
Darek helped us understand how to achieve what we were looking for, especially getting the input dispatched properly. The source code for the app is available on github:
The demo is run on a Nitrogen6x with our two 7″ displays (LVDS Hannstar and RGB Okaya), so it is compatible with all our i.MX6 platforms (Nitrogen6_max, Nit6xlite, SabreLite).
As discussed in a previous blog post, GuruCE has put together a CE7 and CE2013 image for the SABRE Lite/BD-SL-i.MX6, Nitrogen6X, and Nitrogen6X-SOM. They have just released the latest version of the iMX6 BSP which has some major improvements in performance and have added quite a lot of functionality. Here are the highlights from their blog post:
The highlights:
4.75x faster than our previous release This is >6x (!) faster than our competitor’s BSP…
Added full HDMI support, including display auto-detection, hot-plug and dynamic resolution changes in CE
This means you can plug in a 1360×768 monitor and have the CE desktop shown in that resolution, then unplug the monitor and plug in a 1920×1080 monitor and CE will dynamically change resolution and show the desktop in 1920×1080 resolution, all this of course without the purple line on the left (a long standing problem in all the other iMX6 BSPs available).
HDMI, LVDS and LCD display output is now configurable in the bootloader
This means we have one kernel image for all. Just go into the bootloader menu and select which display you are using at which resolution and launch the kernel. Simple as that!
Added support for DMA on all UARTs
Full RX & TX DMA support on UART1, 2, 3, 4 and 5.
Upgraded to the latest Vivante GPU GALCORE driver v5.0.11 (25762)
And we added all the tutorials and test code as well. Together with the amazing performance increase of this release you can now enjoy 110+ fps in full screen 1920×1080 (and 350+ fps windowed) for OpenGL-ES 1.1/2.0! The OpenVG spinning tiger sample is now so fast you only see a blur, and we fully support OpenCL on Dual and Quad of course.
Now asynchronously loading drivers for faster boot
Maximum CPU temperature at rest: 45°C / 113°F
Maximum CPU temperature while running OpenGL-ES 2.0 reflecting ball: 65°C / 149°F
This is not nearly as low as we would like, but it’s a lot better already. Our next release will focus on power-consumption and heat generation reductions.
Improved network performance
The performance improvements also make Ethernet throughput a lot better. We’re only halfway to reaching the theoretical maximum possible on the iMX6 of ~45 MByte/s (it’s on our list of things to fix), but at least Ethernet speeds are out of the KByte range now.
Boundary Devices is a partner with the QT Company. The QT company recently put together a blog post showcasing our Nitrogen6X board, 5MP MIPI camera, and 7″ LVDS display running QT 5.5. The computer vision demo shows off the capabilities of the i.MX6 processor as well as the vision algorithms available within QT5.5.
Boundary Devices will soon be releasing a version of the Nitrogen6_MAX with the Quad Plus processor. The Nitrogen6_MAX is a good fit for the Quad Plus Processor because it offers the full 4GB DDR3 memory as well as other high end features including eMMC and Dual LVDS.
Here are the notable improvements from the standard i.MX6 Quad to the i.MX6 Quad PLUS:
Dramatic graphics performance with enhanced versions of 3D, 2D and composition GPUs and memory bandwidth utilization
Improve the system performance of i.MX 6 class systems by dramatically increasing the memory bandwidth utilization without significant impact to Software or Hardware designs
Improvement of the internal bus interconnect to more efficiently transport and order memory requests to the DDR controller.
Significantly upgraded the capabilities of the graphic and display subsystems to generate more efficient memory requests, resulting in further bandwidth improvements. (interchangeable tiled buffer, pre-fetch / resolve modules, larger OCRAM)
This is a nice video put together at FTF by Freescale that shows the notable improvements: Freescale Quad Plus at FTF
The i.MX6 Quad Plus processor will be officially released by Freescale in November 2015. Boundary Devices will have Nitrogen6_MAX boards available with the Quad Plus in the same time frame.
The i.MX6 SoloX processor is the first of a kind, coupling a Cortex-A9 with a Cortex-M4 core inside one chip to offer the best of both MPU and MCU worlds. The MCU is perfect for all the real-time tasks whereas the MPU can provide a great UI experience with non real-time OS such as GNU/Linux.
Image may be NSFW. Clik here to view.
SoloX Block Diagram
This blog post will detail how to build and run source code on the MCU using our Nit6_SoloX.
Terminology
Before getting any further, here is a list of terms that will be used in this post:
MCC: Multi-Core Communication: protocol offered by Freescale for the MCU and MPU to exchange data
MCU: Microcontroller Unit such as the ARM Cortex-M series, here referring to the Cortex-M4
MPU: Microprocessor Unit such as the ARM Cortex-A series, here referring to the Cortex-A9
MQX: RTOS provided by Freescale to run their MCUs
RTOS: Real-Time Operating System such as MQX or FreeRTOS
As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 1GB SD card image that can be restored using zcat and dd under Linux.
As specified in the documentation, you need to install a specific toolchain (CodeSourcery v2014q1) in order to build the BSP.
~$ cd && mkdir toolchains && cd toolchains
~/toolchains$ wget https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update/+download/gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2
~/toolchains$ tar xjf gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2
~/toolchains$ rm gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2
Your machine is now ready to build applications for the MCU!
Build instructions
This section explains how to build the BSP as well as the applications for the MCU only. In order to build the BSP for the MPU, please refer to other blog posts on either Yocto or Buildroot.
~$ cd ~/mqx/
~/mqx$ export TOP=$PWD
~/mqx$ export TOOLCHAIN_ROOTDIR=$HOME/toolchains/gcc-arm-none-eabi-4_8-2014q1/
~/mqx$ cd $TOP/build/imx6sx_nit6sx_m4/make
~/mqx$ ./build_gcc_arm.sh
As the BSP for our board is now built, we can build any example application provided in the MQX package. In order to have an interaction between the MPU and the MCU, you need to build a MCC application. Below are the instructions to build the pingpong application which sends data back and forth between the cores.
Some might be interested in using an IDE to browse/modify/build the source code, note that Freescale provides instructions to use IAR Workbench (Windows only). It seems that there isn’t any plan to support the SoloX MQX release inside the KSDK (Kinetis SDK) as explained in a community forum post.
Run the demo
First you need to copy the image (20150814-buildroot-nitrogen6x-mcu-demo.img.gz) provided at the beginning of this post to an SD Card. Then copy the m4_fw.bin binary to the root directory of the SD Card.
The SD Card contains the U-Boot version that enables the use of the Cortex-M4, the bootloader inside your NOR must therefore be upgraded.
U-Boot > setenv bootfile u-boot.imx
U-Boot > run upgradeu
Once the upgrade is complete and the board restarted, make sure to have a clean environment:
U-Boot > env default -a
## Resetting to default environment
U-Boot > saveenv
By default, the M4 must be flashed in NOR memory, a U-Boot command has been added to look for the m4_fw.bin as the root of any external storage (SD, USB, SATA):
U-Boot > run m4update
This command will download the firmware from external storage to RAM and flash it at the offset 0x1E0000 of the NOR.
While debugging on the MCU, you might wish not to write every firmware into NOR so we’ve added a command that loads the M4 firmware directly from external storage.
U-Boot > setenv m4boot 'run m4boot_ext'
Before going any further, make sure to hook up the second serial port to your machine as the one marked as “console” will be used for U-Boot and the other one will display data coming from the MCU. In order to start the MCU at boot up, we need to set a variable that will tell the 6x_bootscript to load the firmware into OCRAM. If you wish to start the MCU at every boot, make sure to save this variable.
U-Boot > setenv m4enabled 1
U-Boot > boot
While the kernel is booting, you should see the following prompt on the MCU serial output:
***** MCC PINGPONG EXAMPLE *****
Please wait :
1) A9 peer is ready
Then press "S" to start the demo
********************************
Press "S" to start the demo :
Press the S key as requested above on the MCU serial console and then log into Buildroot on the MPU serial output (login is root, no password). You now need to enable the MPU side of the communication before starting the demo:
# echo 1 > /sys/bus/platform/drivers/imx6sx-mcc-test/mcctest.15/pingpong_en &
A9 mcc prepares run, MCC version is 002.000
test/mcctest.15/pingpong_en &
# Main task received a msg from [1, 0, 2] endpoint
Message: Size=0x00000004, data = 0x00000002
Main task received a msg from [1, 0, 2] endpoint
Message: Size=0x00000004, data = 0x00000004
...
That’s it, you’ve built a MCU application from scratch and can now start exploring all the examples provided inside the MQX SoloX release.
