summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual
diff options
context:
space:
mode:
authorTom Zanussi <tom.zanussi@intel.com>2011-11-03 10:58:14 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-11-08 16:26:31 +0000
commit6ff754f4794cea5e22fefe69e99bc0f6aadb0e52 (patch)
treebb4b01c7f826ae400c31f1fef1122f63fc1b5944 /documentation/dev-manual
parente64946e8c76ebe14d9b20c9a4a701c25bcdcf49e (diff)
downloadpoky-6ff754f4794cea5e22fefe69e99bc0f6aadb0e52.tar.gz
documentation/dev-manual/dev-manual-bsp-appendix.xml: BSP example scrub
As Reported by Robert P. J. Day. Robert was working through this BSP example in the development manual and ran into some problems and some confusion in areas. This launched a long "help-desk" session with Tom Zanussi. In addressing Robert's issues, Tom decided to make a run through of the example as it was written. For the most part the example was sound but needed some technical tweaks as well as some expansion of the text to make things clearer. Tom submitted the patch that addressed these concerns. Scott Rifenbark reviewed the patch and further modified some of the writing to make it consistent with the existing writing in the manual. (From yocto-docs rev: deda08b372c02889398d24ae7159f8b2fbe3c8cf) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual')
-rw-r--r--documentation/dev-manual/dev-manual-bsp-appendix.xml224
1 files changed, 186 insertions, 38 deletions
diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml
index aaf0fbda95..f243bb8091 100644
--- a/documentation/dev-manual/dev-manual-bsp-appendix.xml
+++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml
@@ -10,8 +10,11 @@
10 The example assumes the following: 10 The example assumes the following:
11 <itemizedlist> 11 <itemizedlist>
12 <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem> 12 <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
13 <listitem><para>Use of the Crown Bay Board Support Package (BSP) as a base BSP from 13 <listitem><para>Use of the Crown Bay Board Support Package (BSP) as a "base" BSP from
14 which to work from.</para></listitem> 14 which to work.
15 The example begins with the Crown Bay BSP as the starting point
16 but ends by building a new 'atom-pc' BSP, which was based on the Crown Bay BSP.
17 </para></listitem>
15 <listitem><para>Shell commands assume <filename>bash</filename></para></listitem> 18 <listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
16 <listitem><para>Example was developed on an Intel-based Core i7 platform running 19 <listitem><para>Example was developed on an Intel-based Core i7 platform running
17 Ubuntu 10.04 LTS released in April of 2010.</para></listitem> 20 Ubuntu 10.04 LTS released in April of 2010.</para></listitem>
@@ -24,10 +27,30 @@
24 <para> 27 <para>
25 You need to have the Yocto Project files available on your host system. 28 You need to have the Yocto Project files available on your host system.
26 You can get files through tarball extraction or by cloning the <filename>poky</filename> 29 You can get files through tarball extraction or by cloning the <filename>poky</filename>
27 Git repository. 30 Git repository.
28 See the bulleted item 31 The following paragraphs describe both methods.
29 "<link linkend='local-yp-release'>Yocto Project Release</link>" 32 For additional information, see the bulleted item
30 for information on how to get these files. 33 "<link linkend='local-yp-release'>Yocto Project Release</link>".
34 </para>
35
36 <para>
37 As mentioned, one way to get the Yocto Project files is to use Git to clone the
38 <filename>poky</filename> repository:
39 <literallayout class='monospaced'>
40 $ git clone git://git.yoctoproject.org/poky
41 $ cd poky
42 </literallayout>
43 Alternatively, you can start with the downloaded Poky "edison" tarball:
44 <literallayout class='monospaced'>
45 $ tar xfj poky-edison-6.0.tar.bz2
46 $ cd poky
47 </literallayout>
48 <note>If you're using the tarball method, you can ignore all the following steps that
49 ask you to carry out Git operations.
50 You already have the results of those operations
51 in the form of the edison release tarballs.
52 Consequently, there is nothing left to do other than extract those tarballs into the
53 proper locations.</note>
31 </para> 54 </para>
32 55
33 <para> 56 <para>
@@ -44,7 +67,6 @@
44 These commands create a local branch named <filename>edison</filename> 67 These commands create a local branch named <filename>edison</filename>
45 that tracks the remote branch of the same name. 68 that tracks the remote branch of the same name.
46 <literallayout class='monospaced'> 69 <literallayout class='monospaced'>
47 $ cd poky
48 $ git checkout -b edison origin/edison 70 $ git checkout -b edison origin/edison
49 Switched to a new branch 'edison' 71 Switched to a new branch 'edison'
50 </literallayout> 72 </literallayout>
@@ -58,7 +80,12 @@
58 For this example, the base BSP is the <trademark class='registered'>Intel</trademark> 80 For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
59 <trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform 81 <trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform
60 Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay." 82 Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
61 The BSP layer is <filename>meta-crownbay</filename>. 83 The BSP layer is <filename>meta-crownbay</filename>.
84 The base BSP is simply the BSP
85 we will be using as a starting point, so don't worry if you don't actually have Crown Bay
86 hardware.
87 The remainder of the example transforms the base BSP into a BSP that should be
88 able to boot on generic atom-pc (netbook) hardware.
62 </para> 89 </para>
63 90
64 <para> 91 <para>
@@ -73,27 +100,52 @@
73 <para> 100 <para>
74 You need to have the base BSP layer on your development system. 101 You need to have the base BSP layer on your development system.
75 Similar to the local Yocto Project files, you can get the BSP 102 Similar to the local Yocto Project files, you can get the BSP
76 layer one of two ways: 103 layer a couple of different ways:
77 download the BSP tarball and extract it, or set up a local Git repository that 104 download the BSP tarball and extract it, or set up a local Git repository that
78 has the Yocto Project BSP layers. 105 has the Yocto Project BSP layers.
79 You should use the same method that you used to get the local Yocto Project files earlier. 106 You should use the same method that you used to get the local Yocto Project files earlier.
80 See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get 107 See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get
81 the BSP files. 108 the BSP files.
82 </para> 109 </para>
83 110
84 <para> 111 <para>
85 This example assumes the local <filename>meta-intel</filename> Git repository is 112 This example assumes the BSP layer will be located within a directory named
86 inside the local <filename>poky</filename> Git repository. 113 <filename>meta-intel</filename> contained within the <filename>poky</filename>
87 The <filename>meta-intel</filename> Git repository contains all the metadata 114 parent directory.
88 that supports BSP creation. 115 The following steps will automatically create the
116 <filename>meta-intel</filename> directory and the contained meta-crownbay
117 starting point in both the Git and the tarball cases.
89 </para> 118 </para>
90 119
91 <para> 120 <para>
121 If you're using the Git method, you could do the following to create
122 the starting layout after you have made sure you are in the <filename>poky</filename>
123 directory created in the previous steps:
124 <literallayout class='monospaced'>
125 $ git clone git://git.yoctoproject.org/meta-intel.git
126 $ cd meta-intel
127 </literallayout>
128 Alternatively, you can start with the downloaded <filename>meta-intel</filename>
129 edison tarball.
130 Again, be sure that you are already in the <filename>poky</filename> directory
131 as described previously:
132 <literallayout class='monospaced'>
133 $ tar xfj crownbay-noemgd-edison-6.0.0.tar.bz2
134 $ cd meta-intel
135 </literallayout>
136 </para>
137
138 <para>
139 The <filename>meta-intel</filename> directory contains all the metadata
140 that supports BSP creation.
141 If you're using the Git method, the following
142 step will switch to the edison metadata.
143 If you're using the tarball method, you already have the correct metadata and can
144 skip to the next step.
92 Because <filename>meta-intel</filename> is its own Git repository, you will want 145 Because <filename>meta-intel</filename> is its own Git repository, you will want
93 to be sure you are in the appropriate branch for your work. 146 to be sure you are in the appropriate branch for your work.
94 For this example we are going to use the <filename>edison</filename> branch. 147 For this example we are going to use the <filename>edison</filename> branch.
95 <literallayout class='monospaced'> 148 <literallayout class='monospaced'>
96 $ cd meta-intel
97 $ git checkout -b edison origin/edison 149 $ git checkout -b edison origin/edison
98 Switched to a new branch 'edison' 150 Switched to a new branch 'edison'
99 </literallayout> 151 </literallayout>
@@ -112,15 +164,12 @@
112 164
113 <para> 165 <para>
114 For this example, the new layer will be named <filename>meta-mymachine</filename>. 166 For this example, the new layer will be named <filename>meta-mymachine</filename>.
115 The name must follow the BSP layer naming convention, which is 167 The name should follow the BSP layer naming convention, which is
116 <filename>meta-&lt;name&gt;</filename>. 168 <filename>meta-&lt;name&gt;</filename>.
117 The following example assumes your working directory is <filename>meta-intel</filename> 169 The following assumes your working directory is <filename>meta-intel</filename>
118 inside the local Yocto Project files. 170 inside the local Yocto Project files.
119 If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting 171 To start your new layer, just copy the new layer alongside the existing
120 <filename>meta-crownbay</filename> directory structure to a location of your choice. 172 BSP layers in the <filename>meta-intel</filename> directory:
121 Good practice for a Git repository, however, is to just copy the new layer alongside
122 the existing
123 BSP layers in the <filename>meta-intel</filename> Git repository:
124 <literallayout class='monospaced'> 173 <literallayout class='monospaced'>
125 $ cp -a meta-crownbay/ meta-mymachine 174 $ cp -a meta-crownbay/ meta-mymachine
126 </literallayout> 175 </literallayout>
@@ -162,9 +211,14 @@
162 </para> 211 </para>
163 212
164 <para> 213 <para>
165 The next step makes changes to <filename>mymachine.conf</filename> itself. 214 Next, we need to make changes to the <filename>mymachine.conf</filename> itself.
166 The only changes needed for this example are changes to the comment lines. 215 The only changes we want to make for this example are to the comment lines.
167 Here we simply substitute the Crown Bay name with an appropriate name. 216 Changing comments, of course, is never strictly necessary, but it's alway good form to make
217 them reflect reality as much as possible.
218
219 Here, simply substitute the Crown Bay name with an appropriate name for the BSP
220 (<filename>mymachine</filename> in this case) and change the description to
221 something that describes your hardware.
168 </para> 222 </para>
169 223
170 <para> 224 <para>
@@ -176,7 +230,8 @@
176 </para> 230 </para>
177 231
178 <para> 232 <para>
179 The next configuration file in the new BSP layer we need to edit is <filename>layer.conf</filename>. 233 The next configuration file in the new BSP layer we need to edit is
234 <filename>meta-mymachine/conf/layer.conf</filename>.
180 This file identifies build information needed for the new layer. 235 This file identifies build information needed for the new layer.
181 You can see the 236 You can see the
182 "<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in 237 "<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in
@@ -232,7 +287,7 @@
232 the remaining one that doesn't support EMGD. 287 the remaining one that doesn't support EMGD.
233 These commands take care of the <filename>recipes-bsp</filename> recipes: 288 These commands take care of the <filename>recipes-bsp</filename> recipes:
234 <literallayout class='monospaced'> 289 <literallayout class='monospaced'>
235 $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/*emgd* 290 $ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
236 $ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \ 291 $ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \
237 meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine 292 meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
238 </literallayout> 293 </literallayout>
@@ -248,7 +303,6 @@
248 be sure to rename remaining directories appropriately. 303 be sure to rename remaining directories appropriately.
249 The following commands clean up the <filename>recipes-graphics</filename> directory: 304 The following commands clean up the <filename>recipes-graphics</filename> directory:
250 <literallayout class='monospaced'> 305 <literallayout class='monospaced'>
251 $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*
252 $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay 306 $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
253 $ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \ 307 $ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
254 meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine 308 meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine
@@ -304,6 +358,10 @@
304 The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename> 358 The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
305 statements point to the exact commits used by the Yocto Project development team 359 statements point to the exact commits used by the Yocto Project development team
306 in their source repositories that identify the right kernel for our hardware. 360 in their source repositories that identify the right kernel for our hardware.
361 In other words, the <filename>SRCREV</filename> values are simply Git commit
362 IDs that identify which commit on each
363 of the kernel branches (machine and meta) will be checked out and used to build
364 the kernel.
307 </para> 365 </para>
308 366
309 <para> 367 <para>
@@ -323,12 +381,12 @@
323 SRCREV_machine_pn-linux-yocto_crownbay ?= \ 381 SRCREV_machine_pn-linux-yocto_crownbay ?= \
324 "2247da9131ea7e46ed4766a69bb1353dba22f873" 382 "2247da9131ea7e46ed4766a69bb1353dba22f873"
325 SRCREV_meta_pn-linux-yocto_crownbay ?= \ 383 SRCREV_meta_pn-linux-yocto_crownbay ?= \
326 "67a46a608f47c19f16995be7de7b272025864b1b" 384 "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
327 385
328 SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \ 386 SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
329 "2247da9131ea7e46ed4766a69bb1353dba22f873" 387 "2247da9131ea7e46ed4766a69bb1353dba22f873"
330 SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \ 388 SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
331 "67a46a608f47c19f16995be7de7b272025864b1b" 389 "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
332 </literallayout> 390 </literallayout>
333 </para> 391 </para>
334 392
@@ -343,24 +401,49 @@
343 </para> 401 </para>
344 402
345 <para> 403 <para>
346 To fix this situation in <filename>linux-yocto_3.0.bbappend</filename> 404 To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>,
347 we delete the two <filename>SRCREV</filename> statements that support 405 we delete the two <filename>SRCREV</filename> statements that support
348 EMGD (the top pair). 406 EMGD (the top pair).
349 We also change the remaining pair to specify <filename>mymachine</filename> 407 We also change the remaining pair to specify <filename>mymachine</filename>
350 and insert the commit identifiers to identify the kernel in which we 408 and insert the commit identifiers to identify the kernel in which we
351 are interested, which will be based on the <filename>atom-pc-standard</filename> 409 are interested, which will be based on the <filename>atom-pc-standard</filename>
352 kernel. 410 kernel.
411 In this case, because we're working with the edison branch of everything, we
412 need to use the <filename>SRCREV</filename> values for the atom-pc branch
413 that are associated with the edison release.
414 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
416 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
417 file.
418 </para>
419
420 <para>
421 The machine <filename>SRCREV</filename> we want is in the
422 <filename>SRCREV_machine_atom-pc</filename> variable.
423 The meta <filename>SRCREV</filename> isn't specified in this file, so it must be
424 specified in the base kernel recipe in the
425 <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
426 file, in the <filename>SRCREV_meta variable</filename> found there.
427 It happens to be the same as the value we already inherited from the
428 <filename>meta-crownbay</filename> BSP.
353 Here are the final <filename>SRCREV</filename> statements: 429 Here are the final <filename>SRCREV</filename> statements:
354 <literallayout class='monospaced'> 430 <literallayout class='monospaced'>
355 SRCREV_machine_pn-linux-yocto_mymachine ?= \ 431 SRCREV_machine_pn-linux-yocto_mymachine ?= \
356 "06c798f25a19281d7fa944b14366dd75820ba009" 432 "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
357 SRCREV_meta_pn-linux-yocto_mymachine ?= \ 433 SRCREV_meta_pn-linux-yocto_mymachine ?= \
358 "67a46a608f47c19f16995be7de7b272025864b1b" 434 "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
359 </literallayout> 435 </literallayout>
360 </para> 436 </para>
361 437
362 <para> 438 <para>
363 If you are familiar with Git repositories you probably won’t have trouble locating the 439 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
441 edison.
442 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.
444 We will not be doing that for this example.
445 However, if you do base a future BSP on master and
446 if you are familiar with Git repositories, you probably won’t have trouble locating the
364 exact commit strings in the Yocto Project source repositories you need to change 447 exact commit strings in the Yocto Project source repositories you need to change
365 the <filename>SRCREV</filename> statements. 448 the <filename>SRCREV</filename> statements.
366 You can find all the <filename>machine</filename> and <filename>meta</filename> 449 You can find all the <filename>machine</filename> and <filename>meta</filename>
@@ -394,19 +477,25 @@
394 Because we are not interested in supporting EMGD those three can be deleted. 477 Because we are not interested in supporting EMGD those three can be deleted.
395 The remaining three must be changed so that <filename>mymachine</filename> replaces 478 The remaining three must be changed so that <filename>mymachine</filename> replaces
396 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>. 479 <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
481 the exact branch we need for the KMACHINE variable in our new BSP from the value
482 we find in the
483 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
484 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.
397 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 486 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all
398 the edits: 487 the edits:
399 <literallayout class='monospaced'> 488 <literallayout class='monospaced'>
400 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 489 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
401 490
402 COMPATIBLE_MACHINE_mymachine = "mymachine" 491 COMPATIBLE_MACHINE_mymachine = "mymachine"
403 KMACHINE_mymachine = "yocto/standard/mymachine" 492 KMACHINE_mymachine = "yocto/standard/common-pc/atom-pc"
404 KERNEL_FEATURES_append_mymachine += " cfg/smp.scc" 493 KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
405 494
406 SRCREV_machine_pn-linux-yocto_mymachine ?= \ 495 SRCREV_machine_pn-linux-yocto_mymachine ?= \
407 "06c798f25a19281d7fa944b14366dd75820ba009" 496 "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
408 SRCREV_meta_pn-linux-yocto_mymachine ?= \ 497 SRCREV_meta_pn-linux-yocto_mymachine ?= \
409 "67a46a608f47c19f16995be7de7b272025864b1b" 498 "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
410 </literallayout> 499 </literallayout>
411 </para> 500 </para>
412 </section> 501 </section>
@@ -492,7 +581,7 @@
492</section> 581</section>
493 582
494<section id='building-the-image-app'> 583<section id='building-the-image-app'>
495 <title>Building the Image</title> 584 <title>Building and Booting the Image</title>
496 585
497 <para> 586 <para>
498 To build the image for our <filename>meta-mymachine</filename> BSP enter the following command 587 To build the image for our <filename>meta-mymachine</filename> BSP enter the following command
@@ -513,6 +602,65 @@
513 If the build results in any type of error you should check for misspellings in the 602 If the build results in any type of error you should check for misspellings in the
514 files you changed or problems with your host development environment such as missing packages. 603 files you changed or problems with your host development environment such as missing packages.
515 </para> 604 </para>
605
606 <para>
607 Finally, once you have an image, you can try booting it from a device
608 (e.g. a USB device).
609 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
611 <filename>poky/build/tmp/deploy/images</filename>
612 directory after a successful build to the flash drive.
613 Assuming the USB flash drive takes device <filename>/dev/sdf</filename>,
614 use <filename>dd</filename> to copy the live image to it.
615 For example:
616 <literallayout class='monospaced'>
617 # dd if=core-image-sato-mymachine-20111101223904.hddimg of=/dev/sdf
618 # sync
619 # eject /dev/sdf
620 </literallayout>
621 You should now have a bootable USB flash device.
622 </para>
623
624 <para>
625 Insert the device
626 into a bootable USB socket on the target, and power it on.
627 The system should boot to the Sato graphical desktop.
628 </para>
629
630 <para>
631 For reference, the sato image produced by the previous steps for edison
632 should look like the following in terms of size.
633 If your sato image is much different from this,
634 you probably made a mistake in one of the above steps:
635 <literallayout class='monospaced'>
636 358715392 2011-11-01 19:11 core-image-sato-mymachine-20111101223904.hddimg
637 </literallayout>
638 <note>The previous instructions are also present in the README that was copied
639 from meta-crownbay, which should also be updated to reflect the specifics of your
640 new BSP.
641 That file and the <filename>README.hardware</filename> file in the top-level
642 <filename>poky</filename> directory
643 also provides some suggestions for things to try if booting fails and produces
644 strange error messages.</note>
645 </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>
516</section> 664</section>
517</appendix> 665</appendix>
518 666