The Yocto Project is an open source project that provides tools and methods for creating custom Linux-based systems for embedded products regardless of CPU architecture. It uses a "layer" approach where components like the build system, core packages, and machine-specific files can be mixed and matched. The speaker demonstrates how to download a Yocto Project release, configure a build, and run the build process to generate root filesystem images and packages for target deployment. Potential applications mentioned include virtualization platforms and specialized subsystems in vehicles.

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

3. What is the Yocto Project?

4. 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...

5. Umbrella project

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

7. Build environment
and development tools

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

9. x86 • ARM
MIPS • PowerPC

10. 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

11. Collaboration space

12. 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

13. So many choices…

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

15. …why pick the Yocto Project?

16. 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

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

18. 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

19. Designed for the long term

20. 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

21. Won’t fall apart in time

22. 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

23. Who is in the Yocto Project?

24. Not a complete list

25. Hardware manufacturers

26. i.e. Intel, Texas Instruments, Freescale

27. Embedded OSVs

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

29. Consultants and individuals

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

31. Advisory Board

32. 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

33. How does it work?

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

35. It’s all about the layers

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

37. Bitbake

38. Build system

39. oe-core
Bitbake

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

41. meta-intel
oe-core
Bitbake

42. 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)

43. meta-yocto
meta-intel
oe-core
Bitbake

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

45. Let’s build something!

46. Enough talk, let's pretend to build something.

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

48. 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

49. $ ./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

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

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

52. 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.

53. $ bitbake core-image-minimal

54. 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

55. 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)

56. 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.

57. $ ls tmp/deploy/images/
…
core-image-minimal-atom-pc-20120918205848.hddimg
core-image-minimal-atom-pc-20120918205848.iso
core-image-minimal-atom-pc-20120918205848.rootfs.cpio.gz
core-image-minimal-atom-pc-20120918205848.rootfs.ext3

58. 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.

59. Hob

60. 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.

61. Now what?

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

63. Virtualisation

64. 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.

65. Specialised subsystem

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

67. Q&A

68. Thanks!

69. 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