The MinnowBoard Chronicles Episode 19: The Yocto Project

After working with UEFI over the last 18 episodes of the MinnowBoard Chronicles, I’ve decided to install Linux on my MinnowBoard. It is turning out to be harder than I thought.

Installing Ubuntu 16.04.1 LTS on the MinnowBoard Turbot is actually pretty easy. There is a tutorial available online at, and it is fairly clear and easy to understand and follow. But, never one to be satisfied with doing the obvious, I decided to do my own Linux build for the MinnowBoard using the Yocto Project. I’m using this as a “training exercise” for doing a complete OpenBMC build on the new Portwell Neptune Alpha board I’ve got:

IMG_2482 (1)

I intend to document my OpenBMC work within a forthcoming series of The Neptune Alpha Chronicles, but, first, I wanted to get comfortable with the Yocto Project.

What is the Yocto Project? It’s described on its website as:

The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture. It was founded in 2010 as a collaboration among many hardware manufacturers, open-source operating systems vendors, and electronics companies to bring some order to the chaos of embedded Linux development.

Why use the Yocto Project? It's a complete embedded Linux development environment with tools, metadata, and documentation – everything you need. The free tools are easy to get started with, powerful to work with (including emulation environments, debuggers, an Application Toolkit Generator, etc.) and they allow projects to be carried forward over time without causing you to lose optimizations and investments made during the project’s prototype phase. The Yocto Project fosters community adoption of this open source technology allowing its users to focus on their specific product features and development.

In other words, Yocto will allow me to build a complete open source Linux image for the MinnowBoard, and then ultimately for the Neptune Alpha. That sounds like fun!

A good place to start for this little effort of mine is at the Yocto Quick Start Guide. In fact, the Quick Start Guide has an example specifically targeted for the MinnowBoard, which is ideal.

I quickly realized that I had some work to do to get the build host minimum configuration set up:

A build host with a minimum of 50 Gbytes of free disk space that is running a supported Linux distribution (i.e. recent releases of Fedora, openSUSE, CentOS, Debian, or Ubuntu).

Not having a Linux box at home (remember, I’m not really an engineer; just a salesperson with a keen interest in technology, so I lack high-powered hardware!), it was time to set up a Linux VM on the pokey dual-core Windows desktop I have at home. Spending many hours on this (that may be a subject of a future blog by itself), I finally got it working thanks to directions from Linux Fundamentals by Paul Cobbaut, and the VirtualBox User Manual from Oracle.

Following the Yocto Quick Start Guide, I first need to install lots of new packages, and then clone the poky repository and check out the latest Yocto Project Release (as of the time of this writing, 2.3):

$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \

build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \

xz-utils debianutils iputils-ping libsdl1.2-dev xterm


$ git clone git://

Cloning into 'poky'…

remote: Counting objects: 361782, done.

remote: Compressing objects: 100% (87100/87100), done.

remote: Total 361782 (delta 268619), reused 361439 (delta 268277)

Receiving objects: 100% (361782/361782), 131.94 MiB | 6.88 MiB/s, done.

Resolving deltas: 100% (268619/268619), done.

Checking connectivity… done.

$ git checkout pyro

Yocto Project graphic

That’s as far as I got this week. Next week, I’ll do the image build, maybe try it out on the QEMU emulator, and then install it into my MinnowBoard.

And now, a word from my sponsor: I eventually plan to debug this with ASSET’s SourcePoint JTAG hardware-assisted debugger. And, my interest in OpenBMC stems from our ScanWorks Embedded Diagnostics remote JTAG run-control solution for hyperscale platforms. For more information, read our technical overview (note: requires registration).

Alan Sguigna