Navigating Linux on Intel Galileo

Cover Image of Galileo


Late in 2013, Intel released a new Arduino-compatible board called the Galileo. The board is special in that it's one of the first maker-friendly platforms to run x86 alongside a full Linux distribution. In this respect, it's a lot like the Raspberry Pi with some additional Arduino friendliness mixed in.

Glossing over the more straightforward Arduino compatibility, Galileo's Linux capabilities add an entire (and complex) layer to play with. In theory, x86 enables us to compile code without having to worry about a separate processor architecture as is the case with ARM. However, the current state of Galileo reminds me a lot of working with the earlier iPhone toolchains back in 2008/2009: great platform, but a lot of headache to get things initially working.

The reality is that the Galileo is built on the x1000 Quark SoC, a Pentium-class x86 core with a slew of modern extensions. Unfortunately, the toolchain for this arch isn't as straightforward as firing up Visual Studio and hitting compile. This post is a simple and high-level guide to introduce some of the Linux basics. Specific bits of code and commands aren't a part of this post since those things will invariably change as the platform evolves.

Much of the information here was compiled with the help of Seth Hunter from Intel Labs' Open Design Group and AlexT from Intel Poland. Seth and I came up with some requirements about standard suite of packages and drivers we would like for our own projects using Galileo, and this spawned a collaboration with AlexT who helped build us a custom Linux image introduced at the end of this guide.

Linux Versions

Galileo is designed to run two separate Linux versions. The first is a tiny 8mb image that sits in flash memory (also referred to as the SPI-Flash version), containing the bare essentials to run the Arduino side of things. It's surprising to note that the Arduino sketch is a userland Linux program as uploaded via the Arduino IDE. Since this version is so pared down, a more desirable option is to boot off an SD card.

The full SD card image, like the tiny version, is based on a community developed (and Intel funded) framework for building Linux distributions, Yocto. The default full image available on the Intel site is called the LSB, Linux Standard Build. So far, there hasn't been a huge amount of 'official' support for the board in terms of bugfixes and package management, but the community has picked up the slack to update software like Node.JS and enable new drivers for USB peripherals.

Prebuilt Images & Package Management

Getting started with the Galileo, the Intel-provided full Linux distribution has a swath of driver omissions and outdated software (a problem that was eventually solved in the Raspberry Pi community with NOOBS). A mitigating factor has been the appearance of pre built images to top-load the latest packages and drivers. One of the most prolific contributors to the community is an Intel employee, AlexT, who hacks on the platform at night since it's not part of his regular duties with the company. A good source for the latest and greatest full images can be found at AlexT's website:

These images consist of the primary ext3 filesystem (as an unmounted blob) alongside the Linux kernel, kernel modules, ram filesystem, and grub configuration. The SPI-Flash version will attempt to boot first, but will defer to an SD card if present. In contrast to other platforms like the R-Pi or BeagleBone, this filesystem is auto-mounted and doesn't need to be bit-for-bit flashed onto an SD card; it's enough to simply copy the files. This is a nice bit of user experience as Raspberry Pi tinkerers know well the cumbersome process of flashing images.

A solved problem for the ARM architecture (and particularly Debian & apt-get compatible distros) is a central package repository. ARM-HF (Hard Float) is supported as a target platform in the main apt repository, so people have compiled and uploaded tens of thousands of Linux packages ready-to-download for R-Pi. The Galileo community hasn't yet centralized around a single repository location (using opkg, the Yocto analog to apt) where a similar situation would be feasible. The present way to stay up to date is to continually download and use the latest unofficial images from AlexT. Alternatively, AlexT has set up his own repository where users can opt to use okpg to download working compiled binaries:

Yocto, Poky & BSPs

As mentioned earlier in the introduction, the Quark SoC uses i586, a Pentium architecture that requires some specific tooling. Thankfully, a mature toolset for building software on i586 does exist. In order of increasing complexity, these tools let you:

  1. Build application code directly on the Galileo
  2. Cross-compile application code on your local computer
  3. Cross-compile everything, rebuilding the entire OS image in the process.

On the Board

The first and obvious choice for compilation is directly on the Galileo itself, though the default 0.7.5 LSB does not contain the necessary build tools like gcc. Though, this isn't a problem with the unofficial images (see this for the relevant packages). Getting the build tools to work while retaining Arduino sketch compatibility has been an outstanding issue, however this appears to be fixed in AlexT's latest builds.


Going deeper, building software for the Galileo can also be done in a process called cross-compilation where another host OS (usually Linux, although Windows and OSX are supported to a lesser extent) produces a binary for the Quark architecture. The Arduino does this with the Galileo IDE in a transparent, invisible, and user-friendly way. Still, the enterprising hacker will want full control over this process for his or her own native apps.

Cross-compilation is best performed on a recent 64-bit Linux distro like Ubuntu 13.04, although it is, in theory, possible on Windows 7/8 and OSX 10.8+. My official recommendation? Spin up an Ubuntu virtual machine for the best user experience. The availability of a pre-configured virtual machine simplifies this process, complete with all the necessary tools and Quark BSP (more on the BSP below).

The one downside in using this VM method is that it suffers from maintenance issues. Someone needs to manually update the VM with the latest tools and software. Despite this, a pre-built VM is certainly the easiest way to get started:

Intel has also released something called the Yocto Application Development Toolkit (ADT) as part of their Internet of Things explorer challenge. It consists of an SD card image and a live USB image. The idea behind this is to boot your own computer off the live Yocto image where you may then cross-compile, upload, and debug directly off the Galileo if the two are connected via serial. This approach might be preferential since compiling, uploading (using SCP, SFTP, or a USB drive), and debugging may become tedious as discrete steps.

Hardcore Mode (Building your own Linux image)

The third and most full-on way of compiling software (or drivers) for Galileo is to build your own Linux distribution based on the Yocto framework. This is where Yocto, Poky, BSP, and Bitbake collide to delight and equally confuse.

But first, let's define some of these tools:

The Yocto Project is an open source project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture.

Building a Yocto image suitable for the Galileo uses Poky, a reference Linux distribution complete with a kernel and wide range of required and user-defined packages and drivers.

Poky is a reference system of the Yocto Project - a collection of Yocto Project tools and metadata that serves as a set of working examples. You can download Poky and use it to bootstrap your own distribution.

Another way of describing the relationship between these tools is this: Yocto is a framework for building an embedded Linux image, where Poky is the reference distribution. When adding new drivers or packages to the reference configuration, this new creation becomes a new & custom Linux distro based on Poky.

Board Support Packages

The final piece to this puzzle is a suite of scripts called the Board Support Package (BSP), a standard specifically created by the Yocto project. Other BSPs exist for all manners of platforms and architectures like ARM, x86 Atom, and many more. The BSP for Quark is periodically updated by Intel and contains all the Poky configuration for building the full and Flash-SPI images.

Lastly, Bitbake is the utility that handles a BSP configuration and builds the a custom Poky image from scratch. From scratch you say? Yes, when you Bitbake the BSP, realize that you are fully downloading a version of the Linux kernel + related packages and compiling them on your local machine. Although the resulting image is relatively small (totaling less than 1gb in the end), the compilation process will take hours, ~80GB of disk space, and as much RAM as your system has. Do it in the name of science!

A guide to this entire process using the 0.7.5 BSP is located here. BSP 0.8.0 and 1.0 have been released since this guide was written, though the steps are similar with the exception of naming changes. On the topic of naming, one thing to note is the BSPs refer to the name Clanton in many places, the internal working title of Quark before it was released to the public. With each new BSP release, the build guide provided by Intel is an invaluble resource for tinkering with the configuration.

In short, this method assumes you have setup an environment with the right tools. The BSP handles most of the complexity of working with Yocto and Poky, though you'll probably dig into the BSP configuration scripts to add your own utilities, packages, and drivers. Since the BSP is specific to Quark and not Galileo, getting a grasp of this process early on will be particularly powerful as other boards based on the x1000 start appearing.

Towards Making Things

This post has been in service of creating a new quick-start build for embedded projects. Things like USB audio and camera driver support, network timing (NTP), and the latest node.js are core components in my workflow. Though supported images will eventually provided by Intel, this new image -- created by AlexT with help from Seth Hunter -- is a stopgap for effective making with the Galileo. Find info on it here:

Comment -

Profile Image

Dimitri Diakopoulos