summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual/dev-manual-cases.xml
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/dev-manual/dev-manual-cases.xml')
-rw-r--r--documentation/dev-manual/dev-manual-cases.xml523
1 files changed, 392 insertions, 131 deletions
diff --git a/documentation/dev-manual/dev-manual-cases.xml b/documentation/dev-manual/dev-manual-cases.xml
index 315b028dbd..59c9168d6c 100644
--- a/documentation/dev-manual/dev-manual-cases.xml
+++ b/documentation/dev-manual/dev-manual-cases.xml
@@ -6,67 +6,116 @@
6<title>Development Cases</title> 6<title>Development Cases</title>
7 7
8<para> 8<para>
9For the purposes of this manual we are going to focus on two common development cases or groupings: System Development and User Application Development. System Development covers Board Support Package (BSP) development and kernel image modification. User Application Development covers development of applications that you intend to run on some target hardware. 9 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 covers Board Support Package (BSP) development and kernel image modification.
12 User Application Development covers development of applications that you intend to run on some
13 target hardware.
10</para> 14</para>
11 15
12<para> 16<para>
13[WRITERS NOTE: What is undetermined at this point is how much of the entire development process we include in this particular chapter. In other words, do we cover debugging and emulation steps here on a case-specific basis? Or, do we capture that information in the appropriate subsequent chapter by case?] 17 [WRITERS NOTE: What is undetermined at this point is how much of the entire development process
18 we include in this particular chapter.
19 In other words, do we cover debugging and emulation steps here on a case-specific basis?
20 Or, do we capture that information in the appropriate subsequent chapter by case?]
14</para> 21</para>
15 22
16<section id='system-development'> 23<section id='system-development'>
17 <title>System Development</title> 24 <title>System Development</title>
18 25
19 <para> 26 <para>
20System development involves modification or creation of an image that you want to run on a specific hardware target. Usually when you want to create an image that runs on embedded hardware the image does not require the same amount of features that a full-fledged Linux distribution provides. Thus, you can create a much smaller image that is designed to just use the hardware features for your particular hardware. 27 System development involves modification or creation of an image that you want to run on
28 a specific hardware target.
29 Usually when you want to create an image that runs on embedded hardware the image does
30 not require the same amount of features that a full-fledged Linux distribution provides.
31 Thus, you can create a much smaller image that is designed to just use the hardware
32 features for your particular hardware.
21 </para> 33 </para>
22 34
23 <para> 35 <para>
24To help you understand how system development works in the Yocto Project, this section covers two types of image development: BSP creation and kernel modification. 36 To help you understand how system development works in the Yocto Project, this section
37 covers two types of image development: BSP creation and kernel modification.
25 </para> 38 </para>
26 39
27 <section id='developing-a-board-support-package-bsp'> 40 <section id='developing-a-board-support-package-bsp'>
28 <title>Developing a Board Support Package (BSP)</title> 41 <title>Developing a Board Support Package (BSP)</title>
29 42
30 <para> 43 <para>
31A BSP is a package of recipes that when applied while building an image results in an image you can run on a particular board. Thus, the package, when compiled into the new image, supports the operation of the board. 44 A BSP is a package of recipes that when applied while building an image results in
45 an image you can run on a particular board.
46 Thus, the package, when compiled into the new image, supports the operation of the board.
32 </para> 47 </para>
33 48
34 <para> 49 <para>
35Packages consist of recipes. Recipes are sets of instructions for building a package. The recipes describe where to get source code and what patches to apply. Recipes also describe dependencies for libraries or for other recipes. They also contain configuration and compilation options. Recipes are logical units of execution. 50 Packages consist of recipes.
51 Recipes are sets of instructions for building a package.
52 The recipes describe where to get source code and what patches to apply.
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.
36 </para> 56 </para>
37 57
38 <para> 58 <para>
39Here are the basic steps involved in creating a BSP: 59 Here are the basic steps involved in creating a BSP:
40 <orderedlist> 60 <orderedlist>
41 <listitem><para>1.Be sure you are set up to use Yocto Project (see Chapter 2)</para></listitem> 61 <listitem><para>Be sure you are set up to use Yocto Project (see
42 <listitem><para>1.Choose a BSP available with Yocto Project that most closely represents your hardware</para></listitem> 62 <xref linkend='dev-manual-start'>Getting Started with the Yocto Project</xref>).</para></listitem>
43 <listitem><para>1.Get set up with a base BSP</para></listitem> 63 <listitem><para>Choose a BSP available with Yocto Project that most closely represents
44 <listitem><para>1.Make a copy of the existing BSP and isolate your work by creating a layer for your recipes</para></listitem> 64 your hardware.</para></listitem>
45 <listitem><para>1.Make configuration and recipe changes to your new BSP layer</para></listitem> 65 <listitem><para>Get set up with a base BSP.</para></listitem>
46 <listitem><para>1.Prepare for the build</para></listitem> 66 <listitem><para>Make a copy of the existing BSP and isolate your work by creating a layer
47 <listitem><para>1.Select and configure the kernel (NOTE: Not sure on this step)</para></listitem> 67 for your recipes.</para></listitem>
48 <listitem><para>1.Identify the machine branch in the Git repository</para></listitem> 68 <listitem><para>Make configuration and recipe changes to your new BSP layer.</para></listitem>
49 <listitem><para>1.Build the image</para></listitem> 69 <listitem><para>Prepare for the build.</para></listitem>
70 <listitem><para>Select and configure the kernel. (WRITER'S NOTE: Not sure on this step).</para></listitem>
71 <listitem><para>Identify the machine branch in the Git repository.</para></listitem>
72 <listitem><para>Build the image.</para></listitem>
50 </orderedlist> 73 </orderedlist>
51You can view a video presentation of the BSP creation process at http://free-electorons.com/blog/elc-2011-videos. You can also find supplemental information in the BSP Manual at http://yoctoproject.org//docs/1.1/bsp-guide/bsp-guide.html. Finally, there is another write up of the example used in this section at https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another you might find helpful. 74 You can view a video presentation of the BSP creation process
75 <ulink url='http://free-electrons.com/blog/elc-2011-videos'>here</ulink>.
76 You can also find supplemental information in the
77 <ulink url='http://yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
78 Board Support Package (BSP) Development Guide</ulink>.
79 Finally, there is wiki page write up of the example located
80 <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
81 here</ulink> you might find helpful.
52 </para> 82 </para>
53 83
54 <section id='setting-up-yocto-project'> 84 <section id='setting-up-yocto-project'>
55 <title>Setting Up Yocto Project</title> 85 <title>Setting Up Yocto Project</title>
56 86
57 <para> 87 <para>
58For general host development system preparation such as package requirements and operating system requirements, see Chapter 2 of this manual or the Yocto Project Quick start at http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html. 88 For general host development system preparation such as package requirements and
59 </para> 89 operating system requirements, see
60 90 <xref linkend='dev-manual-start'>Getting Started with the Yocto Project</xref>)Chapter 2 of
61 <para> 91 this manual or the
62You need to have the Yocto Project source tree available on your host system. You can get that through tarball extraction or by initializing and checking out the Yocto Project Git repository. Typically, checking out the Git repository is the method to use. This allows you to maintain a complete history of changes and facilitates you contributing back to the Yocto Project. However, if you just want the source you can download the Yocto Project Release tarball from http://yoctoproject.org/download. If you download the tarball you can extract it into any directory you want using the tar command. For example, the following commands extract the 1.0.1 release tarball into /usr/local/yocto with the Yocto Project source directory as poky.bernard.5.0.1.tar.bz2: 92 <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
93 Yocto Project Quick Start</ulink>.
94 </para>
95
96 <para>
97 You need to have the Yocto Project source tree available on your host system.
98 You can get that through tarball extraction or by initializing and checking out the
99 Yocto Project Git repository.
100 Typically, checking out the Git repository is the method to use.
101 This allows you to maintain a complete history of changes and facilitates you
102 contributing back to the Yocto Project.
103 However, if you just want the source you can download the Yocto Project Release
104 tarball from the
105 <ulink url='http://yoctoproject.org/download'>download page</ulink>.
106 If you download the tarball you can extract it into any directory you want using the
107 tar command.
108 For example, the following commands extract the 1.0.1 release tarball into
109 <filename>/usr/local/yocto</filename> with the Yocto Project source directory as
110 <filename>poky.bernard.5.0.1.tar.bz2</filename>:
63 <literallayout class='monospaced'> 111 <literallayout class='monospaced'>
64 /usr/local/yocto$ tar xfj poky.bernard.5.0.1.tar.bz2 112 /usr/local/yocto$ tar xfj poky.bernard.5.0.1.tar.bz2
65 </literallayout> 113 </literallayout>
66 </para> 114 </para>
67 115
68 <para> 116 <para>
69The following transcript shows how to initialize a Git repository and checkout the Yocto Project source tree: 117 The following transcript shows how to initialize a Git repository and checkout the
118 Yocto Project source tree:
70 <literallayout class='monospaced'> 119 <literallayout class='monospaced'>
71 /usr/local/yocto$ git init 120 /usr/local/yocto$ git init
72 Initialized empty Git repository in /usr/local/yocto/.git 121 Initialized empty Git repository in /usr/local/yocto/.git
@@ -111,7 +160,10 @@ The following transcript shows how to initialize a Git repository and checkout t
111 </para> 160 </para>
112 161
113 <para> 162 <para>
114Once you have the repository set up, you have many development branches from which you can work. For this example we are going to use the Yocto Project 1.0.1 Release, which maps to the Bernard 5.0.1 tag in Git. 163 Once you have the repository set up, you have many development branches from which
164 you can work.
165 For this example we are going to use the Yocto Project 1.0.1 Release,
166 which maps to the <filename>Bernard 5.0.1</filename> tag in Git.
115 <literallayout class='monospaced'> 167 <literallayout class='monospaced'>
116 /usr/local/yocto$ git checkout -b Bernard-5.0.1 bernard-5.0.1 168 /usr/local/yocto$ git checkout -b Bernard-5.0.1 bernard-5.0.1
117 Switched to a new branch 'bernard-5.0.1' 169 Switched to a new branch 'bernard-5.0.1'
@@ -123,15 +175,28 @@ Once you have the repository set up, you have many development branches from whi
123 <title>Choosing a Base BSP</title> 175 <title>Choosing a Base BSP</title>
124 176
125 <para> 177 <para>
126The Yocto Project ships with several BSPs that support various hardware. It is best to base your new BSP on an existing BSP rather than create all the recipes and configuration files from scratch. While it is possible to create everything from scratch, basing your new BSP on something that is close is much easier. Or, at a minimum, it gives you some structure with which to start. 178 The Yocto Project ships with several BSPs that support various hardware.
179 It is best to base your new BSP on an existing BSP rather than create all the
180 recipes and configuration files from scratch.
181 While it is possible to create everything from scratch, basing your new BSP
182 on something that is close is much easier.
183 Or, at a minimum, it gives you some structure with which to start.
127 </para> 184 </para>
128 185
129 <para> 186 <para>
130At this point you need to understand your target hardware well enough to determine which existing BSP most closely matches it. Things to consider are your hardware’s on-board features such as CPU type and graphics support. You should look at the README files for supported BSPs to get an idea of which one you could use. A generic Atom-based BSP to consider is the Crown Bay with no Intel® Embedded Media Graphics Driver (EMGD) support. That is the BSP that this example is going to use. 187 At this point you need to understand your target hardware well enough to determine which
188 existing BSP most closely matches it.
189 Things to consider are your hardware’s on-board features such as CPU type and graphics support.
190 You should look at the README files for supported BSPs to get an idea of which one
191 you could use.
192 A generic Atom-based BSP to consider is the Crown Bay with no Intel® Embedded Media
193 Graphics Driver (EMGD) support.
194 That is the BSP that this example is going to use.
131 </para> 195 </para>
132 196
133 <para> 197 <para>
134To see the supported BSPs go to http://www.yoctoproject.org/download and click on “BSP Downloads.” 198 To see the supported BSPs, go to the Yocto Project
199 <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click on “BSP Downloads.”
135 </para> 200 </para>
136 </section> 201 </section>
137 202
@@ -139,22 +204,34 @@ To see the supported BSPs go to http://www.yoctoproject.org/download and click o
139 <title>Getting Your Base BSP</title> 204 <title>Getting Your Base BSP</title>
140 205
141 <para> 206 <para>
142You need to have the base BSP layer on your development system. Like the Yocto Project source tree you can get the BSP layer one of two ways: download the tarball and extract it, or initialize a Git repository and check out the BSP. You should use the same method that you used for the Yocto Project source tree. 207 You need to have the base BSP layer on your development system.
208 Like the Yocto Project source tree you can get the BSP layer one of two ways:
209 download the tarball and extract it, or initialize a Git repository and check out the BSP.
210 You should use the same method that you used for the Yocto Project source tree.
143 </para> 211 </para>
144 212
145 <para> 213 <para>
146If you are using tarball extraction then simply download the tarball for the base BSP you chose in the previous step and then extract it into any directory you choose using the tar command. Upon extraction, the BSP source directory (layer) will be named <filename>meta-&lt;BSP_name&gt;</filename>. The following command extracts the Crown Bay BSP into a directory named meta-crownbay: 214 If you are using tarball extraction then simply download the tarball for the base
215 BSP you chose in the previous step and then extract it into any directory
216 you choose using the tar command.
217 Upon extraction, the BSP source directory (layer) will be named
218 <filename>meta-&lt;BSP_name&gt;</filename>.
219 The following command extracts the Crown Bay BSP into a directory named
220 <filename>meta-crownbay</filename>:
147 <literallayout class='monospaced'> 221 <literallayout class='monospaced'>
148 /usr/local$ tar xjf crownbay-noemgd-bernard-5.0.1.tar.bz2 222 /usr/local$ tar xjf crownbay-noemgd-bernard-5.0.1.tar.bz2
149 </literallayout> 223 </literallayout>
150 </para> 224 </para>
151 225
152 <para> 226 <para>
153If you initialized a Yocto Project Git repository then you need to do the same for the BSP, which is located in the meta-intel Git repository. The meta-intel repository contains all the metadata that supports BSP creation. 227 If you initialized a Yocto Project Git repository then you need to do the same for the
228 BSP, which is located in the meta-intel Git repository.
229 The meta-intel repository contains all the metadata that supports BSP creation.
154 </para> 230 </para>
155 231
156 <para> 232 <para>
157The following transcript shows the steps to create and set up the meta-intel Git repository inside the Yocto Project Git repository: 233 The following transcript shows the steps to create and set up the meta-intel Git
234 repository inside the Yocto Project Git repository:
158 <literallayout class='monospaced'> 235 <literallayout class='monospaced'>
159 /usr/local/yocto$ mkdir meta-intel 236 /usr/local/yocto$ mkdir meta-intel
160 /usr/local/yocto$ cd meta-intel 237 /usr/local/yocto$ cd meta-intel
@@ -179,7 +256,9 @@ The following transcript shows the steps to create and set up the meta-intel Git
179 </para> 256 </para>
180 257
181 <para> 258 <para>
182Once you have the repository set up, you have many development branches from which you can work. For this example we are going to use Bernard 5.0. 259 Once you have the repository set up, you have many development branches from
260 which you can work.
261 For this example we are going to use Bernard 5.0.
183 <literallayout class='monospaced'> 262 <literallayout class='monospaced'>
184 /usr/local/yocto/meta-intel$ git checkout -b Bernard-5.0.1 meta-intel/bernard 263 /usr/local/yocto/meta-intel$ git checkout -b Bernard-5.0.1 meta-intel/bernard
185 Branch Bernard-5.0.1 set up to track remote branch bernard from meta-intel. 264 Branch Bernard-5.0.1 set up to track remote branch bernard from meta-intel.
@@ -192,23 +271,59 @@ Once you have the repository set up, you have many development branches from whi
192 <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title> 271 <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
193 272
194 <para> 273 <para>
195Now that you have the Yocto Project and base BSP source you need to create a new layer for your BSP. 274 Now that you have the Yocto Project and base BSP source you need to create a
196 </para> 275 new layer for your BSP.
197 276 </para>
198 <para> 277
199Layers are ideal for isolating and storing work for a given piece of hardware. A layer is really just a location or area in which you place the recipes for your BSP. In fact, a BSP is, in itself, a special type of layer. Consider an application as another example that illustrates a layer. Suppose you are creating an application that has library or other dependencies in order for it to compile and run. The layer, in this case, would be where all the recipes that define those dependencies are kept. The key point for a layer is that it is an isolated area that contains all the relevant information for the project that the Yocto Project build system knows about. 278 <para>
200 </para> 279 Layers are ideal for isolating and storing work for a given piece of hardware.
201 280 A layer is really just a location or area in which you place the recipes for your BSP.
202 <para> 281 In fact, a BSP is, in itself, a special type of layer.
203[WRITER'S NOTE: The Yocto Project supports four BSPs that are part of the Yocto Project release: atom-pc, beagleboard, mpc8315e, and routerstationpro. The recipes and configurations for these four BSPs are located and dispersed within meta, which can be found in the Yocto Project source directory. Consequently, they are not totally isolated in the spirit of layers unless you think of meta as a layer itself. On the other hand, the Yocto Project has isolated BSP layers within meta-intel for the Crown Bay, Emenlow, Jasper Forest, N450, and Sugar Bay. [NOTE: meta-yocto, meta, and meta-intel need some explanation. Not sure about the relationship of meta-yocto as compared to meta-intel.] 282 Consider an application as another example that illustrates a layer.
204 </para> 283 Suppose you are creating an application that has library or other dependencies in
205 284 order for it to compile and run.
206 <para> 285 The layer, in this case, would be where all the recipes that define those dependencies
207When you set up a layer for a new BSP you should follow a standard layout. This layout is described in the BSP Manual at http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout. In the standard layout you will notice a suggested hierarchy for BSP kernel recipes, graphics recipes, and configuration information. You can see the standard layout for the Crown Bay BSP in this example by examining the directory structure of meta-crownbay. 286 are kept. The key point for a layer is that it is an isolated area that contains
208 </para> 287 all the relevant information for the project that the Yocto Project build system knows about.
209 288 </para>
210 <para> 289
211To create your BSP layer you simply copy the meta-crownbay layer to a new layer. For this example the new layer is named meta-mymachine. The name must follow the BSP layer naming convention, which is <filename>meta-&lt;name&gt;</filename>. The following example assumes a meta-intel Git repository. If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting meta-crownbay directory structure to a location of your choice: 290 <note>
291 The Yocto Project supports four BSPs that are part of the
292 Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
293 <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
294 The recipes and configurations for these four BSPs are located and dispersed
295 within <filename>meta</filename>, which can be found in the Yocto Project source directory.
296 Consequently, they are not totally isolated in the spirit of layers unless you think
297 of <filename>meta</filename> as a layer itself.
298 On the other hand, the Yocto Project has isolated BSP layers within
299 <filename>meta-intel</filename> for the Crown Bay, Emenlow, Jasper Forest, N450, and
300 Sugar Bay.
301 [WRITER'S NOTE: <filename>meta-yocto</filename>, <filename>meta</filename>, and
302 <filename>meta-intel</filename> need some explanation.
303 Not sure about the relationship of meta-yocto as compared to meta-intel.]
304 </note>
305
306 <para>
307 When you set up a layer for a new BSP you should follow a standard layout.
308 This layout is described in
309 <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>
310 Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development
311 Guide.
312 In the standard layout you will notice a suggested hierarchy for BSP kernel recipes,
313 graphics recipes, and configuration information.
314 You can see the standard layout for the Crown Bay BSP in this example by examining the
315 directory structure of <filename>meta-crownbay</filename>.
316 </para>
317
318 <para>
319 To create your BSP layer you simply copy the <filename>meta-crownbay</filename>
320 layer to a new layer.
321 For this example the new layer is named <filename>meta-mymachine</filename>.
322 The name must follow the BSP layer naming convention, which is
323 <filename>meta-&lt;name&gt;</filename>.
324 The following example assumes a meta-intel Git repository.
325 If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting
326 <filename>meta-crownbay</filename> directory structure to a location of your choice:
212 <literallayout class='monospaced'> 327 <literallayout class='monospaced'>
213 /usr/local/yocto/meta-intel$ cp -a meta-crownbay/ meta-mymachine 328 /usr/local/yocto/meta-intel$ cp -a meta-crownbay/ meta-mymachine
214 </literallayout> 329 </literallayout>
@@ -219,11 +334,22 @@ To create your BSP layer you simply copy the meta-crownbay layer to a new layer.
219 <title>Making Changes to Your BSP</title> 334 <title>Making Changes to Your BSP</title>
220 335
221 <para> 336 <para>
222Right now you have two identical BSP layers with different names: meta-crownbay and meta-mymachine. You need to change your configurations so that they work for your new BSP and your particular hardware. We will look first at the configurations, which are all done in the layer’s conf directory. 337 Right now you have two identical BSP layers with different names:
338 <filename>meta-crownbay</filename> and <filename>meta-mymachine</filename>.
339 You need to change your configurations so that they work for your new BSP and
340 your particular hardware.
341 We will look first at the configurations, which are all done in the layer’s
342 <filename>conf</filename> directory.
223 </para> 343 </para>
224 344
225 <para> 345 <para>
226First, since in this example the new BSP will not support EMGD we will get rid of the crownbay.conf file and then rename the crownbay-noemgd.conf file to mymachine.conf. Much of what we do in the configuration directory is designed to help the Yocto Project build system work with the new layer and to be able to find and use the right software. The following two commands result in a single machine configuration file named mymachine.conf. 346 First, since in this example the new BSP will not support EMGD we will get rid of the
347 <filename>crownbay.conf</filename> file and then rename the
348 <filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.
349 Much of what we do in the configuration directory is designed to help the Yocto Project
350 build system work with the new layer and to be able to find and use the right software.
351 The following two commands result in a single machine configuration file named
352 <filename>mymachine.conf</filename>.
227 <literallayout class='monospaced'> 353 <literallayout class='monospaced'>
228 /usr/local/yocto/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf 354 /usr/local/yocto/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf
229 /usr/local/yocto/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf \ 355 /usr/local/yocto/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf \
@@ -232,15 +358,26 @@ First, since in this example the new BSP will not support EMGD we will get rid o
232 </para> 358 </para>
233 359
234 <para> 360 <para>
235The next step makes changes to mymachine.conf itself. The only changes needed for this example are changes to the comment lines and to the Source Revision (SRCREV) lines at the bottom of the file. 361 The next step makes changes to <filename>mymachine.conf</filename> itself.
362 The only changes needed for this example are changes to the comment lines and to the
363 Source Revision (<filename>SRCREV</filename>) lines at the bottom of the file.
236 </para> 364 </para>
237 365
238 <para> 366 <para>
239For the comments the string crownbay-noemgd needs to be changed to mymachine. 367 For the comments the string <filename>crownbay-noemgd</filename> needs to be changed to
368 <filename>mymachine</filename>.
240 </para> 369 </para>
241 370
242 <para> 371 <para>
243To understand how to complete the changes to the SRCREV statements we need to know which kernel we are using. The PREFERRED_PROVIDER_virtual/kernel statement in the file specifies the kernel we are going to use. We are going to use linux-yocto-stable. The SRCREV statement pairs point to the exact machine branch (commit) and meta branch in the Git repository. Right now the SRCREV variables are as follows in mymachine.conf: 372 To understand how to complete the changes to the <filename>SRCREV</filename>
373 statements we need to know which kernel we are using.
374 The <filename>PREFERRED_PROVIDER_virtual/kernel</filename> statement in the file specifies
375 the kernel we are going to use.
376 We are going to use <filename>linux-yocto-stable</filename>.
377 The <filename>SRCREV</filename> statement pairs point to the exact machine branch
378 (commit) and <filename>meta</filename> branch in the Git repository.
379 Right now the <filename>SRCREV</filename> variables are as follows in
380 <filename>mymachine.conf</filename>:
244 <literallayout class='monospaced'> 381 <literallayout class='monospaced'>
245 SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \ "56fe215d3f1a2cc3a5a26482ac9809ba44495695" 382 SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \ "56fe215d3f1a2cc3a5a26482ac9809ba44495695"
246 SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \ "e1f85a470934a0cf6abde5d95533e74501822c6b" 383 SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \ "e1f85a470934a0cf6abde5d95533e74501822c6b"
@@ -251,7 +388,17 @@ To understand how to complete the changes to the SRCREV statements we need to kn
251 </para> 388 </para>
252 389
253 <para> 390 <para>
254You will notice that there are two pairs of SRCREV statements. The first pair points to a current development kernel, which we don’t care about in this example. The bottom pair points to the stable kernel that we will use: linux-yocto-stable. At this point though, the unique commit strings all are still associated with Crown Bay. So the next changes we make to the configuration file gets rid of the pair that points to the development kernel and provides new commit strings that points to the atom-pc-standard, which we are choosing for the initial build of this BSP. Here are the final SRCREV statements: 391 You will notice that there are two pairs of <filename>SRCREV</filename> statements.
392 The first pair points to a current development kernel, which we don’t care about
393 in this example.
394 The bottom pair points to the stable kernel that we will use:
395 <filename>linux-yocto-stable</filename>.
396 At this point though, the unique commit strings all are still associated with
397 Crown Bay.
398 So the next changes we make to the configuration file gets rid of the pair that points
399 to the development kernel and provides new commit strings that points to the
400 <filename>atom-pc-standard</filename>, which we are choosing for the initial build of this BSP.
401 Here are the final <filename>SRCREV</filename> statements:
255 <literallayout class='monospaced'> 402 <literallayout class='monospaced'>
256 SRCREV_machine_pn-linux-yocto-stable_mymachine ?= \ "72ca49ab08b8eb475cec82a10049503602325791" 403 SRCREV_machine_pn-linux-yocto-stable_mymachine ?= \ "72ca49ab08b8eb475cec82a10049503602325791"
257 SRCREV_meta_pn-linux-yocto-stable_mymachine ?= \ "ec26387cb168e9e0976999b528b5a9dd62e3157a" 404 SRCREV_meta_pn-linux-yocto-stable_mymachine ?= \ "ec26387cb168e9e0976999b528b5a9dd62e3157a"
@@ -259,30 +406,42 @@ You will notice that there are two pairs of SRCREV statements. The first pair p
259 </para> 406 </para>
260 407
261 <para> 408 <para>
262If you are familiar with Git repositories you probably won’t have trouble locating the exact commit strings you need to change the SRCREV statements. You can find all the machine and meta branch points (commits) for the linux-yocto-2.6.34 kernel at link http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.34. 409 If you are familiar with Git repositories you probably won’t have trouble locating the
410 exact commit strings you need to change the <filename>SRCREV</filename> statements.
411 You can find all the <filename>machine</filename> and <filename>meta</filename>
412 branch points (commits) for the <filename>linux-yocto-2.6.34</filename> kernel
413 <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.34'>here</ulink>.
263 </para> 414 </para>
264 415
265 <para> 416 <para>
266If you need a little more assistance after going to the link then do the following: 417 If you need a little more assistance after going to the link then do the following:
267 <orderedlist> 418 <orderedlist>
268 <listitem><para>1.Go to the http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.34 link</para></listitem> 419 <listitem><para>Expand the list of branches by clicking <filename>[…]</filename></para></listitem>
269 <listitem><para>1.Expand the list of branches by clicking […]</para></listitem> 420 <listitem><para>Click on the <filename>atom-pc-standard</filename> branch</para></listitem>
270 <listitem><para>1.Click on the atom-pc-standard branch</para></listitem> 421 <listitem><para>Click on the commit column header to view the top commit</para></listitem>
271 <listitem><para>1.Click on the commit column header to view the top commit</para></listitem> 422 <listitem><para>Copy the commit string for use in the <filename>mymachine.conf</filename>
272 <listitem><para>1.Copy the commit string for use in the mymachine.conf file</para></listitem> 423 file</para></listitem>
273 </orderedlist> 424 </orderedlist>
274 </para> 425 </para>
275 426
276 <para> 427 <para>
277For the SRCREV statement that points to the meta branch use the same procedure except expand the wrs_meta branch in step 2 above. 428 For the <filename>SRCREV</filename> statement that points to the <filename>meta</filename>
429 branch use the same procedure except expand the <filename>wrs_meta</filename>
430 branch in step 2 above.
278 </para> 431 </para>
279 432
280 <para> 433 <para>
281The next configuration file in the new BSP layer we need to edit is layer.conf. This file identifies build information needed for the new layer. You can see http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer for more information on this configuration file. Basically, we are removing statements that support EMGD and changing the ones that support no EMGD. 434 The next configuration file in the new BSP layer we need to edit is <filename>layer.conf</filename>.
435 This file identifies build information needed for the new layer.
436 You can see the
437 <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>
438 Layer Configuration File</ulink> section in the Board Support Packages (BSP) Development Guide
439 for more information on this configuration file.
440 Basically, we are removing statements that support EMGD and changing the ones that support no EMGD.
282 </para> 441 </para>
283 442
284 <para> 443 <para>
285First, remove these statements from the file: 444 First, remove these statements from the file:
286 <literallayout class='monospaced'> 445 <literallayout class='monospaced'>
287 BBFILE_COLLECTIONS_crownbayd += "crownbay" 446 BBFILE_COLLECTIONS_crownbayd += "crownbay"
288 BBFILE_PATTERN_crownbay := "^${LAYERDIR}/" 447 BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
@@ -291,7 +450,7 @@ First, remove these statements from the file:
291 </para> 450 </para>
292 451
293 <para> 452 <para>
294This leaves three similar statements that we care about: 453 This leaves three similar statements that we care about:
295 <literallayout class='monospaced'> 454 <literallayout class='monospaced'>
296 BBFILE_COLLECTIONS_crownbay-noemgd += "crownbay-noemgd" 455 BBFILE_COLLECTIONS_crownbay-noemgd += "crownbay-noemgd"
297 BBFILE_PATTERN_crownbay-noemgd := "^${LAYERDIR}/" 456 BBFILE_PATTERN_crownbay-noemgd := "^${LAYERDIR}/"
@@ -300,7 +459,8 @@ This leaves three similar statements that we care about:
300 </para> 459 </para>
301 460
302 <para> 461 <para>
303Simply substitute the machine string name crownbay-noemgd with the new machine name mymachine to get the following: 462 Simply substitute the machine string name <filename>crownbay-noemgd</filename>
463 with the new machine name <filename>mymachine</filename> to get the following:
304 <literallayout class='monospaced'> 464 <literallayout class='monospaced'>
305 BBFILE_COLLECTIONS_mymachine += "mymachine" 465 BBFILE_COLLECTIONS_mymachine += "mymachine"
306 BBFILE_PATTERN_mymachine := "^${LAYERDIR}/" 466 BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
@@ -309,11 +469,22 @@ Simply substitute the machine string name crownbay-noemgd with the new machine n
309 </para> 469 </para>
310 470
311 <para> 471 <para>
312Now we will take a look at the recipes in your new layer. The standard BSP structure has areas for BSP, graphics, and kernel recipes. When you create a BSP you use these areas for appropriate recipes and append files. Recipes take the form of .bb files. If you want to leverage off of existing recipes elsewhere in the Yocto Project source tree but change them you can use .bbappend files. All new recipes and append files for your layer go in the layer’s recipes-bsp, recipes-kernel, and recipes-graphics directories. 472 Now we will take a look at the recipes in your new layer.
473 The standard BSP structure has areas for BSP, graphics, and kernel recipes.
474 When you create a BSP you use these areas for appropriate recipes and append files.
475 Recipes take the form of <filename>.bb</filename> files.
476 If you want to leverage off of existing recipes elsewhere in the Yocto Project
477 source tree but change them you can use <filename>.bbappend</filename> files.
478 All new recipes and append files for your layer go in the layer’s
479 <filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>, and
480 <filename>recipes-graphics</filename> directories.
313 </para> 481 </para>
314 482
315 <para> 483 <para>
316For this example we are not adding any new BSP recipes. And, we only need to remove the formfactor we do not want and change the name of the remaining one that supports no EMGD. These commands take care of the new layer’s BSP recipes: 484 For this example we are not adding any new BSP recipes.
485 And, we only need to remove the formfactor we do not want and change the name of
486 the remaining one that supports no EMGD.
487 These commands take care of the new layer’s BSP recipes:
317 <literallayout class='monospaced'> 488 <literallayout class='monospaced'>
318 /usr/local/yocto/meta-intel$ rm -rf \ 489 /usr/local/yocto/meta-intel$ rm -rf \
319 meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay 490 meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
@@ -324,7 +495,8 @@ For this example we are not adding any new BSP recipes. And, we only need to re
324 </para> 495 </para>
325 496
326 <para> 497 <para>
327For this example we want to remove anything that supports EMGD. The following command cleans up the recipes-graphics directory: 498 For this example we want to remove anything that supports EMGD.
499 The following command cleans up the <filename>recipes-graphics</filename> directory:
328 <literallayout class='monospaced'> 500 <literallayout class='monospaced'>
329 /usr/local/yocto/meta-intel$ rm –rf \ 501 /usr/local/yocto/meta-intel$ rm –rf \
330 meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd* 502 meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*
@@ -332,7 +504,10 @@ For this example we want to remove anything that supports EMGD. The following c
332 </para> 504 </para>
333 505
334 <para> 506 <para>
335At this point the recipes-graphics directory just has files that support Video Electronics Standards Association (VESA) graphics modes. However, we still need to rename a directory in the layer. This command applies the final change to the recipes-graphics directory: 507 At this point the <filename>recipes-graphics</filename> directory just has files that
508 support Video Electronics Standards Association (VESA) graphics modes.
509 However, we still need to rename a directory in the layer.
510 This command applies the final change to the <filename>recipes-graphics</filename> directory:
336 <literallayout class='monospaced'> 511 <literallayout class='monospaced'>
337 /usr/local/yocto/meta-intel$ mv \ 512 /usr/local/yocto/meta-intel$ mv \
338 meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \ 513 meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
@@ -341,7 +516,11 @@ At this point the recipes-graphics directory just has files that support Video E
341 </para> 516 </para>
342 517
343 <para> 518 <para>
344Finally, let us look at the recipes-kernel directory in the example. The only file we are concerned with for the example is linux-yocto-stable_git.bbappend. The other files all support the EMGD feature of Crown Bay. These commands clean up the directory: 519 Finally, let us look at the <filename>recipes-kernel</filename> directory in the example.
520 The only file we are concerned with for the example is
521 <filename>linux-yocto-stable_git.bbappend</filename>.
522 The other files all support the EMGD feature of Crown Bay.
523 These commands clean up the directory:
345 <literallayout class='monospaced'> 524 <literallayout class='monospaced'>
346 /usr/local/yocto/meta-intel$ rm –rf meta-mymachine/recipes-kernel/linux/linux-yocto 525 /usr/local/yocto/meta-intel$ rm –rf meta-mymachine/recipes-kernel/linux/linux-yocto
347 /usr/local/yocto/meta-intel$ rm –rf \ 526 /usr/local/yocto/meta-intel$ rm –rf \
@@ -352,7 +531,13 @@ Finally, let us look at the recipes-kernel directory in the example. The only f
352 </para> 531 </para>
353 532
354 <para> 533 <para>
355The linux-yocto-stable_git.bbappend file appends a Yocto Project recipe having the same name. The changes we need to make are to remove the statements that support EMGD and change the remaining Crown Bay strings to be mymachine. We also do not need to include the pointer to the EMGD licenses patch at the end of the file. Here is the original file: 534 The <filename>linux-yocto-stable_git.bbappend</filename> file appends a Yocto Project
535 recipe having the same name.
536 The changes we need to make are to remove the statements that support EMGD
537 and change the remaining Crown Bay strings to be <filename>mymachine</filename>.
538 We also do not need to include the pointer to the EMGD licenses patch at the end of
539 the file.
540 Here is the original file:
356 <literallayout class='monospaced'> 541 <literallayout class='monospaced'>
357 FILESEXTRAPATHS := “${THISDIR}/${PN}” 542 FILESEXTRAPATHS := “${THISDIR}/${PN}”
358 COMPATIBLE_MACHINE_crownbay = “crownbay” 543 COMPATIBLE_MACHINE_crownbay = “crownbay”
@@ -364,7 +549,7 @@ The linux-yocto-stable_git.bbappend file appends a Yocto Project recipe having t
364 </para> 549 </para>
365 550
366 <para> 551 <para>
367After editing the file it looks like this: 552 After editing the file it looks like this:
368 <literallayout class='monospaced'> 553 <literallayout class='monospaced'>
369 FILESEXTRAPATHS := “${THISDIR}/${PN}” 554 FILESEXTRAPATHS := “${THISDIR}/${PN}”
370 COMPATIBLE_MACHINE_mymachine = “mymachine” 555 COMPATIBLE_MACHINE_mymachine = “mymachine”
@@ -373,11 +558,17 @@ After editing the file it looks like this:
373 </para> 558 </para>
374 559
375 <para> 560 <para>
376In summary, the edits to the layer’s recipe files result in removal of any files and statements that do not support your targeted hardware in addition to the inclusion of any new recipes you might need. In this example, it was simply a matter of ridding the new layer meta-machine of any code that supported the EMGD features. We did not introduce any new recipes to the layer. 561 In summary, the edits to the layer’s recipe files result in removal of any files and
562 statements that do not support your targeted hardware in addition to the inclusion
563 of any new recipes you might need.
564 In this example, it was simply a matter of ridding the new layer <filename>meta-machine</filename>
565 of any code that supported the EMGD features.
566 We did not introduce any new recipes to the layer.
377 </para> 567 </para>
378 568
379 <para> 569 <para>
380Finally, it is also important to update the layer’s README file so that the information in it reflects your BSP. 570 Finally, it is also important to update the layer’s <filename>README</filename>
571 file so that the information in it reflects your BSP.
381 </para> 572 </para>
382 </section> 573 </section>
383 574
@@ -385,30 +576,58 @@ Finally, it is also important to update the layer’s README file so that the in
385 <title>Preparing for the Build</title> 576 <title>Preparing for the Build</title>
386 577
387 <para> 578 <para>
388Once you have made all the changes to your BSP layer there remains a few things you need to do for the Yocto Project build system in order for it to create your image. You need to get the build environment ready by sourcing an environment setup script and you need to be sure two key configuration files are configured appropriately. 579 Once you have made all the changes to your BSP layer there remains a few things
580 you need to do for the Yocto Project build system in order for it to create your image.
581 You need to get the build environment ready by sourcing an environment setup script
582 and you need to be sure two key configuration files are configured appropriately.
389 </para> 583 </para>
390 584
391 <para> 585 <para>
392The entire process for building an image is overviewed in the Yocto Project Quick Start at http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image. You might want to reference this information. The remainder of this section will apply to our example of the meta-mymachine layer. 586 The entire process for building an image is overviewed in the
587 <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
588 Building an Image</ulink> section of the Yocto Project Quick Start.
589 You might want to reference this information.
590 The remainder of this section will apply to our example of the <filename>meta-mymachine</filename> layer.
393 </para> 591 </para>
394 592
395 <para> 593 <para>
396To get ready to build your new layer you need to do the following: 594 To get ready to build your new layer you need to do the following:
397 <orderedlist> 595 <orderedlist>
398 <listitem><para> 596 <listitem><para>Get the environment ready for the build by sourcing the environment
3991.Get the environment ready for the build by sourcing the environment script. The environment script is in the Yocto Project source directory and has the string init-build-env in the file’s name. For this example, the following command gets the build environment ready: 597 script.
598 The environment script is in the Yocto Project source directory and has the string
599 <filename>init-build-env</filename> in the file’s name.
600 For this example, the following command gets the build environment ready:
400 <literallayout class='monospaced'> 601 <literallayout class='monospaced'>
401 /usr/local/yocto$ source poky-init-build-env yocto-build 602 /usr/local/yocto$ source oe-init-build-env yocto-build
402 </literallayout> 603 </literallayout>
403When you source the script a build directory is created in the current working directory. In our example we were in the Yocto Project source directory. Thus, entering the previous command created the yocto-build directory. If you do not provide a name for the build directory it defaults to build. The build directory contains a conf directory that contains two configuration files you will need to check: bblayers.conf and local.conf.</para></listitem> 604 When you source the script a build directory is created in the current
404 <listitem><para> 605 working directory.
4051.Check and edit the resulting local.conf file. This file minimally identifies the machine for which to build the image by configuring the MACHINE variable. For this example you must set the variable to mymachine as follows: 606 In our example we were in the Yocto Project source directory.
607 Thus, entering the previous command created the <filename>yocto-build</filename> directory.
608 If you do not provide a name for the build directory it defaults to build.
609 The build directory contains a <filename>conf</filename> directory that contains
610 two configuration files you will need to check: <filename>bblayers.conf</filename>
611 and <filename>local.conf</filename>.</para></listitem>
612 <listitem><para>Check and edit the resulting <filename>local.conf</filename> file.
613 This file minimally identifies the machine for which to build the image by
614 configuring the <filename>MACHINE</filename> variable.
615 For this example you must set the variable to mymachine as follows:
406 <literallayout class='monospaced'> 616 <literallayout class='monospaced'>
407 MACHINE ??= “mymachine” 617 MACHINE ??= “mymachine”
408 </literallayout> 618 </literallayout>
409 You should also be sure any other variables in which you are interested are set. Some variables to consider are BB_NUMBER_THREADS and PARALLEL_MAKE, both of which can greatly reduce your build time if you are using a multi-threaded development system (e.g. values of 8 and j 6, respectively are optimal for a development machine that has four available cores).</para></listitem> 619 You should also be sure any other variables in which you are interested are set.
410 <listitem><para> 620 Some variables to consider are <filename>BB_NUMBER_THREADS</filename>
4111.Update the bblayers.conf file so that it includes the path to your new BSP layer. In this example you need to include the pathname to meta-mymachine. For example, if you created a Yocto Project Git repository named yocto in /usr/local then the BBLAYERS variable in the file would need to include the following path: 621 and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time
622 if you are using a multi-threaded development system (e.g. values of
623 <filename>8</filename> and <filename>j 6</filename>, respectively are optimal
624 for a development machine that has four available cores).</para></listitem>
625 <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes
626 the path to your new BSP layer.
627 In this example you need to include the pathname to <filename>meta-mymachine</filename>.
628 For example, if you created a Yocto Project Git repository named
629 <filename>yocto</filename> in <filename>/usr/local</filename> then the
630 <filename>BBLAYERS</filename> variable in the file would need to include the following path:
412 <literallayout class='monospaced'> 631 <literallayout class='monospaced'>
413 /usr/local/yocto/meta-intel/meta-mymachine 632 /usr/local/yocto/meta-intel/meta-mymachine
414 </literallayout></para></listitem> 633 </literallayout></para></listitem>
@@ -416,7 +635,10 @@ When you source the script a build directory is created in the current working d
416 </para> 635 </para>
417 636
418 <para> 637 <para>
419The variable glossary in the Poky Reference Manual at http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos has more information on configuration variables. 638 The appendix
639 <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
640 Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information
641 on configuration variables.
420 </para> 642 </para>
421 </section> 643 </section>
422 644
@@ -424,49 +646,80 @@ The variable glossary in the Poky Reference Manual at http://www.yoctoproject.or
424 <title>Building the Image</title> 646 <title>Building the Image</title>
425 647
426 <para> 648 <para>
427The Yocto Project uses the BitBake tool to build images based on the type of image you want to create. You can find more information on this tool at http://bitbake.berlios.de/manual/. 649 The Yocto Project uses the BitBake tool to build images based on the type of image
650 you want to create.
651 You can find more information on BitBake
652 <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.
428 </para> 653 </para>
429 654
430 <para> 655 <para>
431The build process supports several types of images to satisfy different needs. When you issue the BitBake command you provide a “top-level” recipe that essentially starts the process off of building the type of image you want. 656 The build process supports several types of images to satisfy different needs.
657 When you issue the BitBake command you provide a “top-level” recipe that essentially
658 starts the process off of building the type of image you want.
432 </para> 659 </para>
433 660
434 <para> 661 <para>
435You can find these recipes in the meta/recipes-core/images and meta/recipes-sato/images directories of the Yocto Project source tree or Git repository. Although the recipe names are somewhat explanatory, here is a list that describes them: 662 You can find these recipes in the <filename>meta/recipes-core/images</filename> and
663 <filename>meta/recipes-sato/images</filename> directories of the Yocto Project source
664 tree or Git repository.
665 Although the recipe names are somewhat explanatory, here is a list that describes them:
436 <itemizedlist> 666 <itemizedlist>
437 <listitem><para>Base – A foundational basic image without support for X that can be reasonably used for customization.</para></listitem> 667 <listitem><para><emphasis>Base</emphasis> – A foundational basic image without support
438 <listitem><para>Core – A foundational basic image with support for X that can be reasonably used for customization.</para></listitem> 668 for X that can be reasonably used for customization.</para></listitem>
439 <listitem><para>Direct Disk – An image that you can copy directory to the disk of the target device.</para></listitem> 669 <listitem><para><emphasis>Core</emphasis> – A foundational basic image with support for
440 <listitem><para>Live – An image you can run from a USB device or from a CD without having to first install something.</para></listitem> 670 X that can be reasonably used for customization.</para></listitem>
441 <listitem><para>Minimal – A small image without a GUI. This image is not much more than a kernel with a shell.</para></listitem> 671 <listitem><para><emphasis>Direct Disk</emphasis> – An image that you can copy directory to
442 <listitem><para>Minimal Development – A Minimal image suitable for development work.</para></listitem> 672 the disk of the target device.</para></listitem>
443 <listitem><para>Minimal Direct Disk – A Minimal Direct Disk image.</para></listitem> 673 <listitem><para><emphasis>Live</emphasis> – An image you can run from a USB device or from
444 <listitem><para>Minimal RAM-based Initial Root Filesystem – A minimal image that has the initramfs as part of the kernel, which allows the system to find the first “init” program more efficiently.</para></listitem> 674 a CD without having to first install something.</para></listitem>
445 <listitem><para>Minimal Live – A Minimal Live image.</para></listitem> 675 <listitem><para><emphasis>Minimal</emphasis> – A small image without a GUI.
446 <listitem><para>Minimal MTD Utilities – A minimal image that has support for the MTD utilities, which let the user interact with the MTD subsystem in the kernel to perform operations on flash devices.</para></listitem> 676 This image is not much more than a kernel with a shell.</para></listitem>
447 <listitem><para>Sato – An image with Sato support, a mobile environment and visual style that works well with mobile devices.</para></listitem> 677 <listitem><para><emphasis>Minimal Development</emphasis> – A Minimal image suitable for
448 <listitem><para>Sato Development – A Sato image suitable for development work.</para></listitem> 678 development work.</para></listitem>
449 <listitem><para>Sato Direct Disk – A Sato Direct Disk image.</para></listitem> 679 <listitem><para><emphasis>Minimal Direct Disk</emphasis> – A Minimal Direct Disk image.</para></listitem>
450 <listitem><para>Sato Live – A Sato Live image.</para></listitem> 680 <listitem><para><emphasis>Minimal RAM-based Initial Root Filesystem</emphasis> – A minimal image
451 <listitem><para>Sato SDK – A Sato image that includes the Yocto Project toolchain and development libraries.</para></listitem> 681 that has the <filename>initramfs</filename> as part of the kernel, which allows the
452 <listitem><para>Sato SDK Direct Disk – A Sato SDK Direct Disk image.</para></listitem> 682 system to find the first “init” program more efficiently.</para></listitem>
453 <listitem><para>Sato SDK Live – A Sato SDK Live image.</para></listitem> 683 <listitem><para><emphasis>Minimal Live</emphasis> – A Minimal Live image.</para></listitem>
684 <listitem><para><emphasis>Minimal MTD Utilities</emphasis> – A minimal image that has support
685 for the MTD utilities, which let the user interact with the MTD subsystem in
686 the kernel to perform operations on flash devices.</para></listitem>
687 <listitem><para><emphasis>Sato</emphasis> – An image with Sato support, a mobile environment
688 and visual style that works well with mobile devices.</para></listitem>
689 <listitem><para><emphasis>Sato Development</emphasis> – A Sato image suitable for
690 development work.</para></listitem>
691 <listitem><para><emphasis>Sato Direct Disk</emphasis> – A Sato Direct Disk image.</para></listitem>
692 <listitem><para><emphasis>Sato Live</emphasis> – A Sato Live image.</para></listitem>
693 <listitem><para><emphasis>Sato SDK</emphasis> – A Sato image that includes the Yocto Project
694 toolchain and development libraries.</para></listitem>
695 <listitem><para><emphasis>Sato SDK Direct Disk</emphasis> – A Sato SDK Direct
696 Disk image.</para></listitem>
697 <listitem><para><emphasis>Sato SDK Live</emphasis> – A Sato SDK Live image.</para></listitem>
454 </itemizedlist> 698 </itemizedlist>
455 </para> 699 </para>
456 700
457 <para> 701 <para>
458The remainder of this section applies to our example of the meta-mymachine layer. 702 The remainder of this section applies to our example of the <filename>meta-mymachine</filename> layer.
459 </para> 703 </para>
460 704
461 <para> 705 <para>
462To build the image for our meta-mymachine BSP enter the following command from the same shell from which you ran the setup script. You should run the bitbake command without any intervening shell commands. For example, moving your working directory around could cause problems. Here is the command for this example: 706 To build the image for our <filename>meta-mymachine</filename> BSP enter the following command
707 from the same shell from which you ran the setup script.
708 You should run the <filename>bitbake</filename> command without any intervening shell commands.
709 For example, moving your working directory around could cause problems.
710 Here is the command for this example:
463 <literallayout class='monospaced'> 711 <literallayout class='monospaced'>
464/usr/local/yocto/yocto-build$ bitbake –k poky-image-sato-live 712/usr/local/yocto/yocto-build$ bitbake –k poky-image-sato-live
465 </literallayout> 713 </literallayout>
466 </para> 714 </para>
467 715
468 <para> 716 <para>
469This command requests an image that has Sato support and can be run from a USB device or from a CD without having to first install anything. The build process takes significant time and includes thousands of tasks, which are reported at the console. If the build results in any type of error you should check for misspellings in the files you changed or problems with your host development environment such as missing packages. 717 This command requests an image that has Sato support and can be run from a USB device or
718 from a CD without having to first install anything.
719 The build process takes significant time and includes thousands of tasks, which are reported
720 at the console.
721 If the build results in any type of error you should check for misspellings in the
722 files you changed or problems with your host development environment such as missing packages.
470 </para> 723 </para>
471 </section> 724 </section>
472 </section> 725 </section>
@@ -475,23 +728,31 @@ This command requests an image that has Sato support and can be run from a USB d
475 <title>Modifying a Kernel</title> 728 <title>Modifying a Kernel</title>
476 729
477 <para> 730 <para>
478[WRITER'S NOTE: This section is a second example that focuses on just modifying the kernel. 731 [WRITER'S NOTE: This section is a second example that focuses on just modifying the kernel.
479I don't have any information on this yet. 732 I don't have any information on this yet.
480 </para> 733 </para>
481 734
482 <para> 735 <para>
483Here are some points to consider though: 736 Here are some points to consider though:
484 <itemizedlist> 737 <itemizedlist>
485 <listitem><para>1.Reference http://events.linuxfoundation.org/events/embedded-linux-conference/hart</para></listitem> 738 <listitem><para>Reference Darren's presentation
486 <listitem><para>1.Reference the “Getting Started” chapter to get set up at minimum.</para></listitem> 739 <ulink url='http://events.linuxfoundation.org/events/embedded-linux-conference/hart'>
487 <listitem><para>1.Are there extra steps I need specific to kernel development to get started?</para></listitem> 740 here</ulink></para></listitem>
488 <listitem><para>1.What do I do to get set up? Is it a matter of just installing YP and having some pieces together? What are the pieces?</para></listitem> 741 <listitem><para>Reference <xref linkend='dev-manual-start'>Getting Started with the Yocto Project</xref>
489 <listitem><para>1.Where do I get the base kernel to start with?</para></listitem> 742 section to get set up at minimum.</para></listitem>
490 <listitem><para>1.Do I install the appropriate toolchain?</para></listitem> 743 <listitem><para>Are there extra steps I need specific to kernel development to get started?</para></listitem>
491 <listitem><para>1.What kernel git repository do I use?</para></listitem> 744 <listitem><para>What do I do to get set up?
492 <listitem><para>1.What is the conversion script? What does it do?</para></listitem> 745 Is it a matter of just installing YP and having some pieces together?
493 <listitem><para>1.What do I have to do to integrate the kernel layer?</para></listitem> 746 What are the pieces?</para></listitem>
494 <listitem><para>1.What do I use to integrate the kernel layer? HOB? Do I just Bitbake it?</para></listitem> 747 <listitem><para>Where do I get the base kernel to start with?</para></listitem>
748 <listitem><para>Do I install the appropriate toolchain?</para></listitem>
749 <listitem><para>What kernel git repository do I use?</para></listitem>
750 <listitem><para>What is the conversion script?
751 What does it do?</para></listitem>
752 <listitem><para>What do I have to do to integrate the kernel layer?</para></listitem>
753 <listitem><para>What do I use to integrate the kernel layer?
754 HOB?
755 Do I just Bitbake it?</para></listitem>
495 <listitem><para>Using the System Image Creator.]</para></listitem> 756 <listitem><para>Using the System Image Creator.]</para></listitem>
496 </itemizedlist> 757 </itemizedlist>
497 </para> 758 </para>
@@ -502,13 +763,13 @@ Here are some points to consider though:
502 <title>User Application Development</title> 763 <title>User Application Development</title>
503 764
504 <para> 765 <para>
505[WRITER'S NOTE: This section is the second major development case - developing an application. 766 [WRITER'S NOTE: This section is the second major development case - developing an application.
506Here are points to consider: 767 Here are points to consider:
507 <itemizedlist> 768 <itemizedlist>
508 <listitem><para>1.User-space Application Development scenario overview.</para></listitem> 769 <listitem><para>User-space Application Development scenario overview.</para></listitem>
509 <listitem><para>1.Using the Yocto Eclipse Plug-in.</para></listitem> 770 <listitem><para>Using the Yocto Eclipse Plug-in.</para></listitem>
510 <listitem><para>1.Back-door support.</para></listitem> 771 <listitem><para>Back-door support.</para></listitem>
511 <listitem><para>1.I feel there is more to this area than we have captured during our two review meetings.]</para></listitem> 772 <listitem><para>I feel there is more to this area than we have captured during our two review meetings.]</para></listitem>
512 </itemizedlist> 773 </itemizedlist>
513 </para> 774 </para>
514</section> 775</section>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-11 21:41:14 +0000