diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2013-01-10 18:55:01 -0600 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2013-01-27 13:54:09 +0000 |
commit | cdacd8764b26b945253c7a94941806ce34a44da6 (patch) | |
tree | 508ebed09bf8c7e1425207236d808963ff16b1f1 /documentation | |
parent | 982637f27ae86d83a7ef425c84ab70345e269451 (diff) | |
download | poky-cdacd8764b26b945253c7a94941806ce34a44da6.tar.gz |
profile-manual: Copied in raw "Examples" chapter.
I put the raw text is for chapter 4. No editing.
(From yocto-docs rev: e4a017624595394f86f469e15c1c8ad13e82206d)
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/profile-manual/profile-manual-examples.xml | 1906 |
1 files changed, 15 insertions, 1891 deletions
diff --git a/documentation/profile-manual/profile-manual-examples.xml b/documentation/profile-manual/profile-manual-examples.xml index 442cab3036..e4363ca632 100644 --- a/documentation/profile-manual/profile-manual-examples.xml +++ b/documentation/profile-manual/profile-manual-examples.xml | |||
@@ -2,1911 +2,35 @@ | |||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" | 2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" |
3 | [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > | 3 | [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > |
4 | 4 | ||
5 | <chapter id='dev-manual-model'> | 5 | <chapter id='profile-manual-examples'> |
6 | 6 | ||
7 | <title>Common Development Models</title> | 7 | <title>Real-World Examples</title> |
8 | 8 | ||
9 | <para> | 9 | <para> |
10 | Many development models exist for which you can use the Yocto Project. | 10 | This chapter contains real-world examples. |
11 | This chapter overviews simple methods that use tools provided by the | ||
12 | Yocto Project: | ||
13 | <itemizedlist> | ||
14 | <listitem><para><emphasis>System Development:</emphasis> | ||
15 | System Development covers Board Support Package (BSP) development and kernel | ||
16 | modification or configuration. | ||
17 | For an example on how to create a BSP, see the | ||
18 | "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" | ||
19 | section in the Yocto Project Board Support Package (BSP) Developer's Guide. | ||
20 | </para></listitem> | ||
21 | <listitem><para><emphasis>User Application Development:</emphasis> | ||
22 | User Application Development covers development of applications that you intend | ||
23 | to run on some target hardware. | ||
24 | For information on how to set up your host development system for user-space | ||
25 | application development, see the | ||
26 | <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>. | ||
27 | For a simple example of user-space application development using the | ||
28 | <trademark class='trade'>Eclipse</trademark> IDE, see the | ||
29 | "<link linkend='application-development-workflow'>Application | ||
30 | Development Workflow</link>" section. | ||
31 | </para></listitem> | ||
32 | <listitem><para><emphasis>Temporary Source Code Modification:</emphasis> | ||
33 | Direct modification of temporary source code is a convenient development model | ||
34 | to quickly iterate and develop towards a solution. | ||
35 | Once the solution has been implemented, you should of course take steps to | ||
36 | get the changes upstream and applied in the affected recipes.</para></listitem> | ||
37 | <listitem><para><emphasis>Image Development using Hob:</emphasis> | ||
38 | You can use the <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build | ||
39 | custom operating system images within the build environment. | ||
40 | Hob provides an efficient interface to the OpenEmbedded build system.</para></listitem> | ||
41 | <listitem><para><emphasis>Using a Development Shell:</emphasis> | ||
42 | You can use a <filename>devshell</filename> to efficiently debug commands or simply | ||
43 | edit packages. | ||
44 | Working inside a development shell is a quick way to set up the OpenEmbedded build | ||
45 | environment to work on parts of a project.</para></listitem> | ||
46 | </itemizedlist> | ||
47 | </para> | 11 | </para> |
48 | 12 | ||
49 | <section id='system-development-model'> | 13 | <section id='slow-write-speed-on-live-images'> |
50 | <title>System Development Workflow</title> | 14 | <title>Slow Write Speed on Line Images</title> |
51 | 15 | ||
52 | <para> | 16 | <para> |
53 | System development involves modification or creation of an image that you want to run on | 17 | In one of our previous releases (denzil), users noticed that booting |
54 | a specific hardware target. | 18 | off of a live image and writing to disk was noticeably slower. |
55 | Usually, when you want to create an image that runs on embedded hardware, the image does | 19 | This included the boot itself, especially the first one, since first |
56 | not require the same number of features that a full-fledged Linux distribution provides. | 20 | boots tend to do a significant amount of writing due to certain |
57 | Thus, you can create a much smaller image that is designed to use only the | 21 | post-install scripts. |
58 | features for your particular hardware. | ||
59 | </para> | 22 | </para> |
60 | 23 | ||
61 | <para> | 24 | <para> |
62 | To help you understand how system development works in the Yocto Project, this section | 25 | The problem (and solution) was discovered by using the Yocto tracing |
63 | covers two types of image development: BSP creation and kernel modification or | 26 | tools, in this case 'perf stat', 'perf script', 'perf record' |
64 | configuration. | 27 | and 'perf report'. |
65 | </para> | 28 | </para> |
66 | 29 | ||
67 | <section id='developing-a-board-support-package-bsp'> | ||
68 | <title>Developing a Board Support Package (BSP)</title> | ||
69 | |||
70 | <para> | ||
71 | A BSP is a package of recipes that, when applied during a build, results in | ||
72 | an image that you can run on a particular board. | ||
73 | Thus, the package when compiled into the new image, supports the operation of the board. | ||
74 | </para> | ||
75 | |||
76 | <note> | ||
77 | For a brief list of terms used when describing the development process in the Yocto Project, | ||
78 | see the "<link linkend='yocto-project-terms'>Yocto Project Terms</link>" section. | ||
79 | </note> | ||
80 | |||
81 | <para> | ||
82 | The remainder of this section presents the basic steps used to create a BSP | ||
83 | using the Yocto Project's | ||
84 | <ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>BSP Tools</ulink>. | ||
85 | For an example that shows how to create a new layer using the tools, see the | ||
86 | "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" | ||
87 | section in the Yocto Project Board Support Package (BSP) Developer's Guide. | ||
88 | </para> | ||
89 | |||
90 | <para> | ||
91 | The following illustration and list summarize the BSP creation general workflow. | ||
92 | </para> | ||
93 | |||
94 | <para> | ||
95 | <imagedata fileref="figures/bsp-dev-flow.png" width="6in" depth="7in" align="center" scalefit="1" /> | ||
96 | </para> | ||
97 | |||
98 | <para> | ||
99 | <orderedlist> | ||
100 | <listitem><para><emphasis>Set up your host development system to support | ||
101 | development using the Yocto Project</emphasis>: See the | ||
102 | "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" | ||
103 | and the | ||
104 | "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both | ||
105 | in the Yocto Project Quick Start for requirements.</para></listitem> | ||
106 | <listitem><para><emphasis>Establish a local copy of the project files on your | ||
107 | system</emphasis>: You need this <link linkend='source-directory'>Source | ||
108 | Directory</link> available on your host system. | ||
109 | Having these files on your system gives you access to the build | ||
110 | process and to the tools you need. | ||
111 | For information on how to set up the | ||
112 | <link linkend='source-directory'>Source Directory</link>, see the | ||
113 | "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem> | ||
114 | <listitem><para><emphasis>Establish the <filename>meta-intel</filename> | ||
115 | repository on your system</emphasis>: Having local copies of the | ||
116 | supported BSP layers on your system gives you access to the build | ||
117 | process and to the tools you need for creating a BSP. | ||
118 | For information on how to get these files, see the | ||
119 | "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem> | ||
120 | <listitem><para><emphasis>Create your own BSP layer using the | ||
121 | <ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>: | ||
122 | Layers are ideal for | ||
123 | isolating and storing work for a given piece of hardware. | ||
124 | A layer is really just a location or area in which you place the recipes for your BSP. | ||
125 | In fact, a BSP is, in itself, a special type of layer. | ||
126 | The simplest way to create a new BSP layer that is compliant with the | ||
127 | Yocto Project is to use the <filename>yocto-bsp</filename> script. | ||
128 | For information about that script, see the | ||
129 | "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" | ||
130 | section in the Yocto Project Board Support (BSP) Developer's Guide. | ||
131 | </para> | ||
132 | <para> | ||
133 | Another example that illustrates a layer is an application. | ||
134 | Suppose you are creating an application that has library or other dependencies in | ||
135 | order for it to compile and run. | ||
136 | The layer, in this case, would be where all the recipes that define those dependencies | ||
137 | are kept. | ||
138 | The key point for a layer is that it is an isolated area that contains | ||
139 | all the relevant information for the project that the OpenEmbedded build | ||
140 | system knows about. | ||
141 | For more information on layers, see the | ||
142 | "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>" | ||
143 | section. | ||
144 | For more information on BSP layers, see the | ||
145 | "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the | ||
146 | Yocto Project Board Support Package (BSP) Developer's Guide.</para> | ||
147 | <note>Four BSPs exist that are part of the | ||
148 | Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>, | ||
149 | <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>. | ||
150 | The recipes and configurations for these four BSPs are located and dispersed | ||
151 | within the <link linkend='source-directory'>Source Directory</link>. | ||
152 | On the other hand, BSP layers for Cedar Trail, Chief River, Crown Bay, | ||
153 | Crystal Forest, Emenlow, Fish River, Fish River 2, Jasper Forest, N450, | ||
154 | Romley, sys940x, Sugar Bay, and tlk exist in their own separate layers | ||
155 | within the larger <filename>meta-intel</filename> layer.</note> | ||
156 | <para>When you set up a layer for a new BSP, you should follow a standard layout. | ||
157 | This layout is described in the section | ||
158 | "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>" | ||
159 | section of the Board Support Package (BSP) Development Guide. | ||
160 | In the standard layout, you will notice a suggested structure for recipes and | ||
161 | configuration information. | ||
162 | You can see the standard layout for a BSP by examining | ||
163 | any supported BSP found in the <filename>meta-intel</filename> layer inside | ||
164 | the Source Directory.</para></listitem> | ||
165 | <listitem><para><emphasis>Make configuration changes to your new BSP | ||
166 | layer</emphasis>: The standard BSP layer structure organizes the files you need | ||
167 | to edit in <filename>conf</filename> and several <filename>recipes-*</filename> | ||
168 | directories within the BSP layer. | ||
169 | Configuration changes identify where your new layer is on the local system | ||
170 | and identify which kernel you are going to use. | ||
171 | When you run the <filename>yocto-bsp</filename> script you are able to interactively | ||
172 | configure many things for the BSP (e.g. keyboard, touchscreen, and so forth). | ||
173 | </para></listitem> | ||
174 | <listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>: Recipe | ||
175 | changes include altering recipes (<filename>.bb</filename> files), removing | ||
176 | recipes you don't use, and adding new recipes or append files | ||
177 | (<filename>.bbappend</filename>) that you need to support your hardware. | ||
178 | </para></listitem> | ||
179 | <listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the | ||
180 | changes to your BSP layer, there remains a few things | ||
181 | you need to do for the OpenEmbedded build system in order for it to create your image. | ||
182 | You need to get the build environment ready by sourcing an environment setup script | ||
183 | and you need to be sure two key configuration files are configured appropriately: | ||
184 | the <filename>conf/local.conf</filename> and the | ||
185 | <filename>conf/bblayers.conf</filename> file. | ||
186 | You must make the OpenEmbedded build system aware of your new layer. | ||
187 | See the | ||
188 | "<link linkend='enabling-your-layer'>Enabling Your Layer</link>" section | ||
189 | for information on how to let the build system know about your new layer.</para> | ||
190 | <para>The entire process for building an image is overviewed in the section | ||
191 | "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section | ||
192 | of the Yocto Project Quick Start. | ||
193 | You might want to reference this information.</para></listitem> | ||
194 | <listitem><para><emphasis>Build the image</emphasis>: The OpenEmbedded build system | ||
195 | uses the BitBake tool to build images based on the type of image you want to create. | ||
196 | You can find more information about BitBake in the user manual, which is found in the | ||
197 | <filename>bitbake/doc/manual</filename> directory of the | ||
198 | <link linkend='source-directory'>Source Directory</link>.</para> | ||
199 | <para>The build process supports several types of images to satisfy different needs. | ||
200 | See the | ||
201 | "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter | ||
202 | in the Yocto Project Reference Manual for information on | ||
203 | supported images.</para></listitem> | ||
204 | </orderedlist> | ||
205 | </para> | ||
206 | |||
207 | <para> | ||
208 | You can view a video presentation on "Building Custom Embedded Images with Yocto" | ||
209 | at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>. | ||
210 | You can also find supplemental information in | ||
211 | <ulink url='&YOCTO_DOCS_BSP_URL;'> | ||
212 | The Board Support Package (BSP) Development Guide</ulink>. | ||
213 | Finally, there is wiki page write up of the example also located | ||
214 | <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'> | ||
215 | here</ulink> that you might find helpful. | ||
216 | </para> | ||
217 | </section> | ||
218 | |||
219 | <section id='modifying-the-kernel'> | ||
220 | <title><anchor id='kernel-spot' />Modifying the Kernel</title> | ||
221 | |||
222 | <para> | ||
223 | Kernel modification involves changing the Yocto Project kernel, which could involve changing | ||
224 | configuration options as well as adding new kernel recipes. | ||
225 | Configuration changes can be added in the form of configuration fragments, while recipe | ||
226 | modification comes through the kernel's <filename>recipes-kernel</filename> area | ||
227 | in a kernel layer you create. | ||
228 | </para> | ||
229 | |||
230 | <para> | ||
231 | The remainder of this section presents a high-level overview of the Yocto Project | ||
232 | kernel architecture and the steps to modify the kernel. | ||
233 | For a complete discussion of the kernel, see the | ||
234 | <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>. | ||
235 | You can reference the | ||
236 | "<link linkend='patching-the-kernel'>Patching the Kernel</link>" section | ||
237 | for an example that changes the source code of the kernel. | ||
238 | For information on how to configure the kernel, see the | ||
239 | "<link linkend='configuring-the-kernel'>Configuring the Kernel</link>" section. | ||
240 | </para> | ||
241 | |||
242 | <section id='kernel-overview'> | ||
243 | <title>Kernel Overview</title> | ||
244 | |||
245 | <para> | ||
246 | Traditionally, when one thinks of a patched kernel, they think of a base kernel | ||
247 | source tree and a fixed structure that contains kernel patches. | ||
248 | The Yocto Project, however, employs mechanisms, that in a sense, result in a kernel source | ||
249 | generator. | ||
250 | By the end of this section, this analogy will become clearer. | ||
251 | </para> | ||
252 | |||
253 | <para> | ||
254 | You can find a web interface to the Yocto Project kernel source repositories at | ||
255 | <ulink url='&YOCTO_GIT_URL;'></ulink>. | ||
256 | If you look at the interface, you will see to the left a grouping of | ||
257 | Git repositories titled "Yocto Linux Kernel." | ||
258 | Within this group, you will find several kernels supported by | ||
259 | the Yocto Project: | ||
260 | <itemizedlist> | ||
261 | <listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The | ||
262 | stable Yocto Project kernel that is based on the Linux 2.6.34 released kernel.</para></listitem> | ||
263 | <listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The | ||
264 | stable Yocto Project kernel that is based on the Linux 2.6.37 released kernel.</para></listitem> | ||
265 | <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable | ||
266 | Yocto Project kernel that is based on the Linux 3.0 released kernel.</para></listitem> | ||
267 | <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The | ||
268 | stable Yocto Project kernel to use with the Yocto Project Release 1.1.x. This kernel | ||
269 | is based on the Linux 3.0 released kernel.</para></listitem> | ||
270 | <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The | ||
271 | stable Yocto Project kernel to use with the Yocto Project Release 1.2. This kernel | ||
272 | is based on the Linux 3.2 released kernel.</para></listitem> | ||
273 | <listitem><para><emphasis><filename>linux-yocto-3.4</filename></emphasis> - The | ||
274 | stable Yocto Project kernel to use with the Yocto Project Release 1.3. This kernel | ||
275 | is based on the Linux 3.4 released kernel.</para></listitem> | ||
276 | <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development | ||
277 | kernel based on the latest upstream release candidate available.</para></listitem> | ||
278 | </itemizedlist> | ||
279 | </para> | ||
280 | |||
281 | <para> | ||
282 | The kernels are maintained using the Git revision control system | ||
283 | that structures them using the familiar "tree", "branch", and "leaf" scheme. | ||
284 | Branches represent diversions from general code to more specific code, while leaves | ||
285 | represent the end-points for a complete and unique kernel whose source files | ||
286 | when gathered from the root of the tree to the leaf accumulate to create the files | ||
287 | necessary for a specific piece of hardware and its features. | ||
288 | The following figure displays this concept: | ||
289 | <para> | ||
290 | <imagedata fileref="figures/kernel-overview-1.png" | ||
291 | width="6in" depth="6in" align="center" scale="100" /> | ||
292 | </para> | ||
293 | |||
294 | <para> | ||
295 | Within the figure, the "Kernel.org Branch Point" represents the point in the tree | ||
296 | where a supported base kernel is modified from the Linux kernel. | ||
297 | For example, this could be the branch point for the <filename>linux-yocto-3.0</filename> | ||
298 | kernel. | ||
299 | Thus, everything further to the right in the structure is based on the | ||
300 | <filename>linux-yocto-3.0</filename> kernel. | ||
301 | Branch points to right in the figure represent where the | ||
302 | <filename>linux-yocto-3.0</filename> kernel is modified for specific hardware | ||
303 | or types of kernels, such as real-time kernels. | ||
304 | Each leaf thus represents the end-point for a kernel designed to run on a specific | ||
305 | targeted device. | ||
306 | </para> | ||
307 | |||
308 | <para> | ||
309 | The overall result is a Git-maintained repository from which all the supported | ||
310 | kernel types can be derived for all the supported devices. | ||
311 | A big advantage to this scheme is the sharing of common features by keeping them in | ||
312 | "larger" branches within the tree. | ||
313 | This practice eliminates redundant storage of similar features shared among kernels. | ||
314 | </para> | ||
315 | |||
316 | <note> | ||
317 | Keep in mind the figure does not take into account all the supported Yocto | ||
318 | Project kernel types, but rather shows a single generic kernel just for conceptual purposes. | ||
319 | Also keep in mind that this structure represents the Yocto Project source repositories | ||
320 | that are either pulled from during the build or established on the host development system | ||
321 | prior to the build by either cloning a particular kernel's Git repository or by | ||
322 | downloading and unpacking a tarball. | ||
323 | </note> | ||
324 | |||
325 | <para> | ||
326 | Upstream storage of all the available kernel source code is one thing, while | ||
327 | representing and using the code on your host development system is another. | ||
328 | Conceptually, you can think of the kernel source repositories as all the | ||
329 | source files necessary for all the supported kernels. | ||
330 | As a developer, you are just interested in the source files for the kernel on | ||
331 | on which you are working. | ||
332 | And, furthermore, you need them available on your host system. | ||
333 | </para> | ||
334 | |||
335 | <para> | ||
336 | Kernel source code is available on your host system a couple of different | ||
337 | ways. | ||
338 | If you are working in the kernel all the time, you probably would want | ||
339 | to set up your own local Git repository of the kernel tree. | ||
340 | If you just need to make some patches to the kernel, you can get at | ||
341 | temporary kernel source files extracted and used during the OpenEmbedded | ||
342 | build system. | ||
343 | We will just talk about working with the temporary source code. | ||
344 | </para> | ||
345 | |||
346 | <para> | ||
347 | What happens during the build? | ||
348 | When you build the kernel on your development system, all files needed for the build | ||
349 | are taken from the source repositories pointed to by the | ||
350 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> variable | ||
351 | and gathered in a temporary work area | ||
352 | where they are subsequently used to create the unique kernel. | ||
353 | Thus, in a sense, the process constructs a local source tree specific to your | ||
354 | kernel to generate the new kernel image - a source generator if you will. | ||
355 | </para> | ||
356 | The following figure shows the temporary file structure | ||
357 | created on your host system when the build occurs. | ||
358 | This | ||
359 | <link linkend='build-directory'>Build Directory</link> contains all the | ||
360 | source files used during the build. | ||
361 | </para> | ||
362 | |||
363 | <para> | ||
364 | <imagedata fileref="figures/kernel-overview-2-generic.png" | ||
365 | width="6in" depth="5in" align="center" scale="100" /> | ||
366 | </para> | ||
367 | |||
368 | <para> | ||
369 | Again, for a complete discussion of the Yocto Project kernel's architecture and its | ||
370 | branching strategy, see the | ||
371 | <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>. | ||
372 | You can also reference the | ||
373 | "<link linkend='patching-the-kernel'>Patching the Kernel</link>" | ||
374 | section for a detailed example that modifies the kernel. | ||
375 | </para> | ||
376 | </section> | ||
377 | |||
378 | <section id='kernel-modification-workflow'> | ||
379 | <title>Kernel Modification Workflow</title> | ||
380 | |||
381 | <para> | ||
382 | This illustration and the following list summarizes the kernel modification general workflow. | ||
383 | </para> | ||
384 | |||
385 | <para> | ||
386 | <imagedata fileref="figures/kernel-dev-flow.png" | ||
387 | width="6in" depth="5in" align="center" scalefit="1" /> | ||
388 | </para> | ||
389 | |||
390 | <para> | ||
391 | <orderedlist> | ||
392 | <listitem><para><emphasis>Set up your host development system to support | ||
393 | development using the Yocto Project</emphasis>: See | ||
394 | "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and | ||
395 | "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both | ||
396 | in the Yocto Project Quick Start for requirements.</para></listitem> | ||
397 | <listitem><para><emphasis>Establish a local copy of project files on your | ||
398 | system</emphasis>: Having the <link linkend='source-directory'>Source | ||
399 | Directory</link> on your system gives you access to the build process and tools | ||
400 | you need. | ||
401 | For information on how to get these files, see the bulleted item | ||
402 | "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual. | ||
403 | </para></listitem> | ||
404 | <listitem><para><emphasis>Establish the temporary kernel source files</emphasis>: | ||
405 | Temporary kernel source files are kept in the Build Directory created by the | ||
406 | OpenEmbedded build system when you run BitBake. | ||
407 | If you have never built the kernel you are interested in, you need to run | ||
408 | an initial build to establish local kernel source files.</para> | ||
409 | <para>If you are building an image for the first time, you need to get the build | ||
410 | environment ready by sourcing | ||
411 | the environment setup script. | ||
412 | You also need to be sure two key configuration files | ||
413 | (<filename>local.conf</filename> and <filename>bblayers.conf</filename>) | ||
414 | are configured appropriately.</para> | ||
415 | <para>The entire process for building an image is overviewed in the | ||
416 | "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" | ||
417 | section of the Yocto Project Quick Start. | ||
418 | You might want to reference this information. | ||
419 | You can find more information on BitBake in the user manual, which is found in the | ||
420 | <filename>bitbake/doc/manual</filename> directory of the | ||
421 | <link linkend='source-directory'>Source Directory</link>.</para> | ||
422 | <para>The build process supports several types of images to satisfy different needs. | ||
423 | See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in | ||
424 | the Yocto Project Reference Manual for information on supported images. | ||
425 | </para></listitem> | ||
426 | <listitem><para><emphasis>Make changes to the kernel source code if | ||
427 | applicable</emphasis>: Modifying the kernel does not always mean directly | ||
428 | changing source files. | ||
429 | However, if you have to do this, you make the changes to the files in the | ||
430 | Build directory.</para></listitem> | ||
431 | <listitem><para><emphasis>Make kernel configuration changes | ||
432 | if applicable</emphasis>: | ||
433 | If your situation calls for changing the kernel's configuration, you can | ||
434 | use the <filename>yocto-kernel</filename> script or <filename>menuconfig</filename> | ||
435 | to enable and disable kernel configurations. | ||
436 | Using the script lets you interactively set up kernel configurations. | ||
437 | Using <filename>menuconfig</filename> allows you to interactively develop and test the | ||
438 | configuration changes you are making to the kernel. | ||
439 | When saved, changes using <filename>menuconfig</filename> update the kernel's | ||
440 | <filename>.config</filename>. | ||
441 | Try to resist the temptation of directly editing the <filename>.config</filename> | ||
442 | file found in the | ||
443 | <link linkend='build-directory'>Build Directory</link> at | ||
444 | <filename>tmp/sysroots/<machine-name>/kernel</filename>. | ||
445 | Doing so, can produce unexpected results when the OpenEmbedded build system | ||
446 | regenerates the configuration file.</para> | ||
447 | <para>Once you are satisfied with the configuration changes made using | ||
448 | <filename>menuconfig</filename>, you can directly examine the | ||
449 | <filename>.config</filename> file against a saved original and gather those | ||
450 | changes into a config fragment to be referenced from within the kernel's | ||
451 | <filename>.bbappend</filename> file.</para></listitem> | ||
452 | <listitem><para><emphasis>Rebuild the kernel image with your changes</emphasis>: | ||
453 | Rebuilding the kernel image applies your changes.</para></listitem> | ||
454 | </orderedlist> | ||
455 | </para> | ||
456 | </section> | ||
457 | </section> | ||
458 | </section> | ||
459 | |||
460 | <section id='application-development-workflow'> | ||
461 | <title>Application Development Workflow</title> | ||
462 | |||
463 | <para> | 30 | <para> |
464 | Application development involves creating an application that you want | 31 | See all the unvarnished details of how this bug was diagnosed and |
465 | to run on your target hardware, which is running a kernel image created using the | 32 | solved here: Yocto Bug #3049 |
466 | OpenEmbedded build system. | ||
467 | The Yocto Project provides an Application Development Toolkit (ADT) and | ||
468 | stand-alone cross-development toolchains that | ||
469 | facilitate quick development and integration of your application into its run-time environment. | ||
470 | Using the ADT and toolchains, you can compile and link your application. | ||
471 | You can then deploy your application to the actual hardware or to the QEMU emulator for testing. | ||
472 | If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE, | ||
473 | you can use an Eclipse Yocto Plug-in to | ||
474 | allow you to develop, deploy, and test your application all from within Eclipse. | ||
475 | </para> | 33 | </para> |
476 | |||
477 | <para> | ||
478 | While we strongly suggest using the ADT to develop your application, this option might not | ||
479 | be best for you. | ||
480 | If this is the case, you can still use pieces of the Yocto Project for your development process. | ||
481 | However, because the process can vary greatly, this manual does not provide detail on the process. | ||
482 | </para> | ||
483 | |||
484 | <section id='workflow-using-the-adt-and-eclipse'> | ||
485 | <title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title> | ||
486 | |||
487 | <para> | ||
488 | To help you understand how application development works using the ADT, this section | ||
489 | provides an overview of the general development process and a detailed example of the process | ||
490 | as it is used from within the Eclipse IDE. | ||
491 | </para> | ||
492 | |||
493 | <para> | ||
494 | The following illustration and list summarize the application development general workflow. | ||
495 | </para> | ||
496 | |||
497 | <para> | ||
498 | <imagedata fileref="figures/app-dev-flow.png" | ||
499 | width="7in" depth="8in" align="center" scale="100" /> | ||
500 | </para> | ||
501 | |||
502 | <para> | ||
503 | <orderedlist> | ||
504 | <listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>: | ||
505 | See | ||
506 | "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and | ||
507 | "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both | ||
508 | in the Yocto Project Quick Start for requirements.</para></listitem> | ||
509 | <listitem><para><emphasis>Secure the Yocto Project Kernel Target Image</emphasis>: | ||
510 | You must have a target kernel image that has been built using the OpenEmbeded | ||
511 | build system.</para> | ||
512 | <para>Depending on whether the Yocto Project has a pre-built image that matches your target | ||
513 | architecture and where you are going to run the image while you develop your application | ||
514 | (QEMU or real hardware), the area from which you get the image differs. | ||
515 | <itemizedlist> | ||
516 | <listitem><para>Download the image from | ||
517 | <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink> | ||
518 | if your target architecture is supported and you are going to develop | ||
519 | and test your application on actual hardware.</para></listitem> | ||
520 | <listitem><para>Download the image from the | ||
521 | <ulink url='&YOCTO_QEMU_DL_URL;'> | ||
522 | <filename>machines/qemu</filename></ulink> if your target architecture is supported | ||
523 | and you are going to develop and test your application using the QEMU | ||
524 | emulator.</para></listitem> | ||
525 | <listitem><para>Build your image if you cannot find a pre-built image that matches | ||
526 | your target architecture. | ||
527 | If your target architecture is similar to a supported architecture, you can | ||
528 | modify the kernel image before you build it. | ||
529 | See the | ||
530 | "<link linkend='patching-the-kernel'>Patching the Kernel</link>" | ||
531 | section for an example.</para></listitem> | ||
532 | </itemizedlist></para> | ||
533 | <para>For information on pre-built kernel image naming schemes for images | ||
534 | that can run on the QEMU emulator, see the | ||
535 | "<ulink url='&YOCTO_DOCS_QS_URL;#downloading-the-pre-built-linux-kernel'>Downloading the Pre-Built Linux Kernel</ulink>" | ||
536 | section in the Yocto Project Quick Start.</para></listitem> | ||
537 | <listitem><para><emphasis>Install the ADT</emphasis>: | ||
538 | The ADT provides a target-specific cross-development toolchain, the root filesystem, | ||
539 | the QEMU emulator, and other tools that can help you develop your application. | ||
540 | While it is possible to get these pieces separately, the ADT Installer provides an | ||
541 | easy method. | ||
542 | You can get these pieces by running an ADT installer script, which is configurable. | ||
543 | For information on how to install the ADT, see the | ||
544 | "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>" | ||
545 | section | ||
546 | in the Yocto Project Application Developer's Guide.</para></listitem> | ||
547 | <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem | ||
548 | and the Cross-development Toolchain</emphasis>: | ||
549 | If you choose not to install the ADT using the ADT Installer, | ||
550 | you need to find and download the appropriate root filesystem and | ||
551 | the cross-development toolchain.</para> | ||
552 | <para>You can find the tarballs for the root filesystem in the same area used | ||
553 | for the kernel image. | ||
554 | Depending on the type of image you are running, the root filesystem you need differs. | ||
555 | For example, if you are developing an application that runs on an image that | ||
556 | supports Sato, you need to get root filesystem that supports Sato.</para> | ||
557 | <para>You can find the cross-development toolchains at | ||
558 | <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>. | ||
559 | Be sure to get the correct toolchain for your development host and your | ||
560 | target architecture. | ||
561 | See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" | ||
562 | section in the Yocto Project Application Developer's Guide for information | ||
563 | and the | ||
564 | "<ulink url='&YOCTO_DOCS_QS_URL;#installing-the-toolchain'>Installing the Toolchain</ulink>" | ||
565 | in the Yocto Project Quick Start for information on finding and installing | ||
566 | the correct toolchain based on your host development system and your target | ||
567 | architecture. | ||
568 | </para></listitem> | ||
569 | <listitem><para><emphasis>Create and Build your Application</emphasis>: | ||
570 | At this point, you need to have source files for your application. | ||
571 | Once you have the files, you can use the Eclipse IDE to import them and build the | ||
572 | project. | ||
573 | If you are not using Eclipse, you need to use the cross-development tools you have | ||
574 | installed to create the image.</para></listitem> | ||
575 | <listitem><para><emphasis>Deploy the Image with the Application</emphasis>: | ||
576 | If you are using the Eclipse IDE, you can deploy your image to the hardware or to | ||
577 | QEMU through the project's preferences. | ||
578 | If you are not using the Eclipse IDE, then you need to deploy the application | ||
579 | to the hardware using other methods. | ||
580 | Or, if you are using QEMU, you need to use that tool and load your image in for testing. | ||
581 | </para></listitem> | ||
582 | <listitem><para><emphasis>Test and Debug the Application</emphasis>: | ||
583 | Once your application is deployed, you need to test it. | ||
584 | Within the Eclipse IDE, you can use the debugging environment along with the | ||
585 | set of user-space tools installed along with the ADT to debug your application. | ||
586 | Of course, the same user-space tools are available separately if you choose | ||
587 | not to use the Eclipse IDE.</para></listitem> | ||
588 | </orderedlist> | ||
589 | </para> | ||
590 | </section> | ||
591 | |||
592 | <section id='adt-eclipse'> | ||
593 | <title>Working Within Eclipse</title> | ||
594 | |||
595 | <para> | ||
596 | The Eclipse IDE is a popular development environment and it fully supports | ||
597 | development using the Yocto Project. | ||
598 | <note>This release of the Yocto Project supports both the Juno and Indigo versions | ||
599 | of the Eclipse IDE. | ||
600 | Thus, the following information provides setup information for both versions. | ||
601 | </note> | ||
602 | </para> | ||
603 | |||
604 | <para> | ||
605 | When you install and configure the Eclipse Yocto Project Plug-in into | ||
606 | the Eclipse IDE, you maximize your Yocto Project experience. | ||
607 | Installing and configuring the Plug-in results in an environment that | ||
608 | has extensions specifically designed to let you more easily develop software. | ||
609 | These extensions allow for cross-compilation, deployment, and execution of | ||
610 | your output into a QEMU emulation session. | ||
611 | You can also perform cross-debugging and profiling. | ||
612 | The environment also supports a suite of tools that allows you to perform | ||
613 | remote profiling, tracing, collection of power data, collection of | ||
614 | latency data, and collection of performance data. | ||
615 | </para> | ||
616 | |||
617 | <para> | ||
618 | This section describes how to install and configure the Eclipse IDE | ||
619 | Yocto Plug-in and how to use it to develop your application. | ||
620 | </para> | ||
621 | |||
622 | <section id='setting-up-the-eclipse-ide'> | ||
623 | <title>Setting Up the Eclipse IDE</title> | ||
624 | |||
625 | <para> | ||
626 | To develop within the Eclipse IDE, you need to do the following: | ||
627 | <orderedlist> | ||
628 | <listitem><para>Install the optimal version of the Eclipse IDE.</para></listitem> | ||
629 | <listitem><para>Configure the Eclipse IDE.</para></listitem> | ||
630 | <listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem> | ||
631 | <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem> | ||
632 | </orderedlist> | ||
633 | <note> | ||
634 | Do not install Eclipse from your distribution's package repository. | ||
635 | Be sure to install Eclipse from the official Eclipse download site as directed | ||
636 | in the next section. | ||
637 | </note> | ||
638 | </para> | ||
639 | |||
640 | <section id='installing-eclipse-ide'> | ||
641 | <title>Installing the Eclipse IDE</title> | ||
642 | |||
643 | <para> | ||
644 | It is recommended that you have the Juno 4.2 version of the | ||
645 | Eclipse IDE installed on your development system. | ||
646 | However, if you currently have the Indigo 3.7.2 version installed and you do | ||
647 | not want to upgrade the IDE, you can configure Indigo to work with the | ||
648 | Yocto Project. | ||
649 | See the | ||
650 | "<link linkend='configuring-the-eclipse-ide-indigo'>Configuring the Eclipse IDE (Indigo)</link>" | ||
651 | section. | ||
652 | </para> | ||
653 | |||
654 | <para> | ||
655 | If you don’t have the Juno 4.2 Eclipse IDE installed, you can find the tarball at | ||
656 | <ulink url='&ECLIPSE_MAIN_URL;'></ulink>. | ||
657 | From that site, choose the Eclipse Classic version particular to your development | ||
658 | host. | ||
659 | This version contains the Eclipse Platform, the Java Development | ||
660 | Tools (JDT), and the Plug-in Development Environment. | ||
661 | </para> | ||
662 | |||
663 | <para> | ||
664 | Once you have downloaded the tarball, extract it into a clean | ||
665 | directory. | ||
666 | For example, the following commands unpack and install the | ||
667 | downloaded Eclipse IDE tarball into a clean directory | ||
668 | using the default name <filename>eclipse</filename>: | ||
669 | <literallayout class='monospaced'> | ||
670 | $ cd ~ | ||
671 | $ tar -xzvf ~/Downloads/eclipse-SDK-4.2-linux-gtk-x86_64.tar.gz | ||
672 | </literallayout> | ||
673 | </para> | ||
674 | |||
675 | <para> | ||
676 | If you have the Indigo 3.7.2 Eclipse IDE already installed and you want to use that | ||
677 | version, one issue exists that you need to be aware of regarding the Java | ||
678 | Virtual machine’s garbage collection (GC) process. | ||
679 | The GC process does not clean up the permanent generation | ||
680 | space (PermGen). | ||
681 | This space stores metadata descriptions of classes. | ||
682 | The default value is set too small and it could trigger an | ||
683 | out-of-memory error such as the following: | ||
684 | <literallayout class='monospaced'> | ||
685 | Java.lang.OutOfMemoryError: PermGen space | ||
686 | </literallayout> | ||
687 | </para> | ||
688 | |||
689 | <para> | ||
690 | This error causes the application to hang. | ||
691 | </para> | ||
692 | |||
693 | <para> | ||
694 | To fix this issue, you can use the <filename>--vmargs</filename> | ||
695 | option when you start the Indigo 3.7.2 Eclipse IDE | ||
696 | to increase the size of the permanent generation space: | ||
697 | <literallayout class='monospaced'> | ||
698 | eclipse --vmargs --XX:PermSize=256M | ||
699 | </literallayout> | ||
700 | </para> | ||
701 | </section> | ||
702 | |||
703 | <section id='configuring-the-eclipse-ide-juno'> | ||
704 | <title>Configuring the Eclipse IDE (Juno)</title> | ||
705 | |||
706 | <para> | ||
707 | This section presents the steps needed to configure the Juno 4.2 Eclipse IDE. | ||
708 | If you are using Indigo 3.7.2, see the | ||
709 | "<link linkend='configuring-the-eclipse-ide-indigo'>Configuring the Eclipse IDE (Indigo)</link>". | ||
710 | </para> | ||
711 | |||
712 | <para> | ||
713 | Before installing and configuring the Eclipse Yocto Plug-in, you need to configure | ||
714 | the Juno 4.2 Eclipse IDE. | ||
715 | Follow these general steps: | ||
716 | <orderedlist> | ||
717 | <listitem><para>Start the Eclipse IDE.</para></listitem> | ||
718 | <listitem><para>Make sure you are in your Workbench and select | ||
719 | "Install New Software" from the "Help" pull-down menu. | ||
720 | </para></listitem> | ||
721 | <listitem><para>Select <filename>Juno - &ECLIPSE_JUNO_URL;</filename> | ||
722 | from the "Work with:" pull-down menu.</para></listitem> | ||
723 | <listitem><para>Expand the box next to "Linux Tools" and select the | ||
724 | "LTTng - Linux Tracing Toolkit" boxes.</para></listitem> | ||
725 | <listitem><para>Expand the box next to "Mobile and Device Development" and select the | ||
726 | following boxes: | ||
727 | <itemizedlist> | ||
728 | <listitem><para><filename>C/C++ Remote Launch</filename></para></listitem> | ||
729 | <listitem><para><filename>Remote System Explorer End-user Runtime</filename></para></listitem> | ||
730 | <listitem><para><filename>Remote System Explorer User Actions</filename></para></listitem> | ||
731 | <listitem><para><filename>Target Management Terminal</filename></para></listitem> | ||
732 | <listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem> | ||
733 | <listitem><para><filename>TCF Target Explorer</filename></para></listitem> | ||
734 | </itemizedlist></para></listitem> | ||
735 | <listitem><para>Expand the box next to <filename>Programming Languages</filename> | ||
736 | and select the <filename>Autotools Support for CDT</filename> | ||
737 | and <filename>C/C++ Development Tools</filename> boxes.</para></listitem> | ||
738 | <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem> | ||
739 | </orderedlist> | ||
740 | </para> | ||
741 | </section> | ||
742 | |||
743 | <section id='configuring-the-eclipse-ide-indigo'> | ||
744 | <title>Configuring the Eclipse IDE (Indigo)</title> | ||
745 | |||
746 | <para> | ||
747 | This section presents the steps needed to configure the Indigo 3.7.2 Eclipse IDE. | ||
748 | If you are using Juno 4.2, see the | ||
749 | "<link linkend='configuring-the-eclipse-ide-juno'>Configuring the Eclipse IDE (Juno)</link>". | ||
750 | </para> | ||
751 | |||
752 | <para> | ||
753 | Before installing and configuring the Eclipse Yocto Plug-in, you need to configure | ||
754 | the Indigo 3.7.2 Eclipse IDE. | ||
755 | Follow these general steps: | ||
756 | <orderedlist> | ||
757 | <listitem><para>Start the Eclipse IDE.</para></listitem> | ||
758 | <listitem><para>Make sure you are in your Workbench and select | ||
759 | "Install New Software" from the "Help" pull-down menu. | ||
760 | </para></listitem> | ||
761 | <listitem><para>Select <filename>indigo - &ECLIPSE_INDIGO_URL;</filename> | ||
762 | from the "Work with:" pull-down menu.</para></listitem> | ||
763 | <listitem><para>Expand the box next to <filename>Programming Languages</filename> | ||
764 | and select the <filename>Autotools Support for CDT (incubation)</filename> | ||
765 | and <filename>C/C++ Development Tools</filename> boxes.</para></listitem> | ||
766 | <listitem><para>Expand the box next to "Linux Tools" and select the | ||
767 | "LTTng - Linux Tracing Toolkit(incubation)" boxes.</para></listitem> | ||
768 | <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem> | ||
769 | <listitem><para>After the Eclipse IDE restarts and from the Workbench, select | ||
770 | "Install New Software" from the "Help" pull-down menu.</para></listitem> | ||
771 | <listitem><para>Click the | ||
772 | "Available Software Sites" link.</para></listitem> | ||
773 | <listitem><para>Check the box next to | ||
774 | <filename>&ECLIPSE_UPDATES_URL;</filename> | ||
775 | and click "OK".</para></listitem> | ||
776 | <listitem><para>Select <filename>&ECLIPSE_UPDATES_URL;</filename> | ||
777 | from the "Work with:" pull-down menu.</para></listitem> | ||
778 | <listitem><para>Check the box next to <filename>TM and RSE Main Features</filename>. | ||
779 | </para></listitem> | ||
780 | <listitem><para>Expand the box next to <filename>TM and RSE Optional Add-ons</filename> | ||
781 | and select every item except <filename>RSE Unit Tests</filename> and | ||
782 | <filename>RSE WinCE Services (incubation)</filename>.</para></listitem> | ||
783 | <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem> | ||
784 | <listitem><para>If necessary, select | ||
785 | "Install New Software" from the "Help" pull-down menu so you can click the | ||
786 | "Available Software Sites" link again.</para></listitem> | ||
787 | <listitem><para>After clicking "Available Software Sites", check the box next to | ||
788 | <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename> | ||
789 | and click "OK".</para></listitem> | ||
790 | <listitem><para>Select <filename>&ECLIPSE_INDIGO_CDT_URL;</filename> | ||
791 | from the "Work with:" pull-down menu.</para></listitem> | ||
792 | <listitem><para>Check the box next to <filename>CDT Main Features</filename>. | ||
793 | </para></listitem> | ||
794 | <listitem><para>Expand the box next to <filename>CDT Optional Features</filename> | ||
795 | and select <filename>C/C++ Remote Launch</filename> and | ||
796 | <filename>Target Communication Framework (incubation)</filename>.</para></listitem> | ||
797 | <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem> | ||
798 | </orderedlist> | ||
799 | </para> | ||
800 | </section> | ||
801 | |||
802 | <section id='installing-the-eclipse-yocto-plug-in'> | ||
803 | <title>Installing or Accessing the Eclipse Yocto Plug-in</title> | ||
804 | |||
805 | <para> | ||
806 | You can install the Eclipse Yocto Plug-in into the Eclipse IDE | ||
807 | one of two ways: use the Yocto Project's Eclipse Update site to install the pre-built plug-in, | ||
808 | or build and install the plug-in from the latest source code. | ||
809 | If you don't want to permanently install the plug-in but just want to try it out | ||
810 | within the Eclipse environment, you can import the plug-in project from the | ||
811 | Yocto Project's Source Repositories. | ||
812 | </para> | ||
813 | |||
814 | <section id='new-software'> | ||
815 | <title>Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site</title> | ||
816 | |||
817 | <para> | ||
818 | To install the Eclipse Yocto Plug-in from the update site, | ||
819 | follow these steps: | ||
820 | <orderedlist> | ||
821 | <listitem><para>Start up the Eclipse IDE.</para></listitem> | ||
822 | <listitem><para>In Eclipse, select "Install New Software" from the "Help" menu.</para></listitem> | ||
823 | <listitem><para>Click "Add..." in the "Work with:" area.</para></listitem> | ||
824 | <listitem><para>Enter | ||
825 | <filename>&ECLIPSE_DL_PLUGIN_URL;</filename> | ||
826 | in the URL field and provide a meaningful name in the "Name" field.</para></listitem> | ||
827 | <listitem><para>Click "OK" to have the entry added to the "Work with:" | ||
828 | drop-down list.</para></listitem> | ||
829 | <listitem><para>Select the entry for the plug-in from the "Work with:" drop-down | ||
830 | list.</para></listitem> | ||
831 | <listitem><para>Check the box next to <filename>Development tools and SDKs for Yocto Linux</filename>. | ||
832 | </para></listitem> | ||
833 | <listitem><para>Complete the remaining software installation steps and | ||
834 | then restart the Eclipse IDE to finish the installation of the plug-in. | ||
835 | </para></listitem> | ||
836 | </orderedlist> | ||
837 | </para> | ||
838 | </section> | ||
839 | |||
840 | <section id='zip-file-method'> | ||
841 | <title>Installing the Plug-in Using the Latest Source Code</title> | ||
842 | |||
843 | <para> | ||
844 | To install the Eclipse Yocto Plug-in from the latest source code, follow these steps: | ||
845 | <orderedlist> | ||
846 | <listitem><para>Open a shell and create a Git repository with: | ||
847 | <literallayout class='monospaced'> | ||
848 | $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse | ||
849 | </literallayout> | ||
850 | For this example, the repository is named | ||
851 | <filename>~/yocto-eclipse</filename>.</para></listitem> | ||
852 | <listitem><para>Change to the directory where you set up | ||
853 | the Git repository: | ||
854 | <literallayout class='monospaced'> | ||
855 | $ cd ~/yocto-eclipse | ||
856 | </literallayout></para></listitem> | ||
857 | <listitem><para>Be sure you are in the right branch for your Git repository. | ||
858 | For this release set the branch to <filename>&DISTRO_NAME;</filename>: | ||
859 | <literallayout class='monospaced'> | ||
860 | $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; | ||
861 | </literallayout></para></listitem> | ||
862 | <listitem><para>Change to the <filename>scripts</filename> | ||
863 | directory within the Git repository: | ||
864 | <literallayout class='monospaced'> | ||
865 | $ cd scripts | ||
866 | </literallayout></para></listitem> | ||
867 | <listitem><para>Set up the local build environment by running the | ||
868 | setup script: | ||
869 | <literallayout class='monospaced'> | ||
870 | $ ./setup.sh | ||
871 | </literallayout></para></listitem> | ||
872 | <listitem><para>When the script finishes execution, it prompts | ||
873 | you with instructions on how to run the | ||
874 | <filename>build.sh</filename> script, which is also in | ||
875 | the <filename>scripts</filename> of the | ||
876 | Git repository created earlier. | ||
877 | </para></listitem> | ||
878 | <listitem><para>Run the <filename>build.sh</filename> script | ||
879 | as directed. | ||
880 | Be sure to provide the name of the Git branch along with the | ||
881 | Yocto Project release you are using. | ||
882 | Here is an example that uses the <filename>&DISTRO_NAME;</filename> branches: | ||
883 | <literallayout class='monospaced'> | ||
884 | $ ECLIPSE_HOME=/home/scottrif/yocto-eclipse/scripts/eclipse ./build.sh &DISTRO_NAME; &DISTRO_NAME; | ||
885 | </literallayout> | ||
886 | After running the script, the file | ||
887 | <filename>org.yocto.sdk-<release>-<date>-archive.zip</filename> | ||
888 | is in the current directory.</para></listitem> | ||
889 | <listitem><para>If necessary, start the Eclipse IDE and be sure you are in the | ||
890 | Workbench.</para></listitem> | ||
891 | <listitem><para>Select "Install New Software" from the "Help" pull-down menu. | ||
892 | </para></listitem> | ||
893 | <listitem><para>Click "Add".</para></listitem> | ||
894 | <listitem><para>Provide anything you want in the "Name" field.</para></listitem> | ||
895 | <listitem><para>Click "Archive" and browse to the ZIP file you built | ||
896 | in step seven. | ||
897 | This ZIP file should not be "unzipped", and must be the | ||
898 | <filename>*archive.zip</filename> file created by running the | ||
899 | <filename>build.sh</filename> script.</para></listitem> | ||
900 | <listitem><para>Click through the "Okay" buttons.</para></listitem> | ||
901 | <listitem><para>Check the box next to the new entry in the installation window and complete | ||
902 | the installation.</para></listitem> | ||
903 | <listitem><para>Restart the Eclipse IDE if necessary.</para></listitem> | ||
904 | </orderedlist> | ||
905 | </para> | ||
906 | |||
907 | <para> | ||
908 | At this point you should be able to configure the Eclipse Yocto Plug-in as described in the | ||
909 | "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>" | ||
910 | section.</para> | ||
911 | </section> | ||
912 | |||
913 | <section id='yocto-project-source'> | ||
914 | <title>Importing the Plug-in Project into the Eclipse Environment</title> | ||
915 | |||
916 | <para> | ||
917 | Importing the Eclipse Yocto Plug-in project from the Yocto Project source repositories | ||
918 | is useful when you want to try out the latest plug-in from the tip of plug-in's | ||
919 | development tree. | ||
920 | It is important to understand when you import the plug-in you are not installing | ||
921 | it into the Eclipse application. | ||
922 | Rather, you are importing the project and just using it. | ||
923 | To import the plug-in project, follow these steps: | ||
924 | <orderedlist> | ||
925 | <listitem><para>Open a shell and create a Git repository with: | ||
926 | <literallayout class='monospaced'> | ||
927 | $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse | ||
928 | </literallayout> | ||
929 | For this example, the repository is named | ||
930 | <filename>~/yocto-eclipse</filename>.</para></listitem> | ||
931 | <listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem> | ||
932 | <listitem><para>Expand the "General" box and select "existing projects into workspace" | ||
933 | and then click "Next".</para></listitem> | ||
934 | <listitem><para>Select the root directory and browse to | ||
935 | <filename>~/yocto-eclipse/plugins</filename>.</para></listitem> | ||
936 | <listitem><para>Three plug-ins exist: "org.yocto.bc.ui", "org.yocto.sdk.ide", and | ||
937 | "org.yocto.sdk.remotetools". | ||
938 | Select and import all of them.</para></listitem> | ||
939 | </orderedlist> | ||
940 | </para> | ||
941 | |||
942 | <para> | ||
943 | The left navigation pane in the Eclipse application shows the default projects. | ||
944 | Right-click on one of these projects and run it as an Eclipse application. | ||
945 | This brings up a second instance of Eclipse IDE that has the Yocto Plug-in. | ||
946 | </para> | ||
947 | </section> | ||
948 | </section> | ||
949 | |||
950 | <section id='configuring-the-eclipse-yocto-plug-in'> | ||
951 | <title>Configuring the Eclipse Yocto Plug-in</title> | ||
952 | |||
953 | <para> | ||
954 | Configuring the Eclipse Yocto Plug-in involves setting the Cross | ||
955 | Compiler options and the Target options. | ||
956 | The configurations you choose become the default settings for all projects. | ||
957 | You do have opportunities to change them later when | ||
958 | you configure the project (see the following section). | ||
959 | </para> | ||
960 | |||
961 | <para> | ||
962 | To start, you need to do the following from within the Eclipse IDE: | ||
963 | <itemizedlist> | ||
964 | <listitem><para>Choose <filename>Windows -> Preferences</filename> to display | ||
965 | the <filename>Preferences</filename> Dialog</para></listitem> | ||
966 | <listitem><para>Click <filename>Yocto Project ADT</filename></para></listitem> | ||
967 | </itemizedlist> | ||
968 | </para> | ||
969 | |||
970 | <section id='configuring-the-cross-compiler-options'> | ||
971 | <title>Configuring the Cross-Compiler Options</title> | ||
972 | |||
973 | <para> | ||
974 | To configure the Cross Compiler Options, you must select the type of toolchain, | ||
975 | point to the toolchain, specify the sysroot location, and select the target architecture. | ||
976 | <itemizedlist> | ||
977 | <listitem><para><emphasis>Selecting the Toolchain Type:</emphasis> | ||
978 | Choose between <filename>Standalone pre-built toolchain</filename> | ||
979 | and <filename>Build system derived toolchain</filename> for Cross | ||
980 | Compiler Options. | ||
981 | <itemizedlist> | ||
982 | <listitem><para><emphasis> | ||
983 | <filename>Standalone Pre-built Toolchain:</filename></emphasis> | ||
984 | Select this mode when you are using a stand-alone cross-toolchain. | ||
985 | For example, suppose you are an application developer and do not | ||
986 | need to build a target image. | ||
987 | Instead, you just want to use an architecture-specific toolchain on an | ||
988 | existing kernel and target root filesystem. | ||
989 | </para></listitem> | ||
990 | <listitem><para><emphasis> | ||
991 | <filename>Build System Derived Toolchain:</filename></emphasis> | ||
992 | Select this mode if the cross-toolchain has been installed and built | ||
993 | as part of the Build Directory. | ||
994 | When you select <filename>Build system derived toolchain</filename>, | ||
995 | you are using the toolchain bundled | ||
996 | inside the Build Directory. | ||
997 | </para></listitem> | ||
998 | </itemizedlist> | ||
999 | </para></listitem> | ||
1000 | <listitem><para><emphasis>Point to the Toolchain:</emphasis> | ||
1001 | If you are using a stand-alone pre-built toolchain, you should be pointing to the | ||
1002 | <filename>&YOCTO_ADTPATH_DIR;</filename> directory. | ||
1003 | This is the location for toolchains installed by the ADT Installer or by hand. | ||
1004 | Sections "<ulink url='&YOCTO_DOCS_ADT_URL;#configuring-and-running-the-adt-installer-script'>Configuring | ||
1005 | and Running the ADT Installer Script</ulink>" and | ||
1006 | "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" | ||
1007 | in the Yocto Project Application Developer's Guide | ||
1008 | describe two ways to install a stand-alone cross-toolchain in the | ||
1009 | <filename>/opt/poky</filename> directory. | ||
1010 | <note>It is possible to install a stand-alone cross-toolchain in a directory | ||
1011 | other than <filename>/opt/poky</filename>. | ||
1012 | However, doing so is discouraged.</note></para> | ||
1013 | <para>If you are using a system-derived toolchain, the path you provide | ||
1014 | for the <filename>Toolchain Root Location</filename> | ||
1015 | field is the Build Directory. | ||
1016 | See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using | ||
1017 | BitBake and the Build Directory</ulink>" section in the Yocto Project Application | ||
1018 | Developer's Guide for information on how to install the toolchain into the build | ||
1019 | directory.</para></listitem> | ||
1020 | <listitem><para><emphasis>Specify the Sysroot Location:</emphasis> | ||
1021 | This location is where the root filesystem for the target hardware resides. | ||
1022 | If you used the ADT Installer, then the location is | ||
1023 | <filename>/opt/poky/<release></filename>. | ||
1024 | Additionally, when you use the ADT Installer, the same location is used for | ||
1025 | the QEMU user-space tools and the NFS boot process.</para> | ||
1026 | <para>If you used either of the other two methods to install the toolchain, then the | ||
1027 | location of the sysroot filesystem depends on where you separately | ||
1028 | extracted and intalled the filesystem.</para> | ||
1029 | <para>For information on how to install the toolchain and on how to extract | ||
1030 | and install the sysroot filesystem, see the | ||
1031 | "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>" section. | ||
1032 | </para></listitem> | ||
1033 | <listitem><para><emphasis>Select the Target Architecture:</emphasis> | ||
1034 | The target architecture is the type of hardware you are | ||
1035 | going to use or emulate. | ||
1036 | Use the pull-down <filename>Target Architecture</filename> menu to make | ||
1037 | your selection. | ||
1038 | The pull-down menu should have the supported architectures. | ||
1039 | If the architecture you need is not listed in the menu, you | ||
1040 | will need to build the image. | ||
1041 | See the "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section | ||
1042 | of the Yocto Project Quick Start for more information.</para></listitem> | ||
1043 | </itemizedlist> | ||
1044 | </para> | ||
1045 | </section> | ||
1046 | |||
1047 | <section id='configuring-the-target-options'> | ||
1048 | <title>Configuring the Target Options</title> | ||
1049 | |||
1050 | <para> | ||
1051 | You can choose to emulate hardware using the QEMU emulator, or you | ||
1052 | can choose to run your image on actual hardware. | ||
1053 | <itemizedlist> | ||
1054 | <listitem><para><emphasis><filename>QEMU:</filename></emphasis> Select this option if | ||
1055 | you will be using the QEMU emulator. | ||
1056 | If you are using the emulator, you also need to locate the kernel | ||
1057 | and specify any custom options.</para> | ||
1058 | <para>If you selected <filename>Build system derived toolchain</filename>, | ||
1059 | the target kernel you built will be located in the | ||
1060 | Build Directory in <filename>tmp/deploy/images</filename> directory. | ||
1061 | If you selected <filename>Standalone pre-built toolchain</filename>, the | ||
1062 | pre-built image you downloaded is located | ||
1063 | in the directory you specified when you downloaded the image.</para> | ||
1064 | <para>Most custom options are for advanced QEMU users to further | ||
1065 | customize their QEMU instance. | ||
1066 | These options are specified between paired angled brackets. | ||
1067 | Some options must be specified outside the brackets. | ||
1068 | In particular, the options <filename>serial</filename>, | ||
1069 | <filename>nographic</filename>, and <filename>kvm</filename> must all | ||
1070 | be outside the brackets. | ||
1071 | Use the <filename>man qemu</filename> command to get help on all the options | ||
1072 | and their use. | ||
1073 | The following is an example: | ||
1074 | <literallayout class='monospaced'> | ||
1075 | serial ‘<-m 256 -full-screen>’ | ||
1076 | </literallayout></para> | ||
1077 | <para> | ||
1078 | Regardless of the mode, Sysroot is already defined as part of the | ||
1079 | Cross Compiler Options configuration in the | ||
1080 | <filename>Sysroot Location:</filename> field.</para></listitem> | ||
1081 | <listitem><para><emphasis><filename>External HW:</filename></emphasis> Select this option | ||
1082 | if you will be using actual hardware.</para></listitem> | ||
1083 | </itemizedlist> | ||
1084 | </para> | ||
1085 | |||
1086 | <para> | ||
1087 | Click the <filename>OK</filename> button to save your plug-in configurations. | ||
1088 | </para> | ||
1089 | </section> | ||
1090 | </section> | ||
1091 | </section> | ||
1092 | |||
1093 | <section id='creating-the-project'> | ||
1094 | <title>Creating the Project</title> | ||
1095 | |||
1096 | <para> | ||
1097 | You can create two types of projects: Autotools-based, or Makefile-based. | ||
1098 | This section describes how to create Autotools-based projects from within | ||
1099 | the Eclipse IDE. | ||
1100 | For information on creating Makefile-based projects in a terminal window, see the section | ||
1101 | "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-command-line'>Using the Command Line</ulink>" | ||
1102 | in the Yocto Project Application Developer's Guide. | ||
1103 | </para> | ||
1104 | |||
1105 | <para> | ||
1106 | To create a project based on a Yocto template and then display the source code, | ||
1107 | follow these steps: | ||
1108 | <orderedlist> | ||
1109 | <listitem><para>Select <filename>File -> New -> Project</filename>.</para></listitem> | ||
1110 | <listitem><para>Double click <filename>CC++</filename>.</para></listitem> | ||
1111 | <listitem><para>Double click <filename>C Project</filename> to create the project.</para></listitem> | ||
1112 | <listitem><para>Expand <filename>Yocto Project ADT Project</filename>.</para></listitem> | ||
1113 | <listitem><para>Select <filename>Hello World ANSI C Autotools Project</filename>. | ||
1114 | This is an Autotools-based project based on a Yocto template.</para></listitem> | ||
1115 | <listitem><para>Put a name in the <filename>Project name:</filename> field. | ||
1116 | Do not use hyphens as part of the name.</para></listitem> | ||
1117 | <listitem><para>Click <filename>Next</filename>.</para></listitem> | ||
1118 | <listitem><para>Add information in the <filename>Author</filename> and | ||
1119 | <filename>Copyright notice</filename> fields.</para></listitem> | ||
1120 | <listitem><para>Be sure the <filename>License</filename> field is correct.</para></listitem> | ||
1121 | <listitem><para>Click <filename>Finish</filename>.</para></listitem> | ||
1122 | <listitem><para>If the "open perspective" prompt appears, click "Yes" so that you | ||
1123 | in the C/C++ perspective.</para></listitem> | ||
1124 | <listitem><para>The left-hand navigation pane shows your project. | ||
1125 | You can display your source by double clicking the project's source file. | ||
1126 | </para></listitem> | ||
1127 | </orderedlist> | ||
1128 | </para> | ||
1129 | </section> | ||
1130 | |||
1131 | <section id='configuring-the-cross-toolchains'> | ||
1132 | <title>Configuring the Cross-Toolchains</title> | ||
1133 | |||
1134 | <para> | ||
1135 | The earlier section, "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring | ||
1136 | the Eclipse Yocto Plug-in</link>", sets up the default project | ||
1137 | configurations. | ||
1138 | You can override these settings for a given project by following these steps: | ||
1139 | <orderedlist> | ||
1140 | <listitem><para>Select <filename>Project -> Change Yocto Project Settings</filename>: | ||
1141 | This selection brings up the <filename>Yocot Project Settings</filename> Dialog | ||
1142 | and allows you to make changes specific to an individual project. | ||
1143 | </para> | ||
1144 | <para>By default, the Cross Compiler Options and Target Options for a project | ||
1145 | are inherited from settings you provide using the <filename>Preferences</filename> | ||
1146 | Dialog as described earlier | ||
1147 | in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse | ||
1148 | Yocto Plug-in</link>" section. | ||
1149 | The <filename>Yocto Project Settings</filename> | ||
1150 | Dialog allows you to override those default settings | ||
1151 | for a given project.</para></listitem> | ||
1152 | <listitem><para>Make your configurations for the project and click "OK". | ||
1153 | If you are running the Juno version of Eclipse, you can skip down to the next | ||
1154 | section where you build the project. | ||
1155 | If you are not working with Juno, you need to reconfigure the project as | ||
1156 | described in the next step.</para></listitem> | ||
1157 | <listitem><para>Select <filename>Project -> Reconfigure Project</filename>: | ||
1158 | This selection reconfigures the project by running | ||
1159 | <filename>autogen.sh</filename> in the workspace for your project. | ||
1160 | The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>, | ||
1161 | <filename>autoconf</filename>, <filename>autoheader</filename>, | ||
1162 | <filename>automake --a</filename>, and | ||
1163 | <filename>./configure</filename>. | ||
1164 | Click on the <filename>Console</filename> tab beneath your source code to | ||
1165 | see the results of reconfiguring your project.</para></listitem> | ||
1166 | </orderedlist> | ||
1167 | </para> | ||
1168 | </section> | ||
1169 | |||
1170 | <section id='building-the-project'> | ||
1171 | <title>Building the Project</title> | ||
1172 | |||
1173 | <para> | ||
1174 | To build the project in Juno, right click on the project in the navigator pane and select | ||
1175 | <filename>Build Project</filename>. | ||
1176 | If you are not running Juno, select <filename>Project -> Build Project</filename>. | ||
1177 | The console should update and you can note the cross-compiler you are using. | ||
1178 | </para> | ||
1179 | </section> | ||
1180 | |||
1181 | <section id='starting-qemu-in-user-space-nfs-mode'> | ||
1182 | <title>Starting QEMU in User Space NFS Mode</title> | ||
1183 | |||
1184 | <para> | ||
1185 | To start the QEMU emulator from within Eclipse, follow these steps: | ||
1186 | <orderedlist> | ||
1187 | <listitem><para>Expose the <filename>Run -> External Tools</filename> menu. | ||
1188 | Your image should appear as a selectable menu item. | ||
1189 | </para></listitem> | ||
1190 | <listitem><para>Select your image from the menu to launch the | ||
1191 | emulator in a new window.</para></listitem> | ||
1192 | <listitem><para>If needed, enter your host root password in the shell window at the prompt. | ||
1193 | This sets up a <filename>Tap 0</filename> connection needed for running in user-space | ||
1194 | NFS mode.</para></listitem> | ||
1195 | <listitem><para>Wait for QEMU to launch.</para></listitem> | ||
1196 | <listitem><para>Once QEMU launches, you can begin operating within that | ||
1197 | environment. | ||
1198 | For example, you could determine the IP Address | ||
1199 | for the user-space NFS by using the <filename>ifconfig</filename> command. | ||
1200 | </para></listitem> | ||
1201 | </orderedlist> | ||
1202 | </para> | ||
1203 | </section> | ||
1204 | |||
1205 | <section id='deploying-and-debugging-the-application'> | ||
1206 | <title>Deploying and Debugging the Application</title> | ||
1207 | |||
1208 | <para> | ||
1209 | Once the QEMU emulator is running the image, using the Eclipse IDE | ||
1210 | you can deploy your application and use the emulator to perform debugging. | ||
1211 | Follow these steps to deploy the application. | ||
1212 | <orderedlist> | ||
1213 | <listitem><para>Select <filename>Run -> Debug Configurations...</filename></para></listitem> | ||
1214 | <listitem><para>In the left area, expand <filename>C/C++Remote Application</filename>.</para></listitem> | ||
1215 | <listitem><para>Locate your project and select it to bring up a new | ||
1216 | tabbed view in the <filename>Debug Configurations</filename> Dialog.</para></listitem> | ||
1217 | <listitem><para>Enter the absolute path into which you want to deploy | ||
1218 | the application. | ||
1219 | Use the <filename>Remote Absolute File Path for C/C++Application:</filename> field. | ||
1220 | For example, enter <filename>/usr/bin/<programname></filename>.</para></listitem> | ||
1221 | <listitem><para>Click on the <filename>Debugger</filename> tab to see the cross-tool debugger | ||
1222 | you are using.</para></listitem> | ||
1223 | <listitem><para>Click on the <filename>Main</filename> tab.</para></listitem> | ||
1224 | <listitem><para>Create a new connection to the QEMU instance | ||
1225 | by clicking on <filename>new</filename>.</para></listitem> | ||
1226 | <listitem><para>Select <filename>TCF</filename>, which means Target Communication | ||
1227 | Framework.</para></listitem> | ||
1228 | <listitem><para>Click <filename>Next</filename>.</para></listitem> | ||
1229 | <listitem><para>Clear out the <filename>host name</filename> field and enter the IP Address | ||
1230 | determined earlier.</para></listitem> | ||
1231 | <listitem><para>Click <filename>Finish</filename> to close the | ||
1232 | <filename>New Connections</filename> Dialog.</para></listitem> | ||
1233 | <listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick | ||
1234 | the IP Address you entered.</para></listitem> | ||
1235 | <listitem><para>Click <filename>Run</filename> to bring up a login screen | ||
1236 | and login.</para></listitem> | ||
1237 | <listitem><para>Accept the debug perspective.</para></listitem> | ||
1238 | </orderedlist> | ||
1239 | </para> | ||
1240 | </section> | ||
1241 | |||
1242 | <section id='running-user-space-tools'> | ||
1243 | <title>Running User-Space Tools</title> | ||
1244 | |||
1245 | <para> | ||
1246 | As mentioned earlier in the manual, several tools exist that enhance | ||
1247 | your development experience. | ||
1248 | These tools are aids in developing and debugging applications and images. | ||
1249 | You can run these user-space tools from within the Eclipse IDE through the | ||
1250 | <filename>YoctoTools</filename> menu. | ||
1251 | </para> | ||
1252 | |||
1253 | <para> | ||
1254 | Once you pick a tool, you need to configure it for the remote target. | ||
1255 | Every tool needs to have the connection configured. | ||
1256 | You must select an existing TCF-based RSE connection to the remote target. | ||
1257 | If one does not exist, click <filename>New</filename> to create one. | ||
1258 | </para> | ||
1259 | |||
1260 | <para> | ||
1261 | Here are some specifics about the remote tools: | ||
1262 | <itemizedlist> | ||
1263 | <listitem><para><emphasis><filename>OProfile</filename>:</emphasis> Selecting this tool causes | ||
1264 | the <filename>oprofile-server</filename> on the remote target to launch on | ||
1265 | the local host machine. | ||
1266 | The <filename>oprofile-viewer</filename> must be installed on the local host machine and the | ||
1267 | <filename>oprofile-server</filename> must be installed on the remote target, | ||
1268 | respectively, in order to use. | ||
1269 | You must compile and install the <filename>oprofile-viewer</filename> from the source code | ||
1270 | on your local host machine. | ||
1271 | Furthermore, in order to convert the target's sample format data into a form that the | ||
1272 | host can use, you must have <filename>oprofile</filename> version 0.9.4 or | ||
1273 | greater installed on the host.</para> | ||
1274 | <para>You can locate both the viewer and server from | ||
1275 | <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>. | ||
1276 | <note>The <filename>oprofile-server</filename> is installed by default on | ||
1277 | the <filename>core-image-sato-sdk</filename> image.</note></para></listitem> | ||
1278 | <listitem><para><emphasis><filename>Lttng2.0 ust trace import</filename>:</emphasis> | ||
1279 | Selecting this tool transfers the remote target's | ||
1280 | <filename>Lttng</filename> tracing data back to the local host machine | ||
1281 | and uses the <filename>Lttng</filename> Eclipse plug-in to graphically | ||
1282 | display the output. | ||
1283 | For information on how to use <filename>Lttng</filename> to trace an application, | ||
1284 | see <ulink url='http://lttng.org/documentation'></ulink>. | ||
1285 | <note>Do not use <filename>Lttng-user space (legacy)</filename> tool. | ||
1286 | This tool no longer has any upstream support.</note> | ||
1287 | </para> | ||
1288 | <para>Before you use the <filename>Lttng2.0 ust trace import</filename> tool, | ||
1289 | you need to setup the <filename>Lttng</filename> Eclipse plug-in and create a | ||
1290 | <filename>Tracing</filename> project. | ||
1291 | Do the following: | ||
1292 | <orderedlist> | ||
1293 | <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename> | ||
1294 | and then select <filename>Tracing</filename>.</para></listitem> | ||
1295 | <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective | ||
1296 | into the <filename>Tracing</filename> perspective.</para></listitem> | ||
1297 | <listitem><para>Create a new <filename>Tracing</filename> project by selecting | ||
1298 | <filename>File -> New -> Project</filename>.</para></listitem> | ||
1299 | <listitem><para>Choose <filename>Tracing -> Tracing Project</filename>. | ||
1300 | </para></listitem> | ||
1301 | <listitem><para>Generate your tracing data on the remote target. | ||
1302 | </para></listitem> | ||
1303 | <listitem><para>Click | ||
1304 | <filename>Yocto Project Tools -> Lttng2.0 ust trace import</filename> | ||
1305 | to start the data import process.</para></listitem> | ||
1306 | <listitem><para>Specify your remote connection name.</para></listitem> | ||
1307 | <listitem><para>For the Ust directory path, specify the location of | ||
1308 | your remote tracing data. | ||
1309 | Make sure the location ends with <filename>ust</filename> (e.g. | ||
1310 | <filename>/usr/mysession/ust</filename>.</para></listitem> | ||
1311 | <listitem><para>Click <filename>OK</filename> to complete the import process. | ||
1312 | The data is now in the local tracing project you created.</para></listitem> | ||
1313 | <listitem><para>Right click on the data and then use the menu to | ||
1314 | <filename>Select Trace Type... -> Common Trace Format -> Generic CTF Trace</filename> | ||
1315 | to map the tracing type.</para></listitem> | ||
1316 | <listitem><para>Right click the mouse and select <filename>Open</filename> | ||
1317 | to bring up the Eclipse <filename>Lttng</filename> Trace Viewer so you | ||
1318 | view the tracing data.</para></listitem> | ||
1319 | </orderedlist></para></listitem> | ||
1320 | <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis> Selecting this tool runs | ||
1321 | <filename>powertop</filename> on the remote target machine and displays the results in a | ||
1322 | new view called <filename>powertop</filename>.</para> | ||
1323 | <para><filename>Time to gather data(sec):</filename> is the time passed in seconds before data | ||
1324 | is gathered from the remote target for analysis.</para> | ||
1325 | <para><filename>show pids in wakeups list:</filename> corresponds to the | ||
1326 | <filename>-p</filename> argument | ||
1327 | passed to <filename>powertop</filename>.</para></listitem> | ||
1328 | <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis> | ||
1329 | <filename>latencytop</filename> identifies system latency, while | ||
1330 | <filename>perf</filename> monitors the system's | ||
1331 | performance counter registers. | ||
1332 | Selecting either of these tools causes an RSE terminal view to appear | ||
1333 | from which you can run the tools. | ||
1334 | Both tools refresh the entire screen to display results while they run.</para></listitem> | ||
1335 | </itemizedlist> | ||
1336 | </para> | ||
1337 | </section> | ||
1338 | |||
1339 | <section id='customizing-an-image-using-a-bitbake-commander-project-and-hob'> | ||
1340 | <title>Customizing an Image Using a BitBake Commander Project and Hob</title> | ||
1341 | |||
1342 | <para> | ||
1343 | Within Eclipse, you can create a Yocto BitBake Commander project, | ||
1344 | edit the metadata, and then use the | ||
1345 | <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build a customized | ||
1346 | image all within one IDE. | ||
1347 | </para> | ||
1348 | |||
1349 | <section id='creating-the-yocto-bitbake-commander-project'> | ||
1350 | <title>Creating the Yocto BitBake Commander Project</title> | ||
1351 | |||
1352 | <para> | ||
1353 | To create a Yocto BitBake Commander project, follow these steps: | ||
1354 | <orderedlist> | ||
1355 | <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename> | ||
1356 | and then choose <filename>Bitbake Commander</filename>.</para></listitem> | ||
1357 | <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective into the | ||
1358 | Bitbake Commander perspective.</para></listitem> | ||
1359 | <listitem><para>Select <filename>File -> New -> Project</filename> to create a new Yocto | ||
1360 | Bitbake Commander project.</para></listitem> | ||
1361 | <listitem><para>Choose <filename>Yocto Project Bitbake Commander -> New Yocto Project</filename> | ||
1362 | and click <filename>Next</filename>.</para></listitem> | ||
1363 | <listitem><para>Enter the Project Name and choose the Project Location. | ||
1364 | The Yocto project's metadata files will be put under the directory | ||
1365 | <filename><project_location>/<project_name></filename>. | ||
1366 | If that directory does not exist, you need to check | ||
1367 | the "Clone from Yocto Git Repository" box, which would execute a | ||
1368 | <filename>git clone</filename> command to get the project's metadata files. | ||
1369 | </para></listitem> | ||
1370 | <listitem><para>Select <filename>Finish</filename> to create the project.</para></listitem> | ||
1371 | </orderedlist> | ||
1372 | </para> | ||
1373 | </section> | ||
1374 | |||
1375 | <section id='editing-the-metadata-files'> | ||
1376 | <title>Editing the Metadata Files</title> | ||
1377 | |||
1378 | <para> | ||
1379 | After you create the Yocto Bitbake Commander project, you can modify the metadata files | ||
1380 | by opening them in the project. | ||
1381 | When editing recipe files (<filename>.bb</filename> files), you can view BitBake | ||
1382 | variable values and information by hovering the mouse pointer over the variable name and | ||
1383 | waiting a few seconds. | ||
1384 | </para> | ||
1385 | |||
1386 | <para> | ||
1387 | To edit the metadata, follow these steps: | ||
1388 | <orderedlist> | ||
1389 | <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem> | ||
1390 | <listitem><para>Select <filename>File -> New -> Yocto BitBake Commander -> BitBake Recipe</filename> | ||
1391 | to open a new recipe wizard.</para></listitem> | ||
1392 | <listitem><para>Point to your source by filling in the "SRC_URL" field. | ||
1393 | For example, you can add a recipe to your | ||
1394 | <link linkend='source-directory'>Source Directory</link> | ||
1395 | by defining "SRC_URL" as follows: | ||
1396 | <literallayout class='monospaced'> | ||
1397 | ftp://ftp.gnu.org/gnu/m4/m4-1.4.9.tar.gz | ||
1398 | </literallayout></para></listitem> | ||
1399 | <listitem><para>Click "Populate" to calculate the archive md5, sha256, | ||
1400 | license checksum values and to auto-generate the recipe filename.</para></listitem> | ||
1401 | <listitem><para>Fill in the "Description" field.</para></listitem> | ||
1402 | <listitem><para>Be sure values for all required fields exist.</para></listitem> | ||
1403 | <listitem><para>Click <filename>Finish</filename>.</para></listitem> | ||
1404 | </orderedlist> | ||
1405 | </para> | ||
1406 | </section> | ||
1407 | |||
1408 | <section id='buiding-and-customizing-the-image'> | ||
1409 | <title>Building and Customizing the Image</title> | ||
1410 | |||
1411 | <para> | ||
1412 | To build and customize the image in Eclipse, follow these steps: | ||
1413 | <orderedlist> | ||
1414 | <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem> | ||
1415 | <listitem><para>Select <filename>Project -> Launch HOB</filename>.</para></listitem> | ||
1416 | <listitem><para>Enter the Build Directory where you want to put your final images.</para></listitem> | ||
1417 | <listitem><para>Click <filename>OK</filename> to launch Hob.</para></listitem> | ||
1418 | <listitem><para>Use Hob to customize and build your own images. | ||
1419 | For information on Hob, see the | ||
1420 | <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob Project Page</ulink> on the | ||
1421 | Yocto Project website.</para></listitem> | ||
1422 | </orderedlist> | ||
1423 | </para> | ||
1424 | </section> | ||
1425 | </section> | ||
1426 | </section> | ||
1427 | |||
1428 | <section id='workflow-using-stand-alone-cross-development-toolchains'> | ||
1429 | <title>Workflow Using Stand-alone Cross-development Toolchains</title> | ||
1430 | |||
1431 | <para> | ||
1432 | If you want to develop an application without prior installation of the ADT, you | ||
1433 | still can employ the cross-development toolchain, the QEMU emulator, and a number of supported | ||
1434 | target image files. | ||
1435 | You just need to follow these general steps: | ||
1436 | <orderedlist> | ||
1437 | <listitem><para><emphasis>Install the cross-development toolchain for your target hardware:</emphasis> | ||
1438 | For information on how to install the toolchain, see the | ||
1439 | "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" | ||
1440 | section | ||
1441 | in the Yocto Project Application Developer's Guide.</para></listitem> | ||
1442 | <listitem><para><emphasis>Download the Target Image:</emphasis> The Yocto Project supports | ||
1443 | several target architectures and has many pre-built kernel images and root filesystem | ||
1444 | images.</para> | ||
1445 | <para>If you are going to develop your application on hardware, go to the | ||
1446 | <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink> | ||
1447 | download area and choose a target machine area | ||
1448 | from which to download the kernel image and root filesystem. | ||
1449 | This download area could have several files in it that support development using | ||
1450 | actual hardware. | ||
1451 | For example, the area might contain <filename>.hddimg</filename> files that combine the | ||
1452 | kernel image with the filesystem, boot loaders, etc. | ||
1453 | Be sure to get the files you need for your particular development process.</para> | ||
1454 | <para>If you are going to develop your application and then run and test it using the QEMU | ||
1455 | emulator, go to the | ||
1456 | <ulink url='&YOCTO_QEMU_DL_URL;'><filename>machines/qemu</filename></ulink> | ||
1457 | download area. | ||
1458 | From this area, go down into the directory for your target architecture | ||
1459 | (e.g. <filename>qemux86_64</filename> for an | ||
1460 | <trademark class='registered'>Intel</trademark>-based 64-bit architecture). | ||
1461 | Download kernel, root filesystem, and any other files you need for your process. | ||
1462 | <note>In order to use the root filesystem in QEMU, you need to extract it. | ||
1463 | See the | ||
1464 | "<ulink url='&YOCTO_DOCS_ADT_URL;#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" | ||
1465 | section for information on how to extract the root filesystem.</note></para></listitem> | ||
1466 | <listitem><para><emphasis>Develop and Test your Application:</emphasis> At this point, | ||
1467 | you have the tools to develop your application. | ||
1468 | If you need to separately install and use the QEMU emulator, you can go to | ||
1469 | <ulink url='http://www.qemu.org'>QEMU Home Page</ulink> to download and learn about the | ||
1470 | emulator.</para></listitem> | ||
1471 | </orderedlist> | ||
1472 | </para> | ||
1473 | </section> | ||
1474 | </section> | ||
1475 | |||
1476 | <section id="modifying-temporary-source-code"> | ||
1477 | <title>Modifying Temporary Source Code</title> | ||
1478 | |||
1479 | <para> | ||
1480 | You might | ||
1481 | find it helpful during development to modify the temporary source code used by recipes | ||
1482 | to build packages. | ||
1483 | For example, suppose you are developing a patch and you need to experiment a bit | ||
1484 | to figure out your solution. | ||
1485 | After you have initially built the package, you can iteratively tweak the | ||
1486 | source code, which is located in the | ||
1487 | <link linkend='build-directory'>Build Directory</link>, and then | ||
1488 | you can force a re-compile and quickly test your altered code. | ||
1489 | Once you settle on a solution, you can then preserve your changes in the form of | ||
1490 | patches. | ||
1491 | You can accomplish these steps all within either a | ||
1492 | <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> or | ||
1493 | <link linkend='git'>Git</link> workflow. | ||
1494 | </para> | ||
1495 | |||
1496 | <section id='finding-the-temporary-source-code'> | ||
1497 | <title>Finding the Temporary Source Code</title> | ||
1498 | |||
1499 | <para> | ||
1500 | During a build, the unpacked temporary source code used by recipes | ||
1501 | to build packages is available in the Build Directory as | ||
1502 | defined by the | ||
1503 | <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename> variable. | ||
1504 | Below is the default value for the <filename>S</filename> variable as defined in the | ||
1505 | <filename>meta/conf/bitbake.conf</filename> configuration file in the | ||
1506 | <link linkend='source-directory'>Source Directory</link>: | ||
1507 | <literallayout class='monospaced'> | ||
1508 | S = ${WORKDIR}/${BP} | ||
1509 | </literallayout> | ||
1510 | You should be aware that many recipes override the <filename>S</filename> variable. | ||
1511 | For example, recipes that fetch their source from Git usually set | ||
1512 | <filename>S</filename> to <filename>${WORKDIR}/git</filename>. | ||
1513 | <note> | ||
1514 | The | ||
1515 | <ulink url='&YOCTO_DOCS_REF_URL;#var-BP'><filename>BP</filename></ulink> | ||
1516 | represents the base recipe name, which consists of the name and version: | ||
1517 | <literallayout class='monospaced'> | ||
1518 | BP = ${BPN}-${PV} | ||
1519 | </literallayout> | ||
1520 | </note> | ||
1521 | </para> | ||
1522 | |||
1523 | <para> | ||
1524 | The path to the work directory for the recipe | ||
1525 | (<ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>) depends | ||
1526 | on the recipe name and the architecture of the target device. | ||
1527 | For example, here is the work directory for recipes and resulting packages that are | ||
1528 | not device-dependent: | ||
1529 | <literallayout class='monospaced'> | ||
1530 | ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR} | ||
1531 | </literallayout> | ||
1532 | Let's look at an example without variables. | ||
1533 | Assuming a top-level <link linkend='source-directory'>Source Directory</link> | ||
1534 | named <filename>poky</filename> | ||
1535 | and a default Build Directory of <filename>poky/build</filename>, | ||
1536 | the following is the work directory for the <filename>acl</filename> recipe that | ||
1537 | creates the <filename>acl</filename> package: | ||
1538 | <literallayout class='monospaced'> | ||
1539 | ~/poky/build/tmp/work/i586-poky-linux/acl-2.2.51-r3 | ||
1540 | </literallayout> | ||
1541 | </para> | ||
1542 | |||
1543 | <para> | ||
1544 | If your resulting package is dependent on the target device, | ||
1545 | the work directory varies slightly: | ||
1546 | <literallayout class='monospaced'> | ||
1547 | ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR} | ||
1548 | </literallayout> | ||
1549 | Again, assuming top-level Source Directory named <filename>poky</filename> | ||
1550 | and a default Build Directory of <filename>poky/build</filename>, the | ||
1551 | following are the work and temporary source directories, respectively, | ||
1552 | for the <filename>acl</filename> package that is being | ||
1553 | built for a MIPS-based device: | ||
1554 | <literallayout class='monospaced'> | ||
1555 | ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2 | ||
1556 | ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2/acl-2.2.51 | ||
1557 | </literallayout> | ||
1558 | </para> | ||
1559 | |||
1560 | <note> | ||
1561 | To better understand how the OpenEmbedded build system resolves directories during the | ||
1562 | build process, see the glossary entries for the | ||
1563 | <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>, | ||
1564 | <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>, | ||
1565 | <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>, | ||
1566 | <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></ulink>, | ||
1567 | <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_OS'><filename>TARGET_OS</filename></ulink>, | ||
1568 | <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>, | ||
1569 | <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, | ||
1570 | and | ||
1571 | <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink> | ||
1572 | variables in the Yocto Project Reference Manual. | ||
1573 | </note> | ||
1574 | |||
1575 | <para> | ||
1576 | Now that you know where to locate the directory that has the temporary source code, | ||
1577 | you can use a Quilt or Git workflow to make your edits, test the changes, | ||
1578 | and preserve the changes in the form of patches. | ||
1579 | </para> | ||
1580 | </section> | ||
1581 | |||
1582 | <section id="using-a-quilt-workflow"> | ||
1583 | <title>Using a Quilt Workflow</title> | ||
1584 | |||
1585 | <para> | ||
1586 | <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> | ||
1587 | is a powerful tool that allows you to capture source code changes without having | ||
1588 | a clean source tree. | ||
1589 | This section outlines the typical workflow you can use to modify temporary source code, | ||
1590 | test changes, and then preserve the changes in the form of a patch all using Quilt. | ||
1591 | </para> | ||
1592 | |||
1593 | <para> | ||
1594 | Follow these general steps: | ||
1595 | <orderedlist> | ||
1596 | <listitem><para><emphasis>Find the Source Code:</emphasis> | ||
1597 | The temporary source code used by the OpenEmbedded build system is kept in the | ||
1598 | Build Directory. | ||
1599 | See the | ||
1600 | "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>" | ||
1601 | section to learn how to locate the directory that has the temporary source code for a | ||
1602 | particular package.</para></listitem> | ||
1603 | <listitem><para><emphasis>Change Your Working Directory:</emphasis> | ||
1604 | You need to be in the directory that has the temporary source code. | ||
1605 | That directory is defined by the | ||
1606 | <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink> | ||
1607 | variable.</para></listitem> | ||
1608 | <listitem><para><emphasis>Create a New Patch:</emphasis> | ||
1609 | Before modifying source code, you need to create a new patch. | ||
1610 | To create a new patch file, use <filename>quilt new</filename> as below: | ||
1611 | <literallayout class='monospaced'> | ||
1612 | $ quilt new my_changes.patch | ||
1613 | </literallayout></para></listitem> | ||
1614 | <listitem><para><emphasis>Notify Quilt and Add Files:</emphasis> | ||
1615 | After creating the patch, you need to notify Quilt about the files | ||
1616 | you plan to edit. | ||
1617 | You notify Quilt by adding the files to the patch you just created: | ||
1618 | <literallayout class='monospaced'> | ||
1619 | $ quilt add file1.c file2.c file3.c | ||
1620 | </literallayout> | ||
1621 | </para></listitem> | ||
1622 | <listitem><para><emphasis>Edit the Files:</emphasis> | ||
1623 | Make your changes in the temporary source code to the files you added | ||
1624 | to the patch.</para></listitem> | ||
1625 | <listitem><para><emphasis>Test Your Changes:</emphasis> | ||
1626 | Once you have modified the source code, the easiest way to test your changes | ||
1627 | is by calling the <filename>compile</filename> task as shown in the following example: | ||
1628 | <literallayout class='monospaced'> | ||
1629 | $ bitbake -c compile -f <name_of_package> | ||
1630 | </literallayout> | ||
1631 | The <filename>-f</filename> or <filename>--force</filename> | ||
1632 | option forces re-execution of the specified task. | ||
1633 | If you find problems with your code, you can just keep editing and | ||
1634 | re-testing iteratively until things work as expected. | ||
1635 | <note>All the modifications you make to the temporary source code | ||
1636 | disappear once you <filename>-c clean</filename> or | ||
1637 | <filename>-c cleanall</filename> with BitBake for the package. | ||
1638 | Modifications will also disappear if you use the <filename>rm_work</filename> | ||
1639 | feature as described in the | ||
1640 | "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" | ||
1641 | section of the Yocto Project Quick Start. | ||
1642 | </note></para></listitem> | ||
1643 | <listitem><para><emphasis>Generate the Patch:</emphasis> | ||
1644 | Once your changes work as expected, you need to use Quilt to generate the final patch that | ||
1645 | contains all your modifications. | ||
1646 | <literallayout class='monospaced'> | ||
1647 | $ quilt refresh | ||
1648 | </literallayout> | ||
1649 | At this point the <filename>my_changes.patch</filename> file has all your edits made | ||
1650 | to the <filename>file1.c</filename>, <filename>file2.c</filename>, and | ||
1651 | <filename>file3.c</filename> files.</para> | ||
1652 | <para>You can find the resulting patch file in the <filename>patches/</filename> | ||
1653 | subdirectory of the source (<filename>S</filename>) directory.</para></listitem> | ||
1654 | <listitem><para><emphasis>Copy the Patch File:</emphasis> | ||
1655 | For simplicity, copy the patch file into a directory named <filename>files</filename>, | ||
1656 | which you can create in the same directory that holds the recipe | ||
1657 | (<filename>.bb</filename>) file or the | ||
1658 | append (<filename>.bbappend</filename>) file. | ||
1659 | Placing the patch here guarantees that the OpenEmbedded build system will find | ||
1660 | the patch. | ||
1661 | Next, add the patch into the | ||
1662 | <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename> | ||
1663 | of the recipe. | ||
1664 | Here is an example: | ||
1665 | <literallayout class='monospaced'> | ||
1666 | SRC_URI += "file://my_changes.patch" | ||
1667 | </literallayout></para></listitem> | ||
1668 | <listitem><para><emphasis>Increment the Recipe Revision Number:</emphasis> | ||
1669 | Finally, don't forget to 'bump' the | ||
1670 | <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename> | ||
1671 | value in the recipe since the resulting packages have changed.</para></listitem> | ||
1672 | </orderedlist> | ||
1673 | </para> </section> | ||
1674 | |||
1675 | <section id='using-a-git-workflow'> | ||
1676 | <title>Using a Git Workflow</title> | ||
1677 | <para> | ||
1678 | Git is an even more powerful tool that allows you to capture source code changes without having | ||
1679 | a clean source tree. | ||
1680 | This section outlines the typical workflow you can use to modify temporary source code, | ||
1681 | test changes, and then preserve the changes in the form of a patch all using Git. | ||
1682 | For general information on Git as it is used in the Yocto Project, see the | ||
1683 | "<link linkend='git'>Git</link>" section. | ||
1684 | </para> | ||
1685 | |||
1686 | <note> | ||
1687 | This workflow uses Git only for its ability to manage local changes to the source code | ||
1688 | and produce patches independent of any version control system used with the Yocto Project. | ||
1689 | </note> | ||
1690 | |||
1691 | <para> | ||
1692 | Follow these general steps: | ||
1693 | <orderedlist> | ||
1694 | <listitem><para><emphasis>Find the Source Code:</emphasis> | ||
1695 | The temporary source code used by the OpenEmbedded build system is kept in the | ||
1696 | Build Directory. | ||
1697 | See the | ||
1698 | "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>" | ||
1699 | section to learn how to locate the directory that has the temporary source code for a | ||
1700 | particular package.</para></listitem> | ||
1701 | <listitem><para><emphasis>Change Your Working Directory:</emphasis> | ||
1702 | You need to be in the directory that has the temporary source code. | ||
1703 | That directory is defined by the | ||
1704 | <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink> | ||
1705 | variable.</para></listitem> | ||
1706 | <listitem><para><emphasis>If needed, initialize a Git Repository:</emphasis> | ||
1707 | If the recipe you are working with does not use a Git fetcher, | ||
1708 | you need to set up a Git repository as follows: | ||
1709 | <literallayout class='monospaced'> | ||
1710 | $ git init | ||
1711 | $ git add * | ||
1712 | $ git commit -m "initial revision" | ||
1713 | </literallayout> | ||
1714 | The above Git commands initialize a Git repository that is based on the | ||
1715 | files in your current working directory, stage all the files, and commit | ||
1716 | the files. | ||
1717 | At this point, your Git repository is aware of all the source code files. | ||
1718 | Any edits you now make to files can be committed later and will be tracked by | ||
1719 | Git.</para></listitem> | ||
1720 | <listitem><para><emphasis>Edit the Files:</emphasis> | ||
1721 | Make your changes to the temporary source code.</para></listitem> | ||
1722 | <listitem><para><emphasis>Test Your Changes:</emphasis> | ||
1723 | Once you have modified the source code, the easiest way to test your changes | ||
1724 | is by calling the <filename>compile</filename> task as shown in the following example: | ||
1725 | <literallayout class='monospaced'> | ||
1726 | $ bitbake -c compile -f <name_of_package> | ||
1727 | </literallayout> | ||
1728 | The <filename>-f</filename> or <filename>--force</filename> | ||
1729 | option forces re-execution of the specified task. | ||
1730 | If you find problems with your code, you can just keep editing and | ||
1731 | re-testing iteratively until things work as expected. | ||
1732 | <note>All the modifications you make to the temporary source code | ||
1733 | disappear once you <filename>-c clean</filename>, <filename>-c cleansstate</filename>, | ||
1734 | or <filename>-c cleanall</filename> with BitBake for the package. | ||
1735 | Modifications will also disappear if you use the <filename>rm_work</filename> | ||
1736 | feature as described in the | ||
1737 | "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" | ||
1738 | section of the Yocto Project Quick Start. | ||
1739 | </note></para></listitem> | ||
1740 | <listitem><para><emphasis>See the List of Files You Changed:</emphasis> | ||
1741 | Use the <filename>git status</filename> command to see what files you have actually edited. | ||
1742 | The ability to have Git track the files you have changed is an advantage that this | ||
1743 | workflow has over the Quilt workflow. | ||
1744 | Here is the Git command to list your changed files: | ||
1745 | <literallayout class='monospaced'> | ||
1746 | $ git status | ||
1747 | </literallayout></para></listitem> | ||
1748 | <listitem><para><emphasis>Stage the Modified Files:</emphasis> | ||
1749 | Use the <filename>git add</filename> command to stage the changed files so they | ||
1750 | can be committed as follows: | ||
1751 | <literallayout class='monospaced'> | ||
1752 | $ git add file1.c file2.c file3.c | ||
1753 | </literallayout></para></listitem> | ||
1754 | <listitem><para><emphasis>Commit the Staged Files and View Your Changes:</emphasis> | ||
1755 | Use the <filename>git commit</filename> command to commit the changes to the | ||
1756 | local repository. | ||
1757 | Once you have committed the files, you can use the <filename>git log</filename> | ||
1758 | command to see your changes: | ||
1759 | <literallayout class='monospaced'> | ||
1760 | $ git commit -m "<commit-summary-message>" | ||
1761 | $ git log | ||
1762 | </literallayout> | ||
1763 | <note>The name of the patch file created in the next step is based on your | ||
1764 | <filename>commit-summary-message</filename>.</note></para></listitem> | ||
1765 | <listitem><para><emphasis>Generate the Patch:</emphasis> | ||
1766 | Once the changes are committed, use the <filename>git format-patch</filename> | ||
1767 | command to generate a patch file: | ||
1768 | <literallayout class='monospaced'> | ||
1769 | $ git format-patch -1 | ||
1770 | </literallayout> | ||
1771 | Specifying "-1" causes Git to generate the | ||
1772 | patch file for the most recent commit.</para> | ||
1773 | <para>At this point, the patch file has all your edits made | ||
1774 | to the <filename>file1.c</filename>, <filename>file2.c</filename>, and | ||
1775 | <filename>file3.c</filename> files. | ||
1776 | You can find the resulting patch file in the current directory and it | ||
1777 | is named according to the <filename>git commit</filename> summary line. | ||
1778 | The patch file ends with <filename>.patch</filename>.</para></listitem> | ||
1779 | <listitem><para><emphasis>Copy the Patch File:</emphasis> | ||
1780 | For simplicity, copy the patch file into a directory named <filename>files</filename>, | ||
1781 | which you can create in the same directory that holds the recipe | ||
1782 | (<filename>.bb</filename>) file or the | ||
1783 | append (<filename>.bbappend</filename>) file. | ||
1784 | Placing the patch here guarantees that the OpenEmbedded build system will find | ||
1785 | the patch. | ||
1786 | Next, add the patch into the | ||
1787 | <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename> | ||
1788 | of the recipe. | ||
1789 | Here is an example: | ||
1790 | <literallayout class='monospaced'> | ||
1791 | SRC_URI += "file://0001-<commit-summary-message>.patch" | ||
1792 | </literallayout></para></listitem> | ||
1793 | <listitem><para><emphasis>Increment the Recipe Revision Number:</emphasis> | ||
1794 | Finally, don't forget to 'bump' the | ||
1795 | <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename> | ||
1796 | value in the recipe since the resulting packages have changed.</para></listitem> | ||
1797 | </orderedlist> | ||
1798 | </para> | ||
1799 | </section> | ||
1800 | </section> | ||
1801 | |||
1802 | <section id='image-development-using-hob'> | ||
1803 | <title>Image Development Using Hob</title> | ||
1804 | |||
1805 | <para> | ||
1806 | The <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> is a graphical user interface for the | ||
1807 | OpenEmbedded build system, which is based on BitBake. | ||
1808 | You can use the Hob to build custom operating system images within the Yocto Project build environment. | ||
1809 | Hob simply provides a friendly interface over the build system used during system development. | ||
1810 | In other words, building images with the Hob lets you take care of common build tasks more easily. | ||
1811 | </para> | ||
1812 | |||
1813 | <para> | ||
1814 | For a better understanding of Hob, see the project page at | ||
1815 | <ulink url='&YOCTO_HOME_URL;/projects/hob'></ulink> on the Yocto Project website. | ||
1816 | The page has a short introductory training video on Hob. | ||
1817 | The following lists some features of Hob: | ||
1818 | <itemizedlist> | ||
1819 | <listitem><para>You can setup and run Hob using these commands: | ||
1820 | <literallayout class='monospaced'> | ||
1821 | $ source oe-init-build-env | ||
1822 | $ hob | ||
1823 | </literallayout></para></listitem> | ||
1824 | <listitem><para>You can set the | ||
1825 | <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> | ||
1826 | for which you are building the image.</para></listitem> | ||
1827 | <listitem><para>You can modify various policy settings such as the package format used to build with, | ||
1828 | the parrallelism BitBake uses, whether or not to build an external toolchain, and which host | ||
1829 | to build against.</para></listitem> | ||
1830 | <listitem><para>You can manage | ||
1831 | <link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem> | ||
1832 | <listitem><para>You can select a base image and then add extra packages for your custom build. | ||
1833 | </para></listitem> | ||
1834 | <listitem><para>You can launch and monitor the build from within Hob.</para></listitem> | ||
1835 | </itemizedlist> | ||
1836 | </para> | ||
1837 | </section> | ||
1838 | |||
1839 | <section id="platdev-appdev-devshell"> | ||
1840 | <title>Using a Development Shell</title> | ||
1841 | |||
1842 | <para> | ||
1843 | When debugging certain commands or even when just editing packages, | ||
1844 | <filename>devshell</filename> can be a useful tool. | ||
1845 | When you invoke <filename>devshell</filename>, source files are | ||
1846 | extracted into your working directory and patches are applied. | ||
1847 | Then, a new terminal is opened and you are placed in the working directory. | ||
1848 | In the new terminal, all the OpenEmbedded build-related environment variables are | ||
1849 | still defined so you can use commands such as <filename>configure</filename> and | ||
1850 | <filename>make</filename>. | ||
1851 | The commands execute just as if the OpenEmbedded build system were executing them. | ||
1852 | Consequently, working this way can be helpful when debugging a build or preparing | ||
1853 | software to be used with the OpenEmbedded build system. | ||
1854 | </para> | ||
1855 | |||
1856 | <para> | ||
1857 | Following is an example that uses <filename>devshell</filename> on a target named | ||
1858 | <filename>matchbox-desktop</filename>: | ||
1859 | <literallayout class='monospaced'> | ||
1860 | $ bitbake matchbox-desktop -c devshell | ||
1861 | </literallayout> | ||
1862 | </para> | ||
1863 | |||
1864 | <para> | ||
1865 | This command spawns a terminal with a shell prompt within the OpenEmbedded build environment. | ||
1866 | The <ulink url='&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL'><filename>OE_TERMINAL</filename></ulink> | ||
1867 | controls what type of shell is opened. | ||
1868 | </para> | ||
1869 | |||
1870 | <para> | ||
1871 | For spawned terminals, the following occurs: | ||
1872 | <itemizedlist> | ||
1873 | <listitem><para>The <filename>PATH</filename> variable includes the | ||
1874 | cross-toolchain.</para></listitem> | ||
1875 | <listitem><para>The <filename>pkgconfig</filename> variables find the correct | ||
1876 | <filename>.pc</filename> files.</para></listitem> | ||
1877 | <listitem><para>The <filename>configure</filename> command finds the | ||
1878 | Yocto Project site files as well as any other necessary files.</para></listitem> | ||
1879 | </itemizedlist> | ||
1880 | </para> | ||
1881 | |||
1882 | <para> | ||
1883 | Within this environment, you can run configure or compile | ||
1884 | commands as if they were being run by | ||
1885 | the OpenEmbedded build system itself. | ||
1886 | As noted earlier, the working directory also automatically changes to the | ||
1887 | Source Directory (<ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>). | ||
1888 | </para> | ||
1889 | |||
1890 | <para> | ||
1891 | When you are finished, you just exit the shell or close the terminal window. | ||
1892 | </para> | ||
1893 | |||
1894 | <note> | ||
1895 | <para> | ||
1896 | It is worth remembering that when using <filename>devshell</filename> | ||
1897 | you need to use the full compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename> | ||
1898 | instead of just using <filename>gcc</filename>. | ||
1899 | The same applies to other applications such as <filename>binutils</filename>, | ||
1900 | <filename>libtool</filename> and so forth. | ||
1901 | BitBake sets up environment variables such as <filename>CC</filename> | ||
1902 | to assist applications, such as <filename>make</filename> to find the correct tools. | ||
1903 | </para> | ||
1904 | |||
1905 | <para> | ||
1906 | It is also worth noting that <filename>devshell</filename> still works over | ||
1907 | X11 forwarding and similar situations | ||
1908 | </para> | ||
1909 | </note> | ||
1910 | </section> | 34 | </section> |
1911 | 35 | ||
1912 | </chapter> | 36 | </chapter> |