diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2011-07-22 14:05:31 -0700 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-08-04 15:06:43 +0100 |
commit | e77f5649e08f96d2480567a515fd73d3f21cccd3 (patch) | |
tree | 290d8d4ba143556f6abec619c0a4963e0e99f4c9 /documentation | |
parent | fbe93b6a541a61b65e00c806c20e09005ec9b389 (diff) | |
download | poky-e77f5649e08f96d2480567a515fd73d3f21cccd3.tar.gz |
documentation/dev-manual/dev-manual-cases.xml: partial - edits to clean terms up.
I made a pass through the chapter to try and lessen the confusion over
yp files in a git repo verses those unpacked from a tarball. Also
tried to write the example for the 1.1 release but I don't have the
real software yet and can't supply actual names of files.
(From yocto-docs rev: 2ad973bd1f17005a3922651060d025795634d222)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/dev-manual/dev-manual-cases.xml | 171 |
1 files changed, 89 insertions, 82 deletions
diff --git a/documentation/dev-manual/dev-manual-cases.xml b/documentation/dev-manual/dev-manual-cases.xml index 727995800d..bb8389bc10 100644 --- a/documentation/dev-manual/dev-manual-cases.xml +++ b/documentation/dev-manual/dev-manual-cases.xml | |||
@@ -6,9 +6,10 @@ | |||
6 | <title>Development Cases</title> | 6 | <title>Development Cases</title> |
7 | 7 | ||
8 | <para> | 8 | <para> |
9 | For the purposes of this manual we are going to focus on two common development cases or groupings: | 9 | Many development cases exist for which you can use the Yocto Project. |
10 | However, for the purposes of this manual we are going to focus on two common development cases or groupings: | ||
10 | System Development and User Application Development. | 11 | System Development and User Application Development. |
11 | System Development covers Board Support Package (BSP) development and kernel image modification. | 12 | System Development covers Board Support Package (BSP) development and kernel modification. |
12 | User Application Development covers development of applications that you intend to run on some | 13 | User Application Development covers development of applications that you intend to run on some |
13 | target hardware. | 14 | target hardware. |
14 | </para> | 15 | </para> |
@@ -46,14 +47,10 @@ | |||
46 | Thus, the package, when compiled into the new image, supports the operation of the board. | 47 | Thus, the package, when compiled into the new image, supports the operation of the board. |
47 | </para> | 48 | </para> |
48 | 49 | ||
49 | <para> | 50 | <note> |
50 | Packages consist of recipes. | 51 | For a brief list of terms used when describing the development process in the Yocto Project, |
51 | Recipes are sets of instructions for building a package. | 52 | see <xref linkend='yocto-project-terms'>Yocto Project Terms</xref> in this manual. |
52 | The recipes describe where to get source code and what patches to apply. | 53 | </note> |
53 | Recipes also describe dependencies for libraries or for other recipes. | ||
54 | They also contain configuration and compilation options. | ||
55 | Recipes are logical units of execution. | ||
56 | </para> | ||
57 | 54 | ||
58 | <para> | 55 | <para> |
59 | Here are the basic steps involved in creating a BSP: | 56 | Here are the basic steps involved in creating a BSP: |
@@ -74,8 +71,8 @@ | |||
74 | for your recipes.</para></listitem> | 71 | for your recipes.</para></listitem> |
75 | <listitem><para>Make configuration and recipe changes to your new BSP layer.</para></listitem> | 72 | <listitem><para>Make configuration and recipe changes to your new BSP layer.</para></listitem> |
76 | <listitem><para>Prepare for the build.</para></listitem> | 73 | <listitem><para>Prepare for the build.</para></listitem> |
77 | <listitem><para>Select and configure the kernel. (WRITER'S NOTE: Not sure on this step).</para></listitem> | 74 | <listitem><para>Select and configure the kernel.</para></listitem> |
78 | <listitem><para>Identify the machine branch in the Git repository.</para></listitem> | 75 | <listitem><para>Identify the machine branch.</para></listitem> |
79 | <listitem><para>Build the image.</para></listitem> | 76 | <listitem><para>Build the image.</para></listitem> |
80 | </orderedlist> | 77 | </orderedlist> |
81 | You can view a video presentation of the BSP creation process | 78 | You can view a video presentation of the BSP creation process |
@@ -92,30 +89,29 @@ | |||
92 | <title>Setting Up Yocto Project</title> | 89 | <title>Setting Up Yocto Project</title> |
93 | 90 | ||
94 | <para> | 91 | <para> |
95 | You need to have the Yocto Project source tree available on your host system. | 92 | You need to have the Yocto Project files available on your host system. |
96 | You can get that through tarball extraction or by cloning the <filename>poky</filename> | 93 | You can get files through tarball extraction or by cloning the <filename>poky</filename> |
97 | Git repository. | 94 | Git repository. |
98 | Typically, cloning the Git repository is the method to use. | 95 | Typically, cloning the Git repository is the method to use. |
99 | This allows you to maintain a complete history of changes and facilitates you | 96 | This allows you to maintain a complete history of changes and facilitates you |
100 | contributing back to the Yocto Project. | 97 | contributing back to the Yocto Project. |
101 | However, if you just want the source you can download the Yocto Project Release | 98 | However, if you just want a hierarchical file structure that contains the recipes |
102 | tarball from the | 99 | and metadata that let you develop you can download tarballs from the |
103 | <ulink url='http://yoctoproject.org/download'>download page</ulink>. | 100 | <ulink url='http://yoctoproject.org/download'>download page</ulink>. |
104 | If you download the tarball you can extract it into any directory you want using the | 101 | If you download a tarball you can extract it into any directory you want using the |
105 | tar command. | 102 | tar command. |
106 | For example, the following command extracts the Yocto Project 1.0.1 release tarball | 103 | For example, the following command extracts the Yocto Project 1.1_M2 release tarball |
107 | (bernard 5.0.1) into | 104 | into the current working directory and sets up a file structure whose top-level |
108 | the current working directory and sets up a Yocto Project source directory named | 105 | directory is named <filename>poky-1.1</filename>: |
109 | <filename>bernard.5.0.1</filename>: | ||
110 | <literallayout class='monospaced'> | 106 | <literallayout class='monospaced'> |
111 | $ tar xfj poky.bernard.5.0.1.tar.bz2 | 107 | $ tar xfj poky-1.1.tar.bz2 |
112 | </literallayout> | 108 | </literallayout> |
113 | </para> | 109 | </para> |
114 | 110 | ||
115 | <para> | 111 | <para> |
116 | The following transcript shows how to clone the <filename>poky</filename> Git repository | 112 | The following transcript shows how to clone the <filename>poky</filename> Git repository |
117 | into the current working directory. | 113 | into the current working directory. |
118 | The command creates the Git repository in a directory named <filename>poky</filename>: | 114 | The command creates the repository in a directory named <filename>poky</filename>: |
119 | <literallayout class='monospaced'> | 115 | <literallayout class='monospaced'> |
120 | $ git clone git://git.yoctoproject.org/poky | 116 | $ git clone git://git.yoctoproject.org/poky |
121 | Initialized empty Git repository in /home/scottrif/poky/.git/ | 117 | Initialized empty Git repository in /home/scottrif/poky/.git/ |
@@ -143,8 +139,8 @@ | |||
143 | <literallayout class='monospaced'> | 139 | <literallayout class='monospaced'> |
144 | 140 | ||
145 | $ cd poky | 141 | $ cd poky |
146 | $ git checkout -b bernard origin/bernard | 142 | $ git checkout -b 1.1 origin/1.1 |
147 | Switched to a new branch 'bernard' | 143 | Switched to a new branch '1.1' |
148 | </literallayout> | 144 | </literallayout> |
149 | [WRITER'S NOTE: I NEED THE REAL BRANCH NAMES IN THE EXAMPLE.] | 145 | [WRITER'S NOTE: I NEED THE REAL BRANCH NAMES IN THE EXAMPLE.] |
150 | </para> | 146 | </para> |
@@ -164,18 +160,19 @@ | |||
164 | 160 | ||
165 | <para> | 161 | <para> |
166 | At this point you need to understand your target hardware well enough to determine which | 162 | At this point you need to understand your target hardware well enough to determine which |
167 | existing BSP most closely matches it. | 163 | existing BSP it most closely matches. |
168 | Things to consider are your hardware’s on-board features such as CPU type and graphics support. | 164 | Things to consider are your hardware’s on-board features such as CPU type and graphics support. |
169 | You should look at the README files for supported BSPs to get an idea of which one | 165 | You should look at the README files for supported BSPs to get an idea of which one |
170 | you could use. | 166 | you could use. |
171 | A generic Atom-based BSP to consider is the Crown Bay with no Intel® Embedded Media | 167 | A generic Atom-based BSP to consider is the Crown Bay that does not support |
172 | Graphics Driver (EMGD) support. | 168 | the Intel® Embedded Media Graphics Driver (EMGD). |
173 | That is the BSP that this example is going to use. | 169 | The remainder of this example uses that base BSP. |
174 | </para> | 170 | </para> |
175 | 171 | ||
176 | <para> | 172 | <para> |
177 | To see the supported BSPs, go to the Yocto Project | 173 | To see the supported BSPs, go to the Yocto Project |
178 | <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click on “BSP Downloads.” | 174 | <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click |
175 | on “BSP Downloads.” | ||
179 | </para> | 176 | </para> |
180 | </section> | 177 | </section> |
181 | 178 | ||
@@ -184,13 +181,15 @@ | |||
184 | 181 | ||
185 | <para> | 182 | <para> |
186 | You need to have the base BSP layer on your development system. | 183 | You need to have the base BSP layer on your development system. |
187 | Like the Yocto Project source tree you can get the BSP layer one of two ways: | 184 | Like the Yocto Project's <filename>poky</filename> Git repository you can get the BSP |
188 | download the tarball and extract it, or initialize a Git repository and check out the BSP. | 185 | layer one of two ways: |
189 | You should use the same method that you used for the Yocto Project source tree. | 186 | download the BSP tarball and extract it, or set up a local Git repository that |
187 | has the Yocto Project BSP layers. | ||
188 | You should use the same method that you used to get the Yocto Project files earlier. | ||
190 | </para> | 189 | </para> |
191 | 190 | ||
192 | <para> | 191 | <para> |
193 | If you are using tarball extraction then simply download the tarball for the base | 192 | If you are using tarball extraction, simply download the tarball for the base |
194 | BSP you chose in the previous step and then extract it into any directory | 193 | BSP you chose in the previous step and then extract it into any directory |
195 | you choose using the tar command. | 194 | you choose using the tar command. |
196 | Upon extraction, the BSP source directory (layer) will be named | 195 | Upon extraction, the BSP source directory (layer) will be named |
@@ -198,14 +197,14 @@ | |||
198 | The following command extracts the Crown Bay BSP into the current directory and names it | 197 | The following command extracts the Crown Bay BSP into the current directory and names it |
199 | <filename>meta-crownbay</filename>: | 198 | <filename>meta-crownbay</filename>: |
200 | <literallayout class='monospaced'> | 199 | <literallayout class='monospaced'> |
201 | $ tar xjf crownbay-noemgd-bernard-5.0.1.tar.bz2 | 200 | $ tar xjf crownbay-noemgd-1.1.tar.bz2 |
202 | </literallayout> | 201 | </literallayout> |
203 | </para> | 202 | </para> |
204 | 203 | ||
205 | <para> | 204 | <para> |
206 | If you cloned a Yocto Project Git repository (<filename>poky</filename>) | 205 | If you cloned a Yocto Project Git repository (<filename>poky</filename>) |
207 | then you need to do the same for the | 206 | then you need to do the same for the |
208 | BSP, which is located in the <filename>meta-intel</filename> Git repository. | 207 | BSP, which is located in Yocto Project's <filename>meta-intel</filename> Git repository. |
209 | The <filename>meta-intel</filename> repository contains all the metadata | 208 | The <filename>meta-intel</filename> repository contains all the metadata |
210 | that supports BSP creation. | 209 | that supports BSP creation. |
211 | When you set up the <filename>meta-intel</filename> Git repository you can | 210 | When you set up the <filename>meta-intel</filename> Git repository you can |
@@ -236,7 +235,7 @@ | |||
236 | For this example we are going to use the <filename>[NEED BRANCH]</filename> branch. | 235 | For this example we are going to use the <filename>[NEED BRANCH]</filename> branch. |
237 | <literallayout class='monospaced'> | 236 | <literallayout class='monospaced'> |
238 | $ cd meta-intel | 237 | $ cd meta-intel |
239 | $ git checkout -b bernard origin/bernard | 238 | $ git checkout -b 1.1 origin/1.1 |
240 | Switched to a new branch 'bernard' | 239 | Switched to a new branch 'bernard' |
241 | </literallayout> | 240 | </literallayout> |
242 | [WRITER'S NOTE: I NEED THE REAL BRANCH NAMES IN THE EXAMPLE.] | 241 | [WRITER'S NOTE: I NEED THE REAL BRANCH NAMES IN THE EXAMPLE.] |
@@ -247,7 +246,7 @@ | |||
247 | <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title> | 246 | <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title> |
248 | 247 | ||
249 | <para> | 248 | <para> |
250 | Now that you have the Yocto Project and base BSP source you need to create a | 249 | Now that you have the Yocto Project and base BSP files you need to create a |
251 | new layer for your BSP. | 250 | new layer for your BSP. |
252 | </para> | 251 | </para> |
253 | 252 | ||
@@ -268,34 +267,36 @@ | |||
268 | Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>, | 267 | Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>, |
269 | <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>. | 268 | <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>. |
270 | The recipes and configurations for these four BSPs are located and dispersed | 269 | The recipes and configurations for these four BSPs are located and dispersed |
271 | within <filename>meta-yocto</filename>, which can be found in the Yocto Project source directory. | 270 | within <filename>meta-yocto</filename>, which can be found in the |
271 | area you unpacked the Yocto Project release tarball or set up your local | ||
272 | <filename>poky</filename> Git repository. | ||
272 | Consequently, they are not totally isolated in the spirit of layers unless you think | 273 | Consequently, they are not totally isolated in the spirit of layers unless you think |
273 | of <filename>meta-yocto</filename> as a layer itself. | 274 | of <filename>meta-yocto</filename> as a layer itself. |
274 | On the other hand, the Yocto Project has isolated BSP layers within | 275 | On the other hand, the Yocto Project has isolated BSP layers within |
275 | <filename>meta-intel</filename> for the Crown Bay, Emenlow, Jasper Forest, N450, and | 276 | <filename>meta-intel</filename> Git repository for the Crown Bay, Emenlow, Jasper Forest, |
276 | Sugar Bay. | 277 | N450, and Sugar Bay. |
277 | [WRITER'S NOTE: <filename>meta-yocto</filename>, <filename>meta</filename>, and | 278 | If you are not using a <filename>meta-intel</filename> Git repository then you would |
278 | <filename>meta-intel</filename> need some explanation. | 279 | downloaded a tarball for one of these isolated BSP layers. |
279 | Not sure about the relationship of meta-yocto as compared to meta-intel.] | ||
280 | </note> | 280 | </note> |
281 | 281 | ||
282 | <para> | 282 | <para> |
283 | When you set up a layer for a new BSP you should follow a standard layout. | 283 | When you set up a layer for a new BSP you should follow a standard layout. |
284 | This layout is described in | 284 | This layout is described in the |
285 | <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'> | 285 | <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'> |
286 | Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development | 286 | Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development |
287 | Guide. | 287 | Guide. |
288 | In the standard layout you will notice a suggested hierarchy for BSP kernel recipes, | 288 | In the standard layout you will notice a suggested structure for recipes and |
289 | graphics recipes, and configuration information. | 289 | configuration information. |
290 | You can see the standard layout for the Crown Bay BSP in this example by examining the | 290 | You can see the standard layout for the Crown Bay BSP in this example by examining the |
291 | directory structure of the <filename>meta-crownbay</filename> layer inside the | 291 | directory structure of the <filename>meta-crownbay</filename> layer inside the |
292 | <filename>meta-intel</filename> Git repository. | 292 | <filename>meta-intel</filename> Git repository or the area where you unpacked the |
293 | Crown Bay BSP tarball. | ||
293 | </para> | 294 | </para> |
294 | 295 | ||
295 | <para> | 296 | <para> |
296 | To create your BSP layer you simply copy the <filename>meta-crownbay</filename> | 297 | To create your BSP layer you simply copy the <filename>meta-crownbay</filename> |
297 | layer to a new layer. | 298 | layer to a new layer. |
298 | For this example the new layer is named <filename>meta-mymachine</filename>. | 299 | For this example the new layer will be named <filename>meta-mymachine</filename>. |
299 | The name must follow the BSP layer naming convention, which is | 300 | The name must follow the BSP layer naming convention, which is |
300 | <filename>meta-<name></filename>. | 301 | <filename>meta-<name></filename>. |
301 | The following example assumes your working directory is <filename>meta-intel</filename> | 302 | The following example assumes your working directory is <filename>meta-intel</filename> |
@@ -358,7 +359,7 @@ | |||
358 | <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'> | 359 | <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'> |
359 | Layer Configuration File</ulink> section in the Board Support Packages (BSP) Development Guide | 360 | Layer Configuration File</ulink> section in the Board Support Packages (BSP) Development Guide |
360 | for more information on this configuration file. | 361 | for more information on this configuration file. |
361 | Basically, we are removing statements that support EMGD and changing the ones that support no EMGD. | 362 | Basically, we are changing the existing statements to work with our BSP. |
362 | </para> | 363 | </para> |
363 | 364 | ||
364 | <para> | 365 | <para> |
@@ -385,20 +386,20 @@ | |||
385 | The standard BSP structure has areas for BSP, graphics, core, and kernel recipes. | 386 | The standard BSP structure has areas for BSP, graphics, core, and kernel recipes. |
386 | When you create a BSP you use these areas for appropriate recipes and append files. | 387 | When you create a BSP you use these areas for appropriate recipes and append files. |
387 | Recipes take the form of <filename>.bb</filename> files. | 388 | Recipes take the form of <filename>.bb</filename> files. |
388 | If you want to leverage off of existing recipes elsewhere in the Yocto Project | 389 | If you want to leverage the existing recipes the Yocto Project build system uses |
389 | source tree but change them you can use <filename>.bbappend</filename> files. | 390 | but change those recipes you can use <filename>.bbappend</filename> files. |
390 | All new recipes and append files for your layer go in the layer’s | 391 | All new recipes and append files for your layer must go in the layer’s |
391 | <filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>, | 392 | <filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>, |
392 | <filename>recipes-core</filename>, and | 393 | <filename>recipes-core</filename>, and |
393 | <filename>recipes-graphics</filename> directories. | 394 | <filename>recipes-graphics</filename> directories. |
394 | </para> | 395 | </para> |
395 | 396 | ||
396 | <para> | 397 | <para> |
397 | First, let us look at <filename>recipes-bsp</filename>. | 398 | First, let's look at <filename>recipes-bsp</filename>. |
398 | For this example we are not adding any new BSP recipes. | 399 | For this example we are not adding any new BSP recipes. |
399 | And, we only need to remove the formfactor we do not want and change the name of | 400 | And, we only need to remove the formfactor we do not want and change the name of |
400 | the remaining one that supports no EMGD. | 401 | the remaining one that doesn't support EMGD. |
401 | These commands take care of the new layer’s BSP recipes: | 402 | These commands take care of the <filename>recipes-bsp</filename> recipes: |
402 | <literallayout class='monospaced'> | 403 | <literallayout class='monospaced'> |
403 | $ rm ‐rf meta-mymachine/recipes-graphics/xorg-xserver/*emgd* | 404 | $ rm ‐rf meta-mymachine/recipes-graphics/xorg-xserver/*emgd* |
404 | $ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \ | 405 | $ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \ |
@@ -407,7 +408,7 @@ | |||
407 | </para> | 408 | </para> |
408 | 409 | ||
409 | <para> | 410 | <para> |
410 | Now let us look at <filename>recipes-graphics</filename>. | 411 | Now let's look at <filename>recipes-graphics</filename>. |
411 | For this example we want to remove anything that supports EMGD and | 412 | For this example we want to remove anything that supports EMGD and |
412 | be sure to rename remaining directories appropriately. | 413 | be sure to rename remaining directories appropriately. |
413 | The following commands clean up the <filename>recipes-graphics</filename> directory: | 414 | The following commands clean up the <filename>recipes-graphics</filename> directory: |
@@ -421,14 +422,15 @@ | |||
421 | 422 | ||
422 | <para> | 423 | <para> |
423 | At this point the <filename>recipes-graphics</filename> directory just has files that | 424 | At this point the <filename>recipes-graphics</filename> directory just has files that |
424 | support Video Electronics Standards Association (VESA) graphics modes. | 425 | support Video Electronics Standards Association (VESA) graphics modes and not EMGD. |
425 | </para> | 426 | </para> |
426 | 427 | ||
427 | <para> | 428 | <para> |
428 | Now let us look at changes in <filename>recipes-core</filename>. | 429 | Now let's look at changes in <filename>recipes-core</filename>. |
429 | The file <filename>task-core-tools.bbappend</filename> in | 430 | The file <filename>task-core-tools.bbappend</filename> in |
430 | <filename>recipes-core/tasks</filename> appends the similarly named recipe | 431 | <filename>recipes-core/tasks</filename> appends the similarly named recipe |
431 | located in the Yocto Project Git repository at <filename>meta/recipes-core/tasks</filename>. | 432 | located in the <filename>poky</filename> Git repository at |
433 | <filename>meta/recipes-core/tasks</filename>. | ||
432 | The "append" file in our layer right now is Crown Bay-specific and supports | 434 | The "append" file in our layer right now is Crown Bay-specific and supports |
433 | EMGD and non-EMGD. | 435 | EMGD and non-EMGD. |
434 | Here are the contents of the file: | 436 | Here are the contents of the file: |
@@ -449,16 +451,16 @@ | |||
449 | </para> | 451 | </para> |
450 | 452 | ||
451 | <para> | 453 | <para> |
452 | Finally, let us look at <filename>recipes-kernel</filename> changes. | 454 | Finally, let's look at <filename>recipes-kernel</filename> changes. |
453 | Recall that the BSP uses the <filename>linux-yocto</filename> kernel as determined | 455 | Recall that the BSP uses the <filename>linux-yocto</filename> kernel as determined |
454 | earlier in the <filename>mymachine.conf</filename>. | 456 | earlier in the <filename>mymachine.conf</filename>. |
455 | The recipe for that kernel is located is not located in the | 457 | The recipe for that kernel is located is not located in the |
456 | BSP layer but rather in Yocto Project Git repository at | 458 | BSP layer but rather in the <filename>poky</filename> Git repository at |
457 | <filename>meta/recipes-kernel/linux</filename> and is | 459 | <filename>meta/recipes-kernel/linux</filename> and is |
458 | named <filename>linux-yocto-2.6.37.bb</filename>. | 460 | named <filename>linux-yocto-2.6.37.bb</filename>. |
459 | The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename> | 461 | The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename> |
460 | statements point to the exact commits in the Yocto Project Git repository from | 462 | statements point to the exact commits in the <filename>poky</filename> Git repository |
461 | which the source for the kernel can be found. | 463 | that identify the right kernel for our hardware. |
462 | </para> | 464 | </para> |
463 | 465 | ||
464 | <para> | 466 | <para> |
@@ -471,8 +473,8 @@ | |||
471 | </para> | 473 | </para> |
472 | 474 | ||
473 | <para> | 475 | <para> |
474 | The <filename>SRCREV</filename> statements in the "append" file currently point | 476 | The <filename>SRCREV</filename> statements in the "append" file currently identify |
475 | to the kernel that supports the Crown Bay BSP with and without EMGD support. | 477 | the kernel that supports the Crown Bay BSP with and without EMGD support. |
476 | Here are the statements: | 478 | Here are the statements: |
477 | <literallayout class='monospaced'> | 479 | <literallayout class='monospaced'> |
478 | SRCREV_machine_pn-linux-yocto_crownbay ?= \ | 480 | SRCREV_machine_pn-linux-yocto_crownbay ?= \ |
@@ -489,21 +491,20 @@ | |||
489 | 491 | ||
490 | <para> | 492 | <para> |
491 | You will notice that there are two pairs of <filename>SRCREV</filename> statements. | 493 | You will notice that there are two pairs of <filename>SRCREV</filename> statements. |
492 | The top pair points to a kernel that supports | 494 | The top pair identifies the kernel that supports |
493 | EMGD, which we don’t care about in this example. | 495 | EMGD, which we don’t care about in this example. |
494 | The bottom pair points to the kernel that we will use: | 496 | The bottom pair identifies the kernel that we will use: |
495 | <filename>linux-yocto</filename>. | 497 | <filename>linux-yocto</filename>. |
496 | At this point though, the unique commit strings all are still associated with | 498 | At this point though, the unique commit strings all are still associated with |
497 | Crown Bay. | 499 | Crown Bay and not <filename>meta-mymachine</filename>. |
498 | </para> | 500 | </para> |
499 | 501 | ||
500 | <para> | 502 | <para> |
501 | So the next changes we make modify this <filename>linux-yocto-2.6.37.bbappend</filename> | 503 | To fix this situation in <filename>linux-yocto-2.6.37.bbappend</filename> |
502 | file. | 504 | we delete the two <filename>SRCREV</filename> statements that support |
503 | First, we delete the two <filename>SRCREV</filename> statements that support | ||
504 | EMGD (the top pair). | 505 | EMGD (the top pair). |
505 | Next, we change the remaining pair to specify <filename>mymachine</filename> | 506 | We also change the remaining pair to specify <filename>mymachine</filename> |
506 | and then we insert the commit identifier to point to the kernel in which we | 507 | and insert the commit identifiers to identify the kernel in which we |
507 | are interested, which will be based on the <filename>atom-pc-standard</filename> | 508 | are interested, which will be based on the <filename>atom-pc-standard</filename> |
508 | kernel. | 509 | kernel. |
509 | Here are the final <filename>SRCREV</filename> statements: | 510 | Here are the final <filename>SRCREV</filename> statements: |
@@ -542,10 +543,10 @@ | |||
542 | </para> | 543 | </para> |
543 | 544 | ||
544 | <para> | 545 | <para> |
545 | Also in the <filename>linux-yocto-2.6.47.bbappend</filename> file are | 546 | Also in the <filename>linux-yocto-2.6.37.bbappend</filename> file are |
546 | <filename>COMPATIBLE_MACHINE</filename>, <filename>KMACHINE</filename>, | 547 | <filename>COMPATIBLE_MACHINE</filename>, <filename>KMACHINE</filename>, |
547 | and <filename>KERNEL_FEATURES</filename> statements. | 548 | and <filename>KERNEL_FEATURES</filename> statements. |
548 | Again, there are two sets of these: one for EMGD support and one for non-EMGD support. | 549 | Two sets of these exist: one set supports EMGD and one set does not. |
549 | Because we are not interested in supporting EMGD those three can be deleted. | 550 | Because we are not interested in supporting EMGD those three can be deleted. |
550 | The remaining three must be changed so that <filename>mymachine</filename> replaces | 551 | The remaining three must be changed so that <filename>mymachine</filename> replaces |
551 | <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>. | 552 | <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>. |
@@ -571,7 +572,7 @@ | |||
571 | of any new recipes you might need. | 572 | of any new recipes you might need. |
572 | In this example, it was simply a matter of ridding the new layer | 573 | In this example, it was simply a matter of ridding the new layer |
573 | <filename>meta-machine</filename> of any code that supported the EMGD features | 574 | <filename>meta-machine</filename> of any code that supported the EMGD features |
574 | and making sure we were pointing to the kernel that supports our example, which | 575 | and making sure we were identifying the kernel that supports our example, which |
575 | is the <filename>atom-pc-standard</filename> kernel. | 576 | is the <filename>atom-pc-standard</filename> kernel. |
576 | We did not introduce any new recipes to the layer. | 577 | We did not introduce any new recipes to the layer. |
577 | </para> | 578 | </para> |
@@ -606,8 +607,10 @@ | |||
606 | <orderedlist> | 607 | <orderedlist> |
607 | <listitem><para>Get the environment ready for the build by sourcing the environment | 608 | <listitem><para>Get the environment ready for the build by sourcing the environment |
608 | script. | 609 | script. |
609 | The environment script is in the Yocto Project source directory | 610 | The environment script is in the top-level of the <filename>poky</filename> |
610 | (<filename>poky</filename> in this example) and has the string | 611 | Git repository or the top-level directory in which you unpacked the Yocto Project |
612 | release tarball. | ||
613 | The script has the string | ||
611 | <filename>init-build-env</filename> in the file’s name. | 614 | <filename>init-build-env</filename> in the file’s name. |
612 | For this example, the following command gets the build environment ready: | 615 | For this example, the following command gets the build environment ready: |
613 | <literallayout class='monospaced'> | 616 | <literallayout class='monospaced'> |
@@ -615,7 +618,7 @@ | |||
615 | </literallayout> | 618 | </literallayout> |
616 | When you source the script a build directory is created in the current | 619 | When you source the script a build directory is created in the current |
617 | working directory. | 620 | working directory. |
618 | In our example we were in the Yocto Project source directory. | 621 | In our example we were in the <filename>poky</filename> directory. |
619 | Thus, entering the previous command created the <filename>yocto-build</filename> directory. | 622 | Thus, entering the previous command created the <filename>yocto-build</filename> directory. |
620 | If you do not provide a name for the build directory it defaults to | 623 | If you do not provide a name for the build directory it defaults to |
621 | <filename>build</filename>. | 624 | <filename>build</filename>. |
@@ -672,9 +675,13 @@ | |||
672 | </para> | 675 | </para> |
673 | 676 | ||
674 | <para> | 677 | <para> |
678 | [WRITER'S NOTE: Consider moving this to the Poky Reference Manual.] | ||
679 | </para> | ||
680 | |||
681 | <para> | ||
675 | You can find these recipes in the <filename>meta/recipes-core/images</filename> and | 682 | You can find these recipes in the <filename>meta/recipes-core/images</filename> and |
676 | <filename>meta/recipes-sato/images</filename> directories of the Yocto Project source | 683 | <filename>meta/recipes-sato/images</filename> directories of your local Yocto Project |
677 | tree (the <filename>poky</filename> Git repository in this example). | 684 | file structure (Git repository or extracted release tarball). |
678 | Although the recipe names are somewhat explanatory, here is a list that describes them: | 685 | Although the recipe names are somewhat explanatory, here is a list that describes them: |
679 | <itemizedlist> | 686 | <itemizedlist> |
680 | <listitem><para><emphasis>Base</emphasis> – A foundational basic image without support | 687 | <listitem><para><emphasis>Base</emphasis> – A foundational basic image without support |