summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2012-06-14 17:51:45 (GMT)
committerRichard Purdie <richard.purdie@linuxfoundation.org>2012-06-29 13:59:24 (GMT)
commit7082a56c9568730abcff359809ea7732cf5df440 (patch)
tree666ffccd47e8a621d1f9bf8ee04034737b6dc4b6
parent49198215729f92e4dcd7015e88fb416b1e5df830 (diff)
downloadpoky-7082a56c9568730abcff359809ea7732cf5df440.tar.gz
documentation/dev-manual/dev-manual-bsp-appendix.xml: 1.1.2 variables and updates
First pass at implementing the poky.ent variables. Also, changed text in areas to better match what is in master. I left any example specific stuff alone for the most part. (From yocto-docs rev: 2b5d3ba8ee877eb55b9c052e0f194b37aa68c76a) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-rw-r--r--documentation/dev-manual/dev-manual-bsp-appendix.xml212
1 files changed, 124 insertions, 88 deletions
diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml
index 6850224..74d5406 100644
--- a/documentation/dev-manual/dev-manual-bsp-appendix.xml
+++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml
@@ -1,12 +1,13 @@
1<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 1<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> 2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
3 4
4<appendix id='dev-manual-bsp-appendix'> 5<appendix id='dev-manual-bsp-appendix'>
5 6
6<title>BSP Development Example</title> 7<title>BSP Development Example</title>
7 8
8<para> 9<para>
9 This appendix provides a complete BSP example. 10 This appendix provides a complete BSP development example.
10 The example assumes the following: 11 The example assumes the following:
11 <itemizedlist> 12 <itemizedlist>
12 <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem> 13 <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
@@ -31,47 +32,77 @@
31 The following paragraphs describe both methods. 32 The following paragraphs describe both methods.
32 For additional information, see the bulleted item 33 For additional information, see the bulleted item
33 "<link linkend='local-yp-release'>Yocto Project Release</link>". 34 "<link linkend='local-yp-release'>Yocto Project Release</link>".
34 </para> 35 </para>
35 36
36 <para> 37 <para>
37 As mentioned, one way to get the Yocto Project files is to use Git to clone the 38 As mentioned, one way to get the Yocto Project files is to use Git to clone the
38 <filename>poky</filename> repository: 39 <filename>poky</filename> repository.
40 These commands create a local copy of the Git repository.
41 By default, the top-level directory of the repository is named <filename>poky</filename>:
39 <literallayout class='monospaced'> 42 <literallayout class='monospaced'>
40 $ git clone git://git.yoctoproject.org/poky 43 $ git clone git://git.yoctoproject.org/poky
41 $ cd poky 44 $ cd poky
42 </literallayout> 45 </literallayout>
43 Alternatively, you can start with the downloaded Poky "edison" tarball: 46 Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
47 These commands unpack the tarball into a Yocto Project File directory structure.
48 By default, the top-level directory of the file structure is named
49 <filename>&YOCTO_POKY;</filename>:
44 <literallayout class='monospaced'> 50 <literallayout class='monospaced'>
45 $ tar xfj poky-edison-6.0.1.tar.bz2 51 $ tar xfj &YOCTO_POKY_TARBALL;
46 $ cd poky 52 $ cd &YOCTO_POKY;
47 </literallayout> 53 </literallayout>
48 <note>If you're using the tarball method, you can ignore all the following steps that 54 <note><para>If you're using the tarball method, you can ignore all the following steps that
49 ask you to carry out Git operations. 55 ask you to carry out Git operations.
50 You already have the results of those operations 56 You already have the results of those operations
51 in the form of the edison release tarballs. 57 in the form of the &DISTRO_NAME; release tarballs.
52 Consequently, there is nothing left to do other than extract those tarballs into the 58 Consequently, there is nothing left to do other than extract those tarballs into the
53 proper locations.</note> 59 proper locations.</para>
60
61 <para>Once you expand the released tarball, you have a snapshot of the Git repository
62 that represents a specific release.
63 Fundamentally, this is different than having a local copy of the Yocto Project
64 Git repository.
65 Given the tarball method, changes you make are building on top of a release.
66 With the Git repository method you have the ability to track development
67 and keep changes in revision control.</para></note>
54 </para> 68 </para>
55 69
56 <para> 70 <para>
57 Once you have the local <filename>poky</filename> Git repository set up, 71 With the local <filename>poky</filename> Git repository set up,
58 you have many development branches from which you can work. 72 you have all the development branches available to you from which you can work.
59 From inside the repository you can see the branch names and the tag names used 73 Next, you need to be sure that your local repository reflects the exact
60 in the Git repository using either of the following two commands: 74 release in which you are interested.
75 From inside the repository you can see the development branches that represent
76 areas of development that have diverged from the main (master) branch
77 at some point, such as a branch to track a maintenance release's development.
78 You can also see the tag names used to mark snapshots of stable releases or
79 points in the repository.
80 Use the following commands to list out the branches and the tags in the repository,
81 respectively.
61 <literallayout class='monospaced'> 82 <literallayout class='monospaced'>
62 $ git branch -a 83 $ git branch -a
63 $ git tag -l 84 $ git tag -l
64 </literallayout> 85 </literallayout>
65 For this example we are going to use the Yocto Project 1.1.1 Release, which is code 86 For this example, we are going to use the Yocto Project &DISTRO; Release, which is code
66 named "edison". 87 named "&DISTRO_NAME;".
67 These commands create a local branch named <filename>edison</filename> 88 To make sure we have a local area (branch in Git terms) on our machine that
68 that tracks the remote branch of the same name. 89 reflects the &DISTRO; release, we can use the following commands:
69 <literallayout class='monospaced'> 90 <literallayout class='monospaced'>
70 $ git checkout -b edison origin/edison 91 $ cd ~/poky
71 Switched to a new branch 'edison' 92 $ git fetch --tags
93 $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME;
94 Switched to a new branch '&DISTRO_NAME;'
72 </literallayout> 95 </literallayout>
96 The <filename>git fetch --tags</filename> is somewhat redundant since you just set
97 up the repository and should have all the tags.
98 The <filename>fetch</filename> command makes sure all the tags are available in your
99 local repository.
100 The Git <filename>checkout</filename> command with the <filename>-b</filename> option
101 creates a local branch for you named <filename>&DISTRO_NAME;</filename>.
102 Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball
103 marked with the <filename>&DISTRO_NAME;-&POKYVERSION;</filename> tag in the source repositories.
73 </para> 104 </para>
74</section> 105</section>
75 106
76<section id='choosing-a-base-bsp-app'> 107<section id='choosing-a-base-bsp-app'>
77 <title>Choosing a Base BSP</title> 108 <title>Choosing a Base BSP</title>
@@ -100,7 +131,7 @@
100 <para> 131 <para>
101 You need to have the base BSP layer on your development system. 132 You need to have the base BSP layer on your development system.
102 Similar to the local Yocto Project files, you can get the BSP 133 Similar to the local Yocto Project files, you can get the BSP
103 layer a couple of different ways: 134 layer in couple of different ways:
104 download the BSP tarball and extract it, or set up a local Git repository that 135 download the BSP tarball and extract it, or set up a local Git repository that
105 has the Yocto Project BSP layers. 136 has the Yocto Project BSP layers.
106 You should use the same method that you used to get the local Yocto Project files earlier. 137 You should use the same method that you used to get the local Yocto Project files earlier.
@@ -113,8 +144,8 @@
113 <filename>meta-intel</filename> contained within the <filename>poky</filename> 144 <filename>meta-intel</filename> contained within the <filename>poky</filename>
114 parent directory. 145 parent directory.
115 The following steps will automatically create the 146 The following steps will automatically create the
116 <filename>meta-intel</filename> directory and the contained meta-crownbay 147 <filename>meta-intel</filename> directory and the contained
117 starting point in both the Git and the tarball cases. 148 <filename>meta-crownbay</filename> starting point in both the Git and the tarball cases.
118 </para> 149 </para>
119 150
120 <para> 151 <para>
@@ -125,12 +156,16 @@
125 $ git clone git://git.yoctoproject.org/meta-intel.git 156 $ git clone git://git.yoctoproject.org/meta-intel.git
126 $ cd meta-intel 157 $ cd meta-intel
127 </literallayout> 158 </literallayout>
128 Alternatively, you can start with the downloaded <filename>meta-intel</filename> 159 Alternatively, you can start with the downloaded Crown Bay tarball.
129 edison tarball. 160 You can download the &DISTRO_NAME; version of the BSP tarball from the
161 <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page of the
162 Yocto Project website.
163 Here is the specific link for the tarball needed for this example:
164 <ulink url='&YOCTO_MACHINES_DL_URL;/crownbay-noemgd/crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2'></ulink>.
130 Again, be sure that you are already in the <filename>poky</filename> directory 165 Again, be sure that you are already in the <filename>poky</filename> directory
131 as described previously: 166 as described previously before installing the tarball:
132 <literallayout class='monospaced'> 167 <literallayout class='monospaced'>
133 $ tar xfj crownbay-noemgd-edison-6.0.1.tar.bz2 168 $ tar xfj crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2
134 $ cd meta-intel 169 $ cd meta-intel
135 </literallayout> 170 </literallayout>
136 </para> 171 </para>
@@ -139,15 +174,16 @@
139 The <filename>meta-intel</filename> directory contains all the metadata 174 The <filename>meta-intel</filename> directory contains all the metadata
140 that supports BSP creation. 175 that supports BSP creation.
141 If you're using the Git method, the following 176 If you're using the Git method, the following
142 step will switch to the edison metadata. 177 step will switch to the &DISTRO_NAME; metadata.
143 If you're using the tarball method, you already have the correct metadata and can 178 If you're using the tarball method, you already have the correct metadata and can
144 skip to the next step. 179 skip to the next step.
145 Because <filename>meta-intel</filename> is its own Git repository, you will want 180 Because <filename>meta-intel</filename> is its own Git repository, you will want
146 to be sure you are in the appropriate branch for your work. 181 to be sure you are in the appropriate branch for your work.
147 For this example we are going to use the <filename>edison</filename> branch. 182 For this example we are going to use the <filename>&DISTRO_NAME;</filename> branch.
148 <literallayout class='monospaced'> 183 <literallayout class='monospaced'>
149 $ git checkout -b edison origin/edison 184 $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
150 Switched to a new branch 'edison' 185 Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
186 Switched to a new branch '&DISTRO_NAME;'
151 </literallayout> 187 </literallayout>
152 </para> 188 </para>
153</section> 189</section>
@@ -234,10 +270,8 @@
234 <filename>meta-mymachine/conf/layer.conf</filename>. 270 <filename>meta-mymachine/conf/layer.conf</filename>.
235 This file identifies build information needed for the new layer. 271 This file identifies build information needed for the new layer.
236 You can see the 272 You can see the
237 "<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in 273 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-layer'>Layer Configuration File</ulink>" section
238 <ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>The Board 274 in The Board Support Packages (BSP) Development Guide for more information on this configuration file.
239 Support Packages (BSP) Development Guide</ulink>
240 for more information on this configuration file.
241 Basically, we are changing the existing statements to work with our BSP. 275 Basically, we are changing the existing statements to work with our BSP.
242 </para> 276 </para>
243 277
@@ -268,7 +302,8 @@
268 Now we will take a look at the recipes in your new layer. 302 Now we will take a look at the recipes in your new layer.
269 The standard BSP structure has areas for BSP, graphics, core, and kernel recipes. 303 The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.
270 When you create a BSP, you use these areas for appropriate recipes and append files. 304 When you create a BSP, you use these areas for appropriate recipes and append files.
271 Recipes take the form of <filename>.bb</filename> files. 305 Recipes take the form of <filename>.bb</filename> files, while append files take
306 the form of <filename>.bbappend</filename> files.
272 If you want to leverage the existing recipes the Yocto Project build system uses 307 If you want to leverage the existing recipes the Yocto Project build system uses
273 but change those recipes, you can use <filename>.bbappend</filename> files. 308 but change those recipes, you can use <filename>.bbappend</filename> files.
274 All new recipes and append files for your layer must go in the layer’s 309 All new recipes and append files for your layer must go in the layer’s
@@ -278,7 +313,7 @@
278 </para> 313 </para>
279 314
280 <section id='changing-recipes-bsp'> 315 <section id='changing-recipes-bsp'>
281 <title>Changing <filename>recipes-bsp</filename></title> 316 <title>Changing&nbsp;&nbsp;<filename>recipes-bsp</filename></title>
282 317
283 <para> 318 <para>
284 First, let's look at <filename>recipes-bsp</filename>. 319 First, let's look at <filename>recipes-bsp</filename>.
@@ -295,7 +330,7 @@
295 </section> 330 </section>
296 331
297 <section id='changing-recipes-graphics'> 332 <section id='changing-recipes-graphics'>
298 <title>Changing <filename>recipes-graphics</filename></title> 333 <title>Changing&nbsp;&nbsp;<filename>recipes-graphics</filename></title>
299 334
300 <para> 335 <para>
301 Now let's look at <filename>recipes-graphics</filename>. 336 Now let's look at <filename>recipes-graphics</filename>.
@@ -316,7 +351,7 @@
316 </section> 351 </section>
317 352
318 <section id='changing-recipes-core'> 353 <section id='changing-recipes-core'>
319 <title>Changing <filename>recipes-core</filename></title> 354 <title>Changing&nbsp;&nbsp;<filename>recipes-core</filename></title>
320 355
321 <para> 356 <para>
322 Now let's look at changes in <filename>recipes-core</filename>. 357 Now let's look at changes in <filename>recipes-core</filename>.
@@ -324,7 +359,7 @@
324 <filename>recipes-core/tasks</filename> appends the similarly named recipe 359 <filename>recipes-core/tasks</filename> appends the similarly named recipe
325 located in the local Yocto Project files at 360 located in the local Yocto Project files at
326 <filename>meta/recipes-core/tasks</filename>. 361 <filename>meta/recipes-core/tasks</filename>.
327 The "append" file in our layer right now is Crown Bay-specific and supports 362 The append file in our layer right now is Crown Bay-specific and supports
328 EMGD and non-EMGD. 363 EMGD and non-EMGD.
329 Here are the contents of the file: 364 Here are the contents of the file:
330 <literallayout class='monospaced'> 365 <literallayout class='monospaced'>
@@ -345,7 +380,7 @@
345 </section> 380 </section>
346 381
347 <section id='changing-recipes-kernel'> 382 <section id='changing-recipes-kernel'>
348 <title>Changing <filename>recipes-kernel</filename></title> 383 <title>Changing&nbsp;&nbsp;<filename>recipes-kernel</filename></title>
349 384
350 <para> 385 <para>
351 Finally, let's look at <filename>recipes-kernel</filename> changes. 386 Finally, let's look at <filename>recipes-kernel</filename> changes.
@@ -368,15 +403,18 @@
368 However, in the <filename>meta-mymachine</filename> layer in 403 However, in the <filename>meta-mymachine</filename> layer in
369 <filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename> 404 <filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
370 file named <filename>linux-yocto_3.0.bbappend</filename> that 405 file named <filename>linux-yocto_3.0.bbappend</filename> that
371 is appended to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>. 406 appends information to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
372 Thus, the <filename>SRCREV</filename> statements in the "append" file override 407 Thus, the <filename>SRCREV</filename> statements in the append file override
373 the more general statements found in <filename>meta</filename>. 408 the more general statements found in <filename>meta</filename>.
374 </para> 409 </para>
375 410
376 <para> 411 <para>
377 The <filename>SRCREV</filename> statements in the "append" file currently identify 412 The <filename>SRCREV</filename> statements in the append file currently identify
378 the kernel that supports the Crown Bay BSP with and without EMGD support. 413 the kernel that supports the Crown Bay BSP with and without EMGD support.
379 Here are the statements: 414 Here are the statements:
415 <note>The commit ID strings used in this manual might not match the actual commit
416 ID strings found in the <filename>linux-yocto_3.0.bbappend</filename> file.
417 For the example, this difference does not matter.</note>
380 <literallayout class='monospaced'> 418 <literallayout class='monospaced'>
381 SRCREV_machine_pn-linux-yocto_crownbay ?= \ 419 SRCREV_machine_pn-linux-yocto_crownbay ?= \
382 "2247da9131ea7e46ed4766a69bb1353dba22f873" 420 "2247da9131ea7e46ed4766a69bb1353dba22f873"
@@ -408,11 +446,11 @@
408 and insert the commit identifiers to identify the kernel in which we 446 and insert the commit identifiers to identify the kernel in which we
409 are interested, which will be based on the <filename>atom-pc-standard</filename> 447 are interested, which will be based on the <filename>atom-pc-standard</filename>
410 kernel. 448 kernel.
411 In this case, because we're working with the edison branch of everything, we 449 In this case, because we're working with the &DISTRO_NAME; branch of everything, we
412 need to use the <filename>SRCREV</filename> values for the atom-pc branch 450 need to use the <filename>SRCREV</filename> values for the atom-pc branch
413 that are associated with the edison release. 451 that are associated with the &DISTRO_NAME; release.
414 To find those values, we need to find the <filename>SRCREV</filename> 452 To find those values, we need to find the <filename>SRCREV</filename>
415 values that edison uses for the atom-pc branch, which we find in the 453 values that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
416 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename> 454 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
417 file. 455 file.
418 </para> 456 </para>
@@ -423,9 +461,7 @@
423 The meta <filename>SRCREV</filename> isn't specified in this file, so it must be 461 The meta <filename>SRCREV</filename> isn't specified in this file, so it must be
424 specified in the base kernel recipe in the 462 specified in the base kernel recipe in the
425 <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename> 463 <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
426 file, in the <filename>SRCREV_meta variable</filename> found there. 464 file, in the <filename>SRCREV_meta</filename> variable found there.
427 It happens to be the same as the value we already inherited from the
428 <filename>meta-crownbay</filename> BSP.
429 Here are the final <filename>SRCREV</filename> statements: 465 Here are the final <filename>SRCREV</filename> statements:
430 <literallayout class='monospaced'> 466 <literallayout class='monospaced'>
431 SRCREV_machine_pn-linux-yocto_mymachine ?= \ 467 SRCREV_machine_pn-linux-yocto_mymachine ?= \
@@ -437,8 +473,8 @@
437 473
438 <para> 474 <para>
439 In this example, we're using the <filename>SRCREV</filename> values we 475 In this example, we're using the <filename>SRCREV</filename> values we
440 found already captured in the edison release because we're creating a BSP based on 476 found already captured in the &DISTRO_NAME; release because we're creating a BSP based on
441 edison. 477 &DISTRO_NAME;.
442 If, instead, we had based our BSP on the master branches, we would want to use 478 If, instead, we had based our BSP on the master branches, we would want to use
443 the most recent <filename>SRCREV</filename> values taken directly from the kernel repo. 479 the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
444 We will not be doing that for this example. 480 We will not be doing that for this example.
@@ -448,7 +484,7 @@
448 the <filename>SRCREV</filename> statements. 484 the <filename>SRCREV</filename> statements.
449 You can find all the <filename>machine</filename> and <filename>meta</filename> 485 You can find all the <filename>machine</filename> and <filename>meta</filename>
450 branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at 486 branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
451 <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>. 487 <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.
452 </para> 488 </para>
453 489
454 <para> 490 <para>
@@ -477,12 +513,12 @@
477 Because we are not interested in supporting EMGD those three can be deleted. 513 Because we are not interested in supporting EMGD those three can be deleted.
478 The remaining three must be changed so that <filename>mymachine</filename> replaces 514 The remaining three must be changed so that <filename>mymachine</filename> replaces
479 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>. 515 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
480 Because we are using the atom-pc branch for this new BSP, we can also find 516 Because we are using the <filename>atom-pc</filename> branch for this new BSP, we can also find
481 the exact branch we need for the KMACHINE variable in our new BSP from the value 517 the exact branch we need for the <filename>KMACHINE</filename> variable in our new BSP from the value
482 we find in the 518 we find in the
483 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename> 519 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
484 file we looked at in a previous step. 520 file we looked at in a previous step.
485 In this case, the value we want is in the KMACHINE_atom-pc variable in that file. 521 In this case, the value we want is in the <filename>KMACHINE_atom-pc</filename> variable in that file.
486 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 522 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all
487 the edits: 523 the edits:
488 <literallayout class='monospaced'> 524 <literallayout class='monospaced'>
@@ -509,7 +545,7 @@
509 statements that do not support your targeted hardware in addition to the inclusion 545 statements that do not support your targeted hardware in addition to the inclusion
510 of any new recipes you might need. 546 of any new recipes you might need.
511 In this example, it was simply a matter of ridding the new layer 547 In this example, it was simply a matter of ridding the new layer
512 <filename>meta-machine</filename> of any code that supported the EMGD features 548 <filename>meta-mymachine</filename> of any code that supported the EMGD features
513 and making sure we were identifying the kernel that supports our example, which 549 and making sure we were identifying the kernel that supports our example, which
514 is the <filename>atom-pc-standard</filename> kernel. 550 is the <filename>atom-pc-standard</filename> kernel.
515 We did not introduce any new recipes to the layer. 551 We did not introduce any new recipes to the layer.
@@ -544,7 +580,7 @@
544 Thus, entering the previous command created the <filename>yocto-build</filename> directory. 580 Thus, entering the previous command created the <filename>yocto-build</filename> directory.
545 If you do not provide a name for the build directory it defaults to 581 If you do not provide a name for the build directory it defaults to
546 <filename>build</filename>. 582 <filename>build</filename>.
547 The <filename>yocot-build</filename> directory contains a 583 The <filename>yocto-build</filename> directory contains a
548 <filename>conf</filename> directory that has 584 <filename>conf</filename> directory that has
549 two configuration files you will need to check: <filename>bblayers.conf</filename> 585 two configuration files you will need to check: <filename>bblayers.conf</filename>
550 and <filename>local.conf</filename>.</para></listitem> 586 and <filename>local.conf</filename>.</para></listitem>
@@ -558,15 +594,17 @@
558 You should also be sure any other variables in which you are interested are set. 594 You should also be sure any other variables in which you are interested are set.
559 Some variables to consider are <filename>BB_NUMBER_THREADS</filename> 595 Some variables to consider are <filename>BB_NUMBER_THREADS</filename>
560 and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time 596 and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time
561 if you are using a multi-threaded development system (e.g. values of 597 if your development system supports multiple cores.
562 <filename>8</filename> and <filename>j 6</filename>, respectively are optimal 598 For development systems that support multiple cores, a good rule of thumb is to set
563 for a development machine that has four available cores).</para></listitem> 599 both the <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
600 variables to twice the number of cores your system supports.</para></listitem>
564 <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes 601 <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes
565 the path to your new BSP layer. 602 both the path to your new BSP layer and the path to the
566 In this example you need to include the pathname to <filename>meta-mymachine</filename>. 603 <filename>meta-intel</filename> layer.
567 For this example the 604 In this example, you need to include both these paths as part of the
568 <filename>BBLAYERS</filename> variable in the file would need to include the following path: 605 <filename>BBLAYERS</filename> variable:
569 <literallayout class='monospaced'> 606 <literallayout class='monospaced'>
607 $HOME/poky/meta-intel
570 $HOME/poky/meta-intel/meta-mymachine 608 $HOME/poky/meta-intel/meta-mymachine
571 </literallayout></para></listitem> 609 </literallayout></para></listitem>
572 </orderedlist> 610 </orderedlist>
@@ -574,7 +612,7 @@
574 612
575 <para> 613 <para>
576 The appendix 614 The appendix
577 <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'> 615 <ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glos'>
578 Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information 616 Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information
579 on configuration variables. 617 on configuration variables.
580 </para> 618 </para>
@@ -607,7 +645,7 @@
607 Finally, once you have an image, you can try booting it from a device 645 Finally, once you have an image, you can try booting it from a device
608 (e.g. a USB device). 646 (e.g. a USB device).
609 To prepare a bootable USB device, insert a USB flash drive into your build system and 647 To prepare a bootable USB device, insert a USB flash drive into your build system and
610 copy the <filename>.hddimage</filename>, located in the 648 copy the <filename>.hddimg</filename> file, located in the
611 <filename>poky/build/tmp/deploy/images</filename> 649 <filename>poky/build/tmp/deploy/images</filename>
612 directory after a successful build to the flash drive. 650 directory after a successful build to the flash drive.
613 Assuming the USB flash drive takes device <filename>/dev/sdc</filename>, 651 Assuming the USB flash drive takes device <filename>/dev/sdc</filename>,
@@ -625,10 +663,26 @@
625 Insert the device 663 Insert the device
626 into a bootable USB socket on the target, and power it on. 664 into a bootable USB socket on the target, and power it on.
627 The system should boot to the Sato graphical desktop. 665 The system should boot to the Sato graphical desktop.
666 <footnote><para>Because
667 this new image is not in any way tailored to the system you're
668 booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
669 example, it might not be completely functional though it should at least boot to a text
670 prompt.
671 Specifically, it might fail to boot into graphics without some tweaking.
672 If this ends up being the case, a possible next step would be to replace the
673 <filename>mymachine.conf</filename>
674 contents with the contents of <filename>atom-pc.conf</filename> and replace
675 <filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
676 in <filename>meta-yocto</filename> and see if it fares any better.
677 In any case, following the previous steps will give you a buildable image that
678 will probably boot on most systems.
679 Getting things working like you want
680 them to for your hardware will normally require some amount of experimentation with
681 configuration settings.</para></footnote>
628 </para> 682 </para>
629 683
630 <para> 684 <para>
631 For reference, the sato image produced by the previous steps for edison 685 For reference, the sato image produced by the previous steps for &DISTRO_NAME;
632 should look like the following in terms of size. 686 should look like the following in terms of size.
633 If your sato image is much different from this, 687 If your sato image is much different from this,
634 you probably made a mistake in one of the above steps: 688 you probably made a mistake in one of the above steps:
@@ -643,24 +697,6 @@
643 also provides some suggestions for things to try if booting fails and produces 697 also provides some suggestions for things to try if booting fails and produces
644 strange error messages.</note> 698 strange error messages.</note>
645 </para> 699 </para>
646
647 <para>
648 Because this new image is not in any way tailored to the system you're
649 booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
650 example, it might not be completely functional though it should at least boot to a text
651 prompt.
652 Specifically, it might fail to boot into graphics without some tweaking.
653 If this ends up being the case, a possible next step would be to replace the
654 <filename>mymachine.conf</filename>
655 contents with the contents of <filename>atom-pc.conf</filename> and replace
656 <filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
657 in <filename>meta-yocto</filename> and see if it fares any better.
658 In any case, following the previous steps should
659 probably give you a buildable and bootable image.
660 Getting things working like you want
661 them to for your hardware will normally require some amount of experimentation with
662 configuration settings.
663 </para>
664</section> 700</section>
665</appendix> 701</appendix>
666 702