diff options
Diffstat (limited to 'presentations/automotive-linux-summit-2012/automotive.pin')
-rw-r--r-- | presentations/automotive-linux-summit-2012/automotive.pin | 369 |
1 files changed, 369 insertions, 0 deletions
diff --git a/presentations/automotive-linux-summit-2012/automotive.pin b/presentations/automotive-linux-summit-2012/automotive.pin new file mode 100644 index 0000000..c5292fb --- /dev/null +++ b/presentations/automotive-linux-summit-2012/automotive.pin | |||
@@ -0,0 +1,369 @@ | |||
1 | #!/usr/bin/env pinpoint | ||
2 | |||
3 | [fill] | ||
4 | [bottom] | ||
5 | [font=ITC Kabel Semi-Bold 60px] | ||
6 | [transition=fade] | ||
7 | -- [yocto.jpg] [duration=15.152699] | ||
8 | |||
9 | # Ross Burton, Userspace Architect for Yocto | ||
10 | # Open Source Technology Centre at Intel | ||
11 | # This session is a high level introduction to the Yocto Project | ||
12 | |||
13 | -- [cars2.jpg] [duration=18.412748] | ||
14 | What is the Yocto Project? | ||
15 | # Appears to be confusion in the automotive community about the Yocto Project. | ||
16 | # What is is, what it can offer and so on. | ||
17 | # We were invited by the LF to come here and clarify what Yocto is. | ||
18 | # So, the Yocto Project is... | ||
19 | |||
20 | -- [umbrella.jpg] [duration=13.583521] | ||
21 | Umbrella project | ||
22 | # An umbrella project. | ||
23 | # You don't download or install the Yocto Project itself | ||
24 | # Just like you don't install the Apache Foundation | ||
25 | |||
26 | -- [tools.jpg] [duration=27.991919] | ||
27 | Build environment | ||
28 | and development tools | ||
29 | # An embedded build environment and development tools | ||
30 | # Specifically, a build system (bitbake), package metadata (oe-core), | ||
31 | # Eclipse plugin, Application Development Toolkit (deployable toolchain) | ||
32 | |||
33 | -- [cpus.jpg] [text-align=center] [center] [duration=49.765675] | ||
34 | x86 • ARM | ||
35 | MIPS • PowerPC | ||
36 | # We support all of the big architectures. | ||
37 | # oe-core builds for qemu machines for all of these architectures | ||
38 | # Ensures that the core builds for everything | ||
39 | # Optional BSPs for specific platform support | ||
40 | # Everything is cross compiled, so no "but it worked for x86" problems | ||
41 | |||
42 | -- [people.jpg] [duration=22.377592] | ||
43 | Collaboration space | ||
44 | # Finally YP is a collaboration space, providing a forum | ||
45 | # for users to share their problems and solutions | ||
46 | # Public mailing lists and weekly phone conference | ||
47 | # PAUSE | ||
48 | |||
49 | -- [minifigs.jpg] [center] [duration=18.553514] | ||
50 | So many choices… | ||
51 | # When picking a platform what's the difference between yocto and | ||
52 | # android, linaro, tizen, buildroot, baserock, or hacking your | ||
53 | # favourite desktop distribution... | ||
54 | |||
55 | -- [engineer.jpg] [duration=56.184429] | ||
56 | …why pick the Yocto Project? | ||
57 | # YP is Linux for embedded, from a small ARM board to mission critical | ||
58 | # xeon clusters | ||
59 | # Builds a custom distro suited to your needs | ||
60 | # Easy to add, remove, or change components | ||
61 | # Open development process, no code drops or license complications | ||
62 | |||
63 | -- [cables.jpg] [duration=40.872715] | ||
64 | Some are easy to hack on, | ||
65 | but you’ll regret it later | ||
66 | # Especially if your target is x86, it's easy to start with a | ||
67 | # desktop distribution and chop pieces out | ||
68 | # Building new pieces and rebuilding the pieces that need changes | ||
69 | # But when you need to change hardware, or rebuild with different compiler flags | ||
70 | # It's not that easy any more | ||
71 | |||
72 | -- [road.jpg] [top] [duration=47.108444] | ||
73 | Designed for the long term | ||
74 | # Yocto is designed for long term use | ||
75 | # Six monthly release cycle but maintained release branches | ||
76 | # Commercial support from OSVs | ||
77 | # Tools to help do the mundane distribution building | ||
78 | # - Generate package repos and disk images | ||
79 | # - Static release archives for license compliance | ||
80 | |||
81 | -- [tumble.jpg] [top] [duration=45.338825] | ||
82 | Won’t fall apart in time | ||
83 | # Yocto won't surprise you late in product development | ||
84 | # Reproducable builds for the entire system | ||
85 | # Clear process for updates - easy to make the changes | ||
86 | # and publish a new image or repo | ||
87 | # GPL compliant - trivial to public source *and* build instructions | ||
88 | |||
89 | -- [group.jpg] [duration=9.779828] | ||
90 | Who is in the Yocto Project? | ||
91 | # Not a complete list | ||
92 | |||
93 | -- [chip.jpg] [duration=15.615728] | ||
94 | Hardware manufacturers | ||
95 | # i.e. Intel, Texas Instruments, Freescale | ||
96 | |||
97 | -- [tins.jpg] [duration=26.482639] | ||
98 | Embedded OSVs | ||
99 | # i.e. Wind River, MontaVista, Enea Software, Mentor Graphics | ||
100 | # Commercial supported linux from these vendors | ||
101 | |||
102 | -- [cat.jpg] [duration=31.311359] | ||
103 | Consultants and individuals | ||
104 | # Consultants, small and large | ||
105 | # individuals "scratching an itch" for their own projects | ||
106 | |||
107 | -- [owl.jpg] [top] [duration=60.471573] | ||
108 | Advisory Board | ||
109 | # finally should mention the advisory board. | ||
110 | # Yocto is a project at the Linux Foundation, not owned by any | ||
111 | # particular company | ||
112 | # The advisory board is comprised of reps from member companies | ||
113 | # working on Yocto | ||
114 | # The boards first action was to name itself "advisory board" rather | ||
115 | # than "steering group" to reflect that it offers advice and input and | ||
116 | # doesn't control the project technical direction entirely in the | ||
117 | # hands of the architects and maintainers | ||
118 | |||
119 | -- [xwing.jpg] [duration=10.061844] | ||
120 | How does it work? | ||
121 | # Enough about what the Yocto Project can do | ||
122 | # How does it work? | ||
123 | |||
124 | -- [cake.jpg] [duration=36.383984] | ||
125 | It’s all about the layers | ||
126 | # A YP distribution is assembled from a number of layers | ||
127 | # Layers are modular and you can combine layers from different sources | ||
128 | # An example | ||
129 | |||
130 | -- [blueprint.jpg] [text-align=center] [duration=19.801914] | ||
131 | Bitbake | ||
132 | # Build system | ||
133 | |||
134 | -- [blueprint.jpg] [text-align=center] [transition=none] [duration=42.480724] | ||
135 | oe-core | ||
136 | Bitbake | ||
137 | # core metadata | ||
138 | # toolchain, kernel, eglibc, cairo, gstreamer, Xorg, Wayland (soon), gtk/qt | ||
139 | |||
140 | -- [blueprint.jpg] [text-align=center] [transition=none] [duration=27.569431] | ||
141 | meta-intel | ||
142 | oe-core | ||
143 | Bitbake | ||
144 | # unless you happy with a qemu emulated machine you'll need a bsp | ||
145 | # Intel hardware BSP, such as cedar trail (atom, netbook/industrial), fish river | ||
146 | # island 2 (atom, digital signage, smart services), jasper forest (xeon, server) | ||
147 | |||
148 | -- [blueprint.jpg] [text-align=center] [transition=none] [duration=42.118870] | ||
149 | meta-yocto | ||
150 | meta-intel | ||
151 | oe-core | ||
152 | Bitbake | ||
153 | # Distribution policy | ||
154 | # (Poky in meta-yocto for historial reasons) | ||
155 | |||
156 | -- [corridor.jpg] [duration=15.193717] | ||
157 | Let’s build something! | ||
158 | # Enough talk, let's pretend to build something. | ||
159 | |||
160 | -- [corridor.jpg] [center] [duration=58.901318] | ||
161 | <tt>$ <b>wget http://downloads.yoctoproject.org/… | ||
162 | /poky-denzil-7.0.tar.bz2</b> | ||
163 | $ <b>tar xjf poky-denzil-7.0.tar.bz2</b> | ||
164 | $ <b>cd poky-denzil-7.0</b></tt> | ||
165 | # One of the downloads from the Yocto Project is Poky, a reference | ||
166 | # distribution. This is basically Bitbake, oe-core, and meta-yocto | ||
167 | # glued together for convenience Grabbing and extracting the tarball | ||
168 | # of the 7.0 "denzil" release is as you'd expect | ||
169 | |||
170 | -- [corridor.jpg] [center] [duration=44.895329] | ||
171 | <tt> $ <b>./oe-init-build-env</b> | ||
172 | ### Shell environment set up for builds. | ||
173 | ### You can now run 'bitbake <target>‘ | ||
174 | Common targets are: | ||
175 | core-image-minimal | ||
176 | core-image-sato | ||
177 | … | ||
178 | $ <b>emacs conf/local.conf</b></tt> | ||
179 | # First you need to source a shell script to setup the environment. | ||
180 | # Now lets have a quick look at the configuration file | ||
181 | |||
182 | -- [corridor.jpg] [center] [duration=64.857567] | ||
183 | <tt> # BB_NUMBER_THREADS = "4" | ||
184 | # PARALLEL_MAKE = "-j 4" | ||
185 | |||
186 | MACHINE ??= "qemux86" | ||
187 | … | ||
188 | #MACHINE ?= "qemuarm" | ||
189 | #MACHINE ?= "qemumips" | ||
190 | #MACHINE ?= "atom-pc" | ||
191 | #MACHINE ?= "beagleboard"</tt> | ||
192 | # Just a small fragment of the options available. Defaults are all | ||
193 | # reasonable and it will successfully build out of the box. | ||
194 | # For a faster build, change the parallel options. My build machine is | ||
195 | # a quad core with hyperthreading, so I set both of those to 8 to keep | ||
196 | # it busy | ||
197 | # Default target is x86 on qemu. This is trivially changed by simply | ||
198 | # changing the MACHINE variable. | ||
199 | # Other options include where to keep downloaded tarballs; location of | ||
200 | # any mirrors; features to enable such as multiarch, installing the | ||
201 | # toolchain in the image for development, what package format to use, | ||
202 | # and more. | ||
203 | |||
204 | -- [corridor.jpg] [center] [duration=38.235931] | ||
205 | <tt>$ <b>bitbake core-image-minimal</b></tt> | ||
206 | # Then, you can run bitbake with the name of the target you want | ||
207 | # Targets can be anything - images, packages, or operations. | ||
208 | # Let's build core-image-minimal, a small system that boots to a | ||
209 | # console good start to build up from if you're making a | ||
210 | # single-purpose system | ||
211 | |||
212 | -- [corridor.jpg] [center] [duration=61.638290] | ||
213 | <tt>Currently 7 running tasks (5452 of 9438): | ||
214 | 0: webkit-gtk-1.8.2-r1 do_compile (pid 27137) | ||
215 | 1: qt4-embedded-4.8.1-r48.1 do_compile (pid 27129) | ||
216 | 2: qt4-x11-free-4.8.1-r46.1 do_compile (pid 27096) | ||
217 | 3: systemtap-1.8+git1…-r0 do_compile (pid 27130) | ||
218 | 4: gmp-5.0.5-r0 do_package_write_rpm (pid 27131) | ||
219 | 5: libglade-2.6.4-r4 do_package_write_rpm (pid 27134) | ||
220 | 6: nfs-utils-1.2.3-r5 do_unpack (pid 27187)</tt> | ||
221 | # While bitbake is running you'll see a report of what it's doing, | ||
222 | # something like this. This isn't actually the output from | ||
223 | # core-image-minimal but a colleague's world build that happened to be | ||
224 | # running when I was writing the slides. Poor guy is in for a long | ||
225 | # wait, webkit and two qt builds. | ||
226 | |||
227 | -- [corridor.jpg] [center] [duration=33.001926] | ||
228 | <tt>$ <b>ls tmp/deploy/images/</b> | ||
229 | … | ||
230 | core-image-minimal-atom-pc-20120918205848.hddimg | ||
231 | core-image-minimal-atom-pc-20120918205848.iso | ||
232 | core-image-minimal-atom-pc-20120918205848.rootfs.cpio.gz | ||
233 | core-image-minimal-atom-pc-20120918205848.rootfs.ext3 | ||
234 | </tt> | ||
235 | # When it finishes building the results are in the deploy directory | ||
236 | # Here we can see the constructed root file system as a cpio archive, | ||
237 | # a bare filesystem, a bootable ISO image, and a disk image. | ||
238 | # Generally I'd be writing the disk image to a fast USB stick with dd | ||
239 | # and booting from that for testing. | ||
240 | # The build output is configurable per build and per machine. This | ||
241 | # build was for a fairly standard Intel system so the final output is | ||
242 | # typically bootable on those. Build for a say beagleboard and you'll | ||
243 | # get kernel, bootloader and rootfs tarballs to write a SD card. | ||
244 | # alongside the images directory there is the package repository that | ||
245 | # was used to construct the root fs. This can be shared on the network | ||
246 | # and used as a normal repository, ie install some development or | ||
247 | # debug symbol packages to fix a bug. | ||
248 | |||
249 | -- [hob.jpg] [duration=47.693535] | ||
250 | Hob | ||
251 | # Hob is a graphical interface to bitbake | ||
252 | # demo gremlins have decided to break hob on this laptop - works on my build machine | ||
253 | # 1st iteration, gtk+ application to configure an image and monitor the build | ||
254 | # 2nd iteration, web-based. currently under development. | ||
255 | |||
256 | -- [question.jpg] [duration=17.024797] | ||
257 | Now what? | ||
258 | # So that's how to build an image, but what could we do with it? | ||
259 | # Two quick ideas | ||
260 | |||
261 | -- [dolls.jpg] [top] [duration=42.701355] | ||
262 | Virtualisation | ||
263 | # I expect virtualisation to be common in next-generation automotive | ||
264 | # systems as individual processors become more powerful and logically | ||
265 | # separate systems are ran in virtual machines on fewer physical | ||
266 | # processors. | ||
267 | # Because systems built by Yocto can be trivially tuned to be exactly | ||
268 | # what is required and nothing else they are a good match for | ||
269 | # virtualised systems, both as a minimal host that does simply manages | ||
270 | # the virtual machines, or as a specialized virtual machine itself. | ||
271 | |||
272 | -- [dash.jpg] [top] [duration=24.712542] | ||
273 | Specialised subsystem | ||
274 | # Cars are complicated beasts these days with many processors performing specialised roles | ||
275 | # Dashboard, engine management, and so on. | ||
276 | |||
277 | -- [qa.jpg] [duration=10.726003] | ||
278 | Q&A | ||
279 | |||
280 | -- [yocto.jpg] | ||
281 | Thanks! | ||
282 | |||
283 | # Credits | ||
284 | # | ||
285 | # cars2.jpg | ||
286 | # http://www.flickr.com/photos/15443451@N00/516336421/ | ||
287 | # Creative Commons 2.0 BY-NC-SA (C) Piyapat Ch. | ||
288 | # | ||
289 | # cables.jpg | ||
290 | # group.jpg | ||
291 | # tumble.jpg | ||
292 | # umbrella.jpg | ||
293 | # (C) David Stewart, All Rights Reserved, Used with Permission. | ||
294 | # | ||
295 | # tools.jpg | ||
296 | # http://www.flickr.com/photos/22749993@N08/5386712834/ | ||
297 | # Creative Commons 2.0 BY (C) Jim Pennucci | ||
298 | # | ||
299 | # cpus.jpg | ||
300 | # http://www.flickr.com/photos/17642817@N00/4553998825/ | ||
301 | # Creative Commons 2.0 BY (C) Jason Rogers | ||
302 | # | ||
303 | # people.jpg | ||
304 | # http://www.flickr.com/photos/29370225@N03/6292167005/ | ||
305 | # Creative Commons 2.0 BY (C) Roberto Trm | ||
306 | # | ||
307 | # minifigs.jpg | ||
308 | # http://www.flickr.com/photos/40646519@N00/305410323/ | ||
309 | # Creative Commons 2.0 BY (C) peter dutton | ||
310 | # | ||
311 | # engineer.jpg | ||
312 | # http://www.flickr.com/photos/39066002@N05/3595313340/ | ||
313 | # Creative Commons 2.0 BY-NC-SA (C) RoberthK | ||
314 | # | ||
315 | # road.jpg | ||
316 | # http://www.flickr.com/photos/81851211@N00/5861614/ | ||
317 | # Creative Commons 2.0 BY-NC-SA (C) Rick Harrison | ||
318 | # | ||
319 | # chip.jpg | ||
320 | # http://www.flickr.com/photos/19616961@N00/41549347/ | ||
321 | # Creative Commons 2.0 BY (C) Rodrigo Senna | ||
322 | # | ||
323 | # tins.jpg | ||
324 | # http://www.flickr.com/photos/75771631@N00/5185871835/ | ||
325 | # Creative Commons 2.0 BY (C) Matthew Hine | ||
326 | # | ||
327 | # cat.jpg | ||
328 | # http://www.flickr.com/photos/9516941@N08/2286083797/ | ||
329 | # Creative Commons 2.0 BY (C) Tristan Bowersox | ||
330 | # | ||
331 | # owl.jpg | ||
332 | # http://www.flickr.com/photos/95962912@N00/161060725/ | ||
333 | # Creative Commons 2.0 BY-NC-SA (C) Nuno Barreto | ||
334 | # | ||
335 | # xwing.jpg | ||
336 | # http://www.flickr.com/photos/55723329@N00/6657150957/ | ||
337 | # Creative Commons 2.0 BY (C) psiaki | ||
338 | # | ||
339 | # cake.jpg | ||
340 | # http://www.flickr.com/photos/megpi/2690878513/ | ||
341 | # Creative Commons 2.0 BY-NC-SA (C) megpi | ||
342 | # | ||
343 | # blueprint.jpg | ||
344 | # http://www.flickr.com/photos/71745913@N00/2576799956/ | ||
345 | # Creative Commons 2.0 BY-NC-SA (C) HD41117 | ||
346 | # | ||
347 | # corridor.jpg | ||
348 | # http://www.flickr.com/photos/71865026@N00/1264424156/ | ||
349 | # Creative Commons 2.0 BY-SA (C) Mark Sebastian | ||
350 | # | ||
351 | # hob.jpg | ||
352 | # http://www.flickr.com/photos/11247388@N00/5436586179/ | ||
353 | # Creative Commons 2.0 BY (C) sunshinecity | ||
354 | # | ||
355 | # question.jpg | ||
356 | # http://www.flickr.com/photos/65555826@N00/1447024668/ | ||
357 | # Creative Commons 2.0 BY (C) wonderferret | ||
358 | # | ||
359 | # dolls.jpg | ||
360 | # http://www.flickr.com/photos/30692297@N07/5454308102/ | ||
361 | # Creative Commons 2.0 BY-NC-SA (C) Adrian S Jones | ||
362 | # | ||
363 | # dash.jpg | ||
364 | # http://www.flickr.com/photos/97856361@N00/167428099/ | ||
365 | # Creative Commons 2.0 BY-NC-SA (C) Albert Lynn | ||
366 | # | ||
367 | # qa.jpg | ||
368 | # http://www.flickr.com/photos/39039882@N00/22778226/ | ||
369 | # Creative Commons 2.0 BY-NC (C) Tantek Çelik | ||