the yocto project

Ross Burton, Userspace Architect for Yocto Open Source Technology Centre at Intel This session is a high level introduction to the Yocto Project

What is the Yocto Project?

Appears to be confusion in the automotive community about the Yocto Project. What is is, what it can offer and so on. We were invited by the LF to come here and clarify what Yocto is. So, the Yocto Project is...

Umbrella project

An umbrella project. You don't download or install the Yocto Project itself Just like you don't install the Apache Foundation

Build environmentand development tools

An embedded build environment and development tools Specifically, a build system (bitbake), package metadata (oe-core), Eclipse plugin, Application Development Toolkit (deployable toolchain)

x86 • ARMMIPS • PowerPC

We support all of the big architectures. oe-core builds for qemu machines for all of these architectures Ensures that the core builds for everything Optional BSPs for specific platform support Everything is cross compiled, so no "but it worked for x86" problems

Collaboration space

Finally YP is a collaboration space, providing a forum for users to share their problems and solutions Public mailing lists and weekly phone conference PAUSE

So many choices…

When picking a platform what's the difference between yocto and android, linaro, tizen, buildroot, baserock, or hacking your favourite desktop distribution...

…why pick the Yocto Project?

YP is Linux for embedded, from a small ARM board to mission critical xeon clusters Builds a custom distro suited to your needs Easy to add, remove, or change components Open development process, no code drops or license complications

Some are easy to hack on,but you’ll regret it later

Especially if your target is x86, it's easy to start with a desktop distribution and chop pieces out Building new pieces and rebuilding the pieces that need changes But when you need to change hardware, or rebuild with different compiler flags It's not that easy any more

Designed for the long term

Yocto is designed for long term use Six monthly release cycle but maintained release branches Commercial support from OSVs Tools to help do the mundane distribution building - Generate package repos and disk images - Static release archives for license compliance

Won’t fall apart in time

Yocto won't surprise you late in product development Reproducable builds for the entire system Clear process for updates - easy to make the changes and publish a new image or repo GPL compliant - trivial to public source *and* build instructions

Who is in the Yocto Project?

Not a complete list

Hardware manufacturers

i.e. Intel, Texas Instruments, Freescale

Embedded OSVs

i.e. Wind River, MontaVista, Enea Software, Mentor Graphics Commercial supported linux from these vendors

Consultants and individuals

Consultants, small and large individuals "scratching an itch" for their own projects

Advisory Board

finally should mention the advisory board. Yocto is a project at the Linux Foundation, not owned by any particular company The advisory board is comprised of reps from member companies working on Yocto The boards first action was to name itself "advisory board" rather than "steering group" to reflect that it offers advice and input and doesn't control the project technical direction entirely in the hands of the architects and maintainers

How does it work?

Enough about what the Yocto Project can do How does it work?

It’s all about the layers

A YP distribution is assembled from a number of layers Layers are modular and you can combine layers from different sources An example

Bitbake

Build system

oe-coreBitbake

core metadata toolchain, kernel, eglibc, cairo, gstreamer, Xorg, Wayland (soon), gtk/qt

meta-inteloe-coreBitbake

unless you happy with a qemu emulated machine you'll need a bsp Intel hardware BSP, such as cedar trail (atom, netbook/industrial), fish river island 2 (atom, digital signage, smart services), jasper forest (xeon, server)

meta-yoctometa-inteloe-coreBitbake

Distribution policy (Poky in meta-yocto for historial reasons)

Let’s build something!

Enough talk, let's pretend to build something.

$ wget http://downloads.yoctoproject.org/… /poky-denzil-7.0.tar.bz2$ tar xjf poky-denzil-7.0.tar.bz2$ cd poky-denzil-7.0

One of the downloads from the Yocto Project is Poky, a reference distribution. This is basically Bitbake, oe-core, and meta-yocto glued together for convenience Grabbing and extracting the tarball of the 7.0 "denzil" release is as you'd expect

$ ./oe-init-build-env ### Shell environment set up for builds. ### You can now run 'bitbake <target>‘ Common targets are: core-image-minimal core-image-sato … $ emacs conf/local.conf

First you need to source a shell script to setup the environment. Now lets have a quick look at the configuration file

# BB_NUMBER_THREADS = "4" # PARALLEL_MAKE = "-j 4" MACHINE ??= "qemux86" … #MACHINE ?= "qemuarm" #MACHINE ?= "qemumips" #MACHINE ?= "atom-pc" #MACHINE ?= "beagleboard"

Just a small fragment of the options available. Defaults are all reasonable and it will successfully build out of the box. For a faster build, change the parallel options. My build machine is a quad core with hyperthreading, so I set both of those to 8 to keep it busy Default target is x86 on qemu. This is trivially changed by simply changing the MACHINE variable. Other options include where to keep downloaded tarballs; location of any mirrors; features to enable such as multiarch, installing the toolchain in the image for development, what package format to use, and more.

$ bitbake core-image-minimal

Then, you can run bitbake with the name of the target you want Targets can be anything - images, packages, or operations. Let's build core-image-minimal, a small system that boots to a console good start to build up from if you're making a single-purpose system

Currently 7 running tasks (5452 of 9438):0: webkit-gtk-1.8.2-r1 do_compile (pid 27137)1: qt4-embedded-4.8.1-r48.1 do_compile (pid 27129)2: qt4-x11-free-4.8.1-r46.1 do_compile (pid 27096)3: systemtap-1.8+git1…-r0 do_compile (pid 27130)4: gmp-5.0.5-r0 do_package_write_rpm (pid 27131)5: libglade-2.6.4-r4 do_package_write_rpm (pid 27134)6: nfs-utils-1.2.3-r5 do_unpack (pid 27187)

While bitbake is running you'll see a report of what it's doing, something like this. This isn't actually the output from core-image-minimal but a colleague's world build that happened to be running when I was writing the slides. Poor guy is in for a long wait, webkit and two qt builds.

$ ls tmp/deploy/images/…core-image-minimal-atom-pc-20120918205848.hddimgcore-image-minimal-atom-pc-20120918205848.isocore-image-minimal-atom-pc-20120918205848.rootfs.cpio.gzcore-image-minimal-atom-pc-20120918205848.rootfs.ext3

When it finishes building the results are in the deploy directory Here we can see the constructed root file system as a cpio archive, a bare filesystem, a bootable ISO image, and a disk image. Generally I'd be writing the disk image to a fast USB stick with dd and booting from that for testing. The build output is configurable per build and per machine. This build was for a fairly standard Intel system so the final output is typically bootable on those. Build for a say beagleboard and you'll get kernel, bootloader and rootfs tarballs to write a SD card. alongside the images directory there is the package repository that was used to construct the root fs. This can be shared on the network and used as a normal repository, ie install some development or debug symbol packages to fix a bug.

Hob

Hob is a graphical interface to bitbake demo gremlins have decided to break hob on this laptop - works on my build machine 1st iteration, gtk+ application to configure an image and monitor the build 2nd iteration, web-based. currently under development.

Now what?

So that's how to build an image, but what could we do with it? Two quick ideas

Virtualisation

I expect virtualisation to be common in next-generation automotive systems as individual processors become more powerful and logically separate systems are ran in virtual machines on fewer physical processors. Because systems built by Yocto can be trivially tuned to be exactly what is required and nothing else they are a good match for virtualised systems, both as a minimal host that does simply manages the virtual machines, or as a specialized virtual machine itself.

Specialised subsystem

Cars are complicated beasts these days with many processors performing specialised roles Dashboard, engine management, and so on.

Q&A

Thanks!

Credits

cars2.jpg http://www.flickr.com/photos/15443451@N00/516336421/ Creative Commons 2.0 BY-NC-SA (C) Piyapat Ch. cables.jpg group.jpg tumble.jpg umbrella.jpg (C) David Stewart, All Rights Reserved, Used with Permission. tools.jpg http://www.flickr.com/photos/22749993@N08/5386712834/ Creative Commons 2.0 BY (C) Jim Pennucci cpus.jpg http://www.flickr.com/photos/17642817@N00/4553998825/ Creative Commons 2.0 BY (C) Jason Rogers people.jpg http://www.flickr.com/photos/29370225@N03/6292167005/ Creative Commons 2.0 BY (C) Roberto Trm minifigs.jpg http://www.flickr.com/photos/40646519@N00/305410323/ Creative Commons 2.0 BY (C) peter dutton engineer.jpg http://www.flickr.com/photos/39066002@N05/3595313340/