Yocto Project Compatible
This BSP is compatible with the Yocto Project as per the requirements
This layer depends on:
Table of Contents
I. Building the meta-intel BSP layer
II. Installing Image to Media
I. Building the meta-intel/common BSP layer
In order to build an image with BSP support for a given release, you
need to download the corresponding BSP tarball from the 'Board Support
Package (BSP) Downloads' page of the Yocto Project website.
Having done that, and assuming you extracted the BSP tarball contents
at the top-level of your yocto build tree, you can build a meta-intel
image by adding the location of the meta-intel layer to
To enable the meta-intel layer, add the either of the follow to MACHINE
in your local.conf:
MACHINE ?= "intel-core2-32"
MACHINE ?= "intel-corei7-64"
MACHINE ?= "intel-quark"
You should then be able to build your image as such:
$ source oe-init-build-env
$ bitbake core-image-sato
At the end of a successful build, you should have a live image that
you can boot from a USB flash drive (see instructions on how to do
that below, in the section 'Booting the images from /binary').
NOTE: The meta-intel machines will include support for hardware video
acceleration via gstreamer if and only if the "commercial" string is
added to the the LICENSE_FLAGS_WHITELIST variable in your local.conf.
LICENSE_FLAGS_WHITELIST = "commercial"
The reason this is needed is to prevent the image from including
anything that might violate the license terms of the packages used to
implement the the video acceleration feature, such as gst-ffmpeg and
ffmpeg. As always, please consult the licenses included in the
specific packages for details if you use packages that require
The xf86-video-intel recipe depends on Xorg's dri and glx modules,
which are built only when 'opengl' is listed in DISTRO_FEATURES. So
if the distro doesn't list 'opengl' in the DISTRO_FEATURES, then you
would need this additional line in your local.conf:
DISTRO_FEATURES_append = " opengl"
As an alternative to downloading the BSP tarball, you can also work
directly from the meta-intel git repository. For each BSP in the
'meta-intel' repository, there are multiple branches, one
corresponding to each major release starting with 'laverne' (0.90), in
addition to the latest code which tracks the current master (note that
not all BSPs are present in every release). Instead of extracting a
BSP tarball at the top level of your yocto build tree, you can
equivalently check out the appropriate branch from the meta-intel
repository at the same location.
II. Installing Image to Media
For intel-core* BSPs use this, see below for intel-quark information
This BSP contains bootable live images, which can be used to directly
boot Yocto off of a USB flash drive.
Under Linux, insert a USB flash drive. Assuming the USB flash drive
takes device /dev/sdf, use dd to copy the live image to it. For
# dd if=core-image-sato-intel-core2-32.hddimg of=/dev/sdf
# eject /dev/sdf
This should give you a bootable USB flash device. Insert the device
into a bootable USB socket on the target, and power on. This should
result in a system booted to the Sato graphical desktop.
If you want a terminal, use the arrows at the top of the UI to move to
different pages of available applications, one of which is named
'Terminal'. Clicking that should give you a root terminal.
If you want to ssh into the system, you can use the root terminal to
ifconfig the IP address and use that to ssh in. The root password is
empty, so to log in type 'root' for the user name and hit 'Enter' at
the Password prompt: and you should be in.
If you find you're getting corrupt images on the USB (it doesn't show
the syslinux boot: prompt, or the boot: prompt contains strange
characters), try doing this first:
# dd if=/dev/zero of=/dev/sdf bs=1M count=512
For intel-quark a sample .wks file is provided to use with the wic script.
All prebuilt binaries utilize a time-limited kernel. Yocto Project users should build their own kernel image in their end product.
Please submit any patches against this BSP to the meta-intel mailing list
(firstname.lastname@example.org) and cc: the maintainer:
Maintainer: Saul Wold
Please see the meta-intel/MAINTAINERS file for more details.
The intel-* BSPs, also known as the intel-common BSPs, provide a few
carefully selected tune options and generic hardware support to cover
the majority of current Intel CPUs and devices. The naming follows the
convention of intel--, where TUNE is the gcc cpu-type (used
with mtune and march typically) and BITS is either 32 bit or 64 bit.
This BSP is optimized for the Core2 family of CPUs as well as all Atom
CPUs prior to the Silvermont core.
This BSP is optimized for Nehalem and later Core and Xeon CPUs as well
as Silvermont and later Atom CPUs, such as the Baytrail and Braswell
This BSP is optimized for the X1000 / Quark family of SoCs using the
Galileo Gen 1/2 platforms.
These BSPs use what we call the intel-common Linux kernel package
architecture. This includes core2-32-intel-common, corei7-64-intel-common
and intel-quark. These kernel packages can also be used by any of
the BSPs in meta-intel that choose to include the
intel-common-pkgarch.inc file. To minimize the proliferation of vendor
trees, reduce the sources we must support, and consolidate QA efforts,
all BSP maintainers are encouraged to make use of the intel-common Linux
kernel package architecture.
Of the BSPs presently included in meta-intel, the following have passed
initial testing with the intel-common BSPs (rather than the named BSP):
Hardware used to test intel-corei7-64:
MinnowBoard MAX (64bit firmware)
Walnut Canyon 2 (Broadwell)
Hardware used to test intel-core2-32:
MinnowBoard MAX (32bit firmware)
Hardware used to test intel-quark:
Galileo Gen 1
Galileo Gen 2
If you are interested in a BSP not listed here, chances are we are
currently working on resolving some configuration issues with it. Please
check the bugzilla and check in with us on the meta-intel mailing list.
* HDMI audio issue caused by PulseAudio defect
* eMMC installation failure caused by defect in install-efi
Both of these have patches applied to the stable branch of Jethro, but not in 2.0 release tarball.
* GCC Link Time Optimization (LTO) drops the compiler tunings, disable LTO
where possible to avoid this issue.
* GPIO Expander support in the upstream kernel is still a WIP.