summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2011-08-10 14:21:23 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-08-15 15:27:00 +0100
commit04c77b9fb532e43fbc936c624f0c65124dee4ceb (patch)
tree1291b4c8788a8b89f05e6d3aa19f9265ba5ba3b6 /documentation
parentd14ab10f5bf762955931d519e1e059366cafb8a6 (diff)
downloadpoky-04c77b9fb532e43fbc936c624f0c65124dee4ceb.tar.gz
documentation/dev-manual/dev-manual-kernel-appendix.xml: re-write
I performed a major re-write of this section that touched all aspects of it. This was necessary due to the fact I could not get the example running because of not understanding the repo location and branch needs to set it up. (From yocto-docs rev: 160e66d0c8ddf11584c53306def916a45a05f62b) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/dev-manual/dev-manual-kernel-appendix.xml505
1 files changed, 362 insertions, 143 deletions
diff --git a/documentation/dev-manual/dev-manual-kernel-appendix.xml b/documentation/dev-manual/dev-manual-kernel-appendix.xml
index 5aed90f95b..ac344985bd 100644
--- a/documentation/dev-manual/dev-manual-kernel-appendix.xml
+++ b/documentation/dev-manual/dev-manual-kernel-appendix.xml
@@ -6,16 +6,13 @@
6<title>Kernel Modification Example</title> 6<title>Kernel Modification Example</title>
7 7
8 <para> 8 <para>
9 Kernel modification involves changing or adding configurations to an existing kernel, or 9 Kernel modification involves changing or adding configurations to an existing kernel,
10 adding recipes to the kernel that are needed to support specific hardware features. 10 adding recipes to the kernel that are needed to support specific hardware features, or even
11 The process is similar to creating a Board Support Package (BSP) except that it invloves 11 changing the source code itself.
12 isolating your work in a kernel layer and the use of <filename>menuconfig</filename> 12 This section presents some simple examples that modify the kernel source code,
13 to help make configuration data easily identifiable. 13 change the kernel configuration, and add a kernel source recipe.
14 </para> 14<!-- [WRITER'S NOTE: I might want to work in information about applying a local
15 15 change to a kernel layer and also pushing a change upstream into the tree]
16 <para>
17 This section presents a simple example that shows how to modify the kernel.
18 The example uses a three-step approach that is convenient for making kernel modifications.
19 <orderedlist> 16 <orderedlist>
20 <listitem><para>Iteratively determine and set kernel configurations and make 17 <listitem><para>Iteratively determine and set kernel configurations and make
21 kernel recipe changes.</para></listitem> 18 kernel recipe changes.</para></listitem>
@@ -24,19 +21,19 @@
24 <listitem><para>Push your configuration and recipe changes upstream into the 21 <listitem><para>Push your configuration and recipe changes upstream into the
25 Yocto Project source repositories to make them available to the community. 22 Yocto Project source repositories to make them available to the community.
26 </para></listitem> 23 </para></listitem>
27 </orderedlist> 24 </orderedlist> -->
28 </para> 25 </para>
29 26
30 <section id='modifying-a-kernel-example'> 27 <section id='modifying-the-kernel-source-code'>
31 <title>Modifying a Kernel Example</title> 28 <title>Modifying the Kernel Source Code</title>
32 29
33 <para> 30 <para>
34 The example changes kernel configurations to support the VFAT filesystem and 31 This example adds some simple QEMU emulator console output at boot time by
35 allow the user to print out a simple text file from the mounted VFAT filesystem. 32 adding <filename>printk</filename> statements to the kernel's
36 The filesystem used will be an image filesystem rather than a filesystem on some 33 <filename>calibrate.c</filename> source code file.
37 external drive such as a USB stick or external drive. 34 Booting the modified image causes the added messages to appear on the emulator's
38 The example uses the <filename>linux-yocto-2.6.37</filename> kernel. 35 console.
39 </para> 36 </para>
40 37
41 <para> 38 <para>
42 For a general flow of the example, see 39 For a general flow of the example, see
@@ -44,11 +41,72 @@
44 earlier in this manual. 41 earlier in this manual.
45 </para> 42 </para>
46 43
47 <section id='setting-up-yocto-project-kernel-example'> 44 <section id='understanding-the-files-you-need'>
48 <title>Setting Up Yocto Project</title> 45 <title>Understanding the Files You Need</title>
46
47 <para>
48 Before you modify the kernel you need to know what Git repositories and file
49 structures you need.
50 Briefly, you need the following:
51 <itemizedlist>
52 <listitem><para>A local Yocto Project files Git repository</para></listitem>
53 <listitem><para>The <filename>poky-extras</filename> Git repository placed
54 within the local Yocto Project files Git repository</para></listitem>
55 <listitem><para>A bare clone of the Linux Yocto kernel that you want to modify
56 </para></listitem>
57 <listitem><para>A copy of that bare clone in which you make your source
58 modifcations</para></listitem>
59 </itemizedlist>
60 </para>
61
62 <para>
63 The following illustration summarizes what you need:
64 </para>
65
66 <para>
67 <imagedata fileref="figures/kernel-example-repos.png" width="7in" depth="4in"
68 align="center" scale="100" />
69 </para>
70
71 <para>
72 Here is a brief description of the four areas:
73 <itemizedlist>
74 <listitem><para><emphasis>Local Yocto Project Files:</emphasis> This Git
75 repository contains all the metadata that supports building images in the
76 Yocto Project build environment.
77 Note that the Git repository in our example also contains the
78 <filename>poky-extras</filename> Git repository, which contains the
79 kernel metadata specific to building a kernel image.
80 The Local Yocto Project files Git repository also contains the build directory
81 and configuration files that let you control the build.</para></listitem>
82 <listitem><para><emphasis><filename>poky-extras</filename>:</emphasis> This
83 Git repository contains the <filename>meta-kernel-dev</filename> layer,
84 which is where you make changes that append to the kernel build recipes.
85 You edit <filename>.bbappend</filename> files to point the build to your
86 local kernel source files and to define the kernel being built.
87 This Git repository is a gathering place for extensions to the Linux Yocto
88 (or really any) kernel recipes that faciliate the creation and development
89 of kernel features, BSPs or configuration</para></listitem>
90 <listitem><para><emphasis>Bare Clone of the Linux Yocto Git Repository:</emphasis>
91 This bare Git repository tracks the upstream Git repository of the Linux Yocto kernel
92 you are changing.
93 As mentioned, when you build the Linux Yocto kernel image you point to this repository
94 so that the build process can locate the locally changed source files.
95 When you modify the kernel image you must work with a bare clone.
96 </para></listitem>
97 <listitem><para><emphasis>Copy of the Linux Yocto Kernel Bare Clone:</emphasis>
98 This Git repository contains the actual source files that you modify.
99 Any changes you make to files in this location need to ultimately be pushed
100 to the bare clone using the <filename>git push</filename> command.
101 </para></listitem>
102 </itemizedlist>
103 </para>
104 </section>
105
106 <section id='setting-up-the-local-yocto-project-files-git-repository'>
107 <title>Setting Up the Local Yocto Project Files Git Repository</title>
49 108
50 <para> 109 <para>
51 You need to have the Yocto Project files available on your host system.
52 You can get files through tarball extraction or by cloning the <filename>poky</filename> 110 You can get files through tarball extraction or by cloning the <filename>poky</filename>
53 Git repository. 111 Git repository.
54 See the bulleted item 112 See the bulleted item
@@ -58,183 +116,344 @@
58 </para> 116 </para>
59 117
60 <para> 118 <para>
61 Once you have the local <filename>poky</filename> Git repository set up, 119 This example assumes the name of the Git repository is <filename>poky</filename>.
120 Once you have the repository set up,
62 you have many development branches from which you can work. 121 you have many development branches from which you can work.
63 From inside the repository you can see the branch names and the tag names used 122 From inside the repository you can see the branch names and the tag names used
64 in the Git repository using either of the following two commands: 123 in the Git repository using either of the following two commands:
65 <literallayout class='monospaced'> 124 <literallayout class='monospaced'>
125 $ cd poky
66 $ git branch -a 126 $ git branch -a
67 $ git tag -l 127 $ git tag -l
68 </literallayout> 128 </literallayout>
69 For this example we are going to use the Yocto Project 1.1 Release, 129 For this example, we are going to use the Yocto Project 1.1_M3 Release,
70 which maps to the <filename>1.1</filename> branch in the repository. 130 which maps to the <filename>1.1_M3</filename> branch in the repository.
71 These commands create a local branch named <filename>1.1</filename> 131 These commands create a local branch named <filename>1.1_M3</filename>
72 that tracks the remote branch of the same name. 132 that tracks the remote branch of the same name.
73 <literallayout class='monospaced'> 133 <literallayout class='monospaced'>
74 $ cd poky 134 $ git checkout -b 1.1_M3 origin/1.1_M3
75 $ git checkout -b 1.1 origin/1.1 135 Branch 1.1_M3 set up to track remote branch 1.1_M3 from origin.
76 Switched to a new branch '1.1' 136 Switched to a new branch '1.1_M3'
77 </literallayout> 137 </literallayout>
78 </para> 138 </para>
79 </section> 139 </section>
80 140
81 <section id='getting-a-local-copy-of-the-kernel-files'> 141 <section id='setting-up-the-poky-extras-git-repository'>
82 <title>Getting a Local Copy of the Kernel Files</title> 142 <title>Setting Up the <filename>poky-extras</filename> Git Repository</title>
83 143
84 <para> 144 <para>
85 You need to have a local copy of the Linux Yocto kernel files on your system. 145 This example places the <filename>poky-extras</filename> Git repository inside
86 Yocto Project files available on your host system. 146 of <filename>poky</filename>.
87 You must create a local Git repository of these files.
88 See the bulleted item 147 See the bulleted item
89 <link linkend='local-kernel-files'>Linux Yocto Kernel</link> in 148 <link linkend='poky-extras-repo'>The
149 <filename>poky-extras</filename> Git Repository</link> in
90 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual 150 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
91 for information on how to get these files. 151 for information on how to get these files.
92 </para> 152 </para>
93 </section> 153 </section>
94 154
95 <section id='create-a-layer-for-your-kernel-work'> 155 <section id='setting-up-the-bare-clone-and-its-copy'>
96 <title>Create a Layer for Your Kernel Work</title> 156 <title>Setting Up the Bare Clone and its Copy</title>
97 157
98 <para> 158 <para>
99 It is always good to isolate your work using your own layer. 159 This example modifies the <filename>linux-yocto-2.6.37</filename> kernel.
100 Doing so allows you to experiment and easily start over should things go wrong. 160 Thus, you need to create a bare clone of that kernel and then make a copy of the
101 This example uses a layer named <filename>meta-vfatsupport</filename>. 161 bare clone.
162 See the bulleted item
163 <link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
164 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
165 for information on how to do that.
102 </para> 166 </para>
103 167
104 <para> 168 <para>
105 When you set up a layer for kernel work you should follow general layout 169 The bare clone exists simply as the receiving end of <filename>git push</filename>
106 guidelines layers. 170 commands after you make edits and commits inside the copy of the clone.
107 For example, if you were creating a BSP you would want to follow the layout 171 The copy (<filename>linux-yocto-2.6.37</filename> in this example) has to have
108 described in the 172 a local branch created and checked out for your work.
109 <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'> 173 The following commands create and checkout the branch:
110 Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development 174 <literallayout class='monospaced'>
111 Guide. 175 $ cd ~/linux-yocto-2.6.37
112 For kernel layers, you can start with a skeleton layer 176 $ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
113 named <filename>meta-skeleton</filename> found in your local 177 Branch common-pc-base set up to track remote branch yocto/standard/common-pc/base from origin.
114 Yocto Project file directory structure (the <filename>poky</filename> Git 178 Switched to a new branch 'common-pc-base'
115 repository or the directory structure resulting from unpacking the Yocto Project 179 </literallayout>
116 release tarball).
117 </para> 180 </para>
181 </section>
118 182
119 <para> 183 <section id='building-and-booting-the-default-qemu-kernel-image'>
120 To create your kernel layer simply copy the <filename>meta-skeleton</filename> 184 <title>Building and Booting the Default QEMU Kernel Image</title>
121 layer and rename it <filename>meta-vfatsupport</filename>. 185
122 The following command sets up the layer inside the <filename>poky</filename> 186 <para>
123 Git repository: 187 In this example before we make changes to the kernel image we will build it first
188 and see how it boots inside the QEMU emulator.
189 <note>
190 Because a full build can take hours, you should check two variables in the
191 <filename>build</filename> directory that is created after you source the
192 <filename>oe-init-build-env</filename> script.
193 You can find these variables
194 <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
195 in the <filename>build/conf</filename> directory in the
196 <filename>local.conf</filename> configuration file.
197 By default, these variables are commented out.
198 If your host development system supports multi-core and multi-thread capabilities
199 you can uncomment these statements and set the variables to significantly shorten
200 the full build time.
201 As a guideline, set <filename>BB_NUMBER_THREADS</filename> to twice the number
202 of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and
203 a half times the number of cores your machine supports.
204 </note>
205 These commands build the default <filename>qemux86</filename> image:
124 <literallayout class='monospaced'> 206 <literallayout class='monospaced'>
125 $ cd ~/poky 207 $ cd ~/poky
126 $ cp -r meta-skeleton meta-vfatsupport 208 $ source oe-init-build-env
209
210 ### Shell environment set up for builds. ###
211
212 You can now run 'bitbake &lt;target&gt;'
213
214 Common targets are:
215 core-image-minimal
216 core-image-sato
217 meta-toolchain
218 meta-toolchain-sdk
219 adt-installer
220 meta-ide-support
221
222 You can also run generated qemu images with a command like 'runqemu qemux86'
223
224 $ bitbake -k core-image-minimal
127 </literallayout> 225 </literallayout>
128 </para> 226 </para>
129 227
130 <para> 228 <para>
131 In the new layer you will find areas for configuration changes 229 The <filename>source</filename> command sets up the build environment, while the
132 (<filename>conf</filename>) and recipe changes (<filename>recipes-skeleton</filename>). 230 following <filename>bitbake</filename> command starts the build.
133 </para> 231 </para>
134 232
135 <para> 233 <para>
136 You need to modify the structure a bit for your work. 234 After the build completes, you can start the QEMU emulator using the resulting image
137 These commands add some further structure and names that the Yocto Project build 235 <filename>qemux86</filename> as follows:
138 environment expect:
139 <literallayout class='monospaced'> 236 <literallayout class='monospaced'>
140 $ mkdir meta-vfatsupport/images 237 $ runqemu qemux86
141 $ mkdir meta-vfatsupport/recipes-bsp
142 $ mv meta-vfatsupport/recipes-skeleton meta-vfatsupport/recipes-kernel
143 $ mkdir meta-vfatsupport/recipes-kernel/linux
144 $ mkdir meta-vfatsupport/recipes-kernel/linux/linux-yocto
145 </literallayout> 238 </literallayout>
146 </para> 239 </para>
147 240
148 <para> 241 <para>
149 The last piece you need for your layer is a 242 As the image boots in the emulator, console messages and status appear across the
150 <filename>linux-yocto_git.bbappend</filename> file inside 243 terminal window.
151 <filename>meta-vfatsupport/recipes-kernel/linux</filename>. 244 Because the output scrolls by quickly it is difficult to read.
152 This file needs the following content to make the build process aware of the 245 To examine the output you can log into the system using the
153 new layer's location: 246 login <filename>root</filename> with no password.
247 Once you are logged in, you can issue the following command to scroll through the
248 console output:
154 <literallayout class='monospaced'> 249 <literallayout class='monospaced'>
155 FILESEXTRAPATHS := "${THISDIR}/${PN}" 250 # dmesg | less
156 </literallayout> 251 </literallayout>
157 </para> 252 </para>
158 253
159 <para> 254 <para>
160 [WRITER'S NOTE: We need a better <filename>meta-skeleton</filename> layer 255 Take note of the output as you will want to look for your inserted print command output
161 that is part of <filename>poky</filename>. 256 later in the example.
162 It should have a structure that includes <filename>images</filename>,
163 <filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>, and
164 so forth.
165 For now this step of the example is brute-forcing the structure with shell
166 commands to set up the minimum structure and include the
167 <filename>.bbappend</filename> file.
168 </para> 257 </para>
169 </section> 258 </section>
170 259
171 <section id='be-sure-the-image-is-available'> 260 <section id='changing-the-source-code-and-pushing-it-to-the-bare-clone'>
172 <title>Be Sure the Image is Available</title> 261 <title>Changing the Source Code and Pushing it to the Bare Clone</title>
173 262
174 <para> 263 <para>
175 For the example you need an image that you can use when you run the QEMU emulator. 264 The file you change in this example is named <filename>calibrate.c</filename>
176 By default, support of VFAT filesystems will not be supported in this image. 265 and is located in the <filename>linux-yocto-2.6.37</filename> Git repository
177 The example will test that in a subsequent section. 266 in <filename>init</filename>.
267 For this example simply insert several <filename>printk</filename> statements
268 at the beginning of the <filename>calibrate_delay</filename> function.
269 Now let's look at the changes to the source code.
270 Here is the unaltered code at the start of this function:
271 <literallayout class='monospaced'>
272 void __cpuinit calibrate_delay(void)
273 {
274 unsigned long ticks, loopbit;
275 int lps_precision = LPS_PREC;
276 static bool printed;
277
278 if (preset_lpj) {
279 .
280 .
281 .
282 </literallayout>
283 </para>
284
285 <para>
286 This example uses the following five <filename>printk</filename> statements
287 just after defining <filename>lps_precision</filename>:
288 <literallayout class='monospaced'>
289 void __cpuinit calibrate_delay(void)
290 {
291 unsigned long ticks, loopbit;
292 int lps_precision = LPS_PREC;
293 printk("*************************************\n");
294 printk("* *\n");
295 printk("* HELLO YOCTO KERNEL *\n");
296 printk("* *\n");
297 printk("*************************************\n");
298 static bool printed;
299
300 if (preset_lpj) {
301 .
302 .
303 .
304 </literallayout>
305 </para>
306
307 <para>
308 After making and saving your changes, you need to stage them for the push.
309 The following Git commands stage and commit your changes:
310 <literallayout class='monospaced'>
311 $ git add calibrate.c
312 $ git commit --signoff
313 </literallayout>
314 </para>
315
316 <para>
317 Once the source code has been modified you need to use Git to push the changes to
318 the bare clone.
319 If you do not push the changes then the Yocto Project build system will not pick
320 the changed source files.
321 </para>
322
323 <para>
324 To push the changes do the following:
325 <literallayout class='monospaced'>
326 $ git push origin common-pc-base:yocto/standard/common-pc/base
327 </literallayout>
328 </para>
329
330 <para>
331 For general information on how to push a change using Git, see [WRITER'S NOTE: need
332 the link to the submitting a change section].
333 </para>
334 </section>
335
336 <section id='changing-build-parameters-for-your-build'>
337 <title>Changing Build Parameters for Your Build</title>
338
339 <para>
340 At this point the source has been changed and pushed.
341 Now you need to define some variables used by the Yocto Project build system to locate your
342 source.
343 You essentially need to identify where to find the kernel recipe and the changed source code.
344 You also need to be sure some basic configurations are in place that identify the
345 type of machine you are building and to help speed up the build should your host support
346 multiple-core and thread capabilities.
347 </para>
348
349 <para>
350 Do the following to make sure the build parameters are set up for the example.
351 Once you set up these build parameters they should not have to change unless you
352 change the target architecture of the machine you are building or you move
353 the bare clone, copy of the clone, or the <filename>poky-extras</filename> repository:
354 <itemizedlist>
355 <listitem><para><emphasis>Build for the Correct Target Architecture</emphasis> - The
356 <filename>local.conf</filename> in the build directory defines the build's
357 target architecture.
358 By default,
359 <filename>MACHINE</filename> is set to <filename>qemux86</filename>, which
360 specifies a 32-bit Intel Architecture target machine suitable for the
361 QEMU emulator.
362 So for this example, <filename>MACHINE</filename> is correctly configured.
363 </para></listitem>
364 <listitem><para><emphasis>Optimize Build Time</emphasis> - Also in the
365 <filename>local.conf</filename> file are two variables that can speed your
366 build time if your host supports multi-core and multi-thread capabilities:
367 <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>.
368 If the host system has multiple cores then you can optimize build time
369 by setting <filename>BB_NUMBER_THREADS</filename> to twice the number of
370 cores and setting <filename>PARALLEL_MAKE</filename> to one and a half times the
371 number of cores.</para></listitem>
372 <listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename>
373 Layer</emphasis> - The <filename>BBLAYERS</filename> variable in the
374 <filename>bblayers.conf</filename> found in the
375 <filename>poky/build/conf</filename> directory needs to have the path to your local
376 <filename>meta-kernel-dev</filename> layer.
377 By default, the <filename>BBLAYERS</filename> variable contains paths to
378 <filename>meta</filename> and <filename>meta-yocto</filename> in the
379 <filename>poky</filename> Git repository.
380 Add the path to your <filename>meta-kernel-dev</filename> location.
381 Here is an example:
382 <literallayout class='monospaced'>
383 BBLAYERS = " \
384 /home/scottrif/poky/meta \
385 /home/scottrif/poky/meta-yocto \
386 /home/scottrif/poky/poky-extras/meta-kernel-dev \
387 "
388 </literallayout></para></listitem>
389 <listitem><para><emphasis>Identify Your Source Files</emphasis> - In the
390 <filename>linux-yocto-2.6.37.bbappend</filename> file located in the
391 <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
392 directory you need to identify the location of the
393 local source code, which in this example is the bare clone named
394 <filename>linux-yocto-2.6.37.git</filename>.
395 To do this, set the <filename>KSRC_linux_yocto</filename> to point to your
396 local <filename>linux-yocto-2.6.37.git</filename> Git repository by adding the
397 following statement:
398 <literallayout class='monospaced'>
399 KSRC_linux_yocto ?= /home/scottrif/linux-yocto-2.6.37.git
400 </literallayout></para></listitem>
401 <listitem><para><emphasis>Specify the Kernel Machine</emphasis> - Also in the
402 <filename>linux-yocto-2.6.37.bbappend</filename> you need to specify
403 the kernel machine with the following statement:
404 <literallayout class='monospaced'>
405 KMACHINE_qemux86 = "yocto/standard/common-pc/base"
406 </literallayout></para></listitem>
407 </itemizedlist>
408 </para>
409 </section>
410
411 <section id='building-and-booting-the-modified-qemu-kernel-image'>
412 <title>Building and Booting the Modified QEMU Kernel Image</title>
413
414 <para>
415 Next, you need to build the modified image.
416 Do the following:
417 <orderedlist>
418 <listitem><para>Your environment should be set up since you previously sourced
419 the <filename>oe-init-build-env</filename> script.
420 If it isn't, source the script again from the <filename>poky</filename>
421 again.</para></listitem>
422 <listitem><para>Be sure any old images are cleaned out by running the
423 <filename>cleanall</filename> BitBake task as follows:
424 <literallayout class='monospaced'>
425 $ bitbake -c cleanall linux-yocto
426 </literallayout></para></listitem>
427 <listitem><para>Build the kernel image using this command:
428 <literallayout class='monospaced'>
429 $ bitbake -k core-image-minimal
430 </literallayout></para></listitem>
431 </orderedlist>
178 </para> 432 </para>
179 433
180 <para> 434 <para>
181 In theory, you can get an image suitable for QEMU one of two ways: 435 Next, boot the modified image in the QEMU emulator using this command:
182 <itemizedlist> 436 <literallayout class='monospaced'>
183 <listitem><para>Download a pre-built kernel image and matching <filename>ext3</filename> 437 $ runqemu qemux86
184 file system from the Yocto Project 438 </literallayout>
185 <ulink url='http://autobuilder.yoctoproject.org/downloads/'>Index of downloads</ulink>.
186 See <link linkend='index-downloads'>Index of Downloads</link> earlier in the
187 manual for more information about this source repository.
188 You can also see
189 <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>
190 Using Pre-Build Binaries and QEMU</ulink>
191 in the Yocto Project Quick Start for information on how to find and choose
192 images ready to run in QEMU.</para></listitem>
193 <listitem><para>Build an image and matching <filename>ext3</filename>
194 filesystem using the <filename>poky</filename> Git repository on your local
195 development system.</para></listitem>
196 </itemizedlist>
197 </para> 439 </para>
198 440
199 <para> 441 <para>
200 This example continues by building the image. 442 Log into the machine using <filename>root</filename> with no password and then
201 If you want to see more on building an image in general, see 443 use the following shell command to scroll through the console's boot output.
202 <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'> 444 <literallayout class='monospaced'>
203 Building an Image</ulink> in the Yocto Project Quick Start. 445 # dmesg | less
446 </literallayout>
204 </para> 447 </para>
205 448
206 <para> 449 <para>
207 The following steps result in a QEMU image and filesystem for 450 You should see the results of your <filename>printk</filename> statements
208 an x86 (32-bit) target machine that can run in the emulator. 451 as part of the output.
209 <orderedlist>
210 <listitem><para><emphasis>Prepare the Build Environment</emphasis> - Source the
211 script to set up the build environment:
212 <literallayout class='monospaced'>
213 $ cd ~/poky
214 $ source oe-init-build-env
215 </literallayout></para></listitem>
216 <listitem><para><emphasis>Change Configurations to Speed Up the Build</emphasis> - If your
217 development system supports multiple cores you can remove the comments in the
218 <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
219 statements and adjust the arguments to optimize the build time.
220 For example, a development host that has four cores could use
221 <filename>8</filename> and <filename>j 6</filename> to get the best use of
222 your host's multi-core and thread capabilities.</para></listitem>
223 <listitem><para><emphasis>Start the Build</emphasis> - Use BitBake to start the
224 build:
225 <literallayout class='monospaced'>
226 $ bitbake -k core-image-sato
227 </literallayout>
228 Depending on your host system's load and capabilities the build takes some time.
229 Once it completes you will have the kernel image needed to continue the example.
230 The image and filesystem reside in the build directory at
231 <filename>poky/build/tmp/deploy/images</filename>.
232 </para></listitem>
233 </orderedlist>
234 </para> 452 </para>
235 </section> 453 </section>
454 </section>
236 455
237 <section id='is-vfat-supported'> 456<!-- <section id='is-vfat-supported'>
238 <title>Is VFAT Supported?</title> 457 <title>Is VFAT Supported?</title>
239 458
240 <para> 459 <para>
@@ -288,12 +507,12 @@ It should just build whatever is necessary and not go through an entire build ag
288 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no 507 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no
289 -hda /home/scottrif/poky/build/tmp/deploy/images/core-image-sato-qemux86.ext3 508 -hda /home/scottrif/poky/build/tmp/deploy/images/core-image-sato-qemux86.ext3
290 -show-cursor -usb -usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot 509 -show-cursor -usb -usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot
291 -m 128 --append "vga=0 root=/dev/hda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 " 510 -m 128 &dash;&dash;append "vga=0 root=/dev/hda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
292 Enabling opengl 511 Enabling opengl
293 vmsvga_value_write: guest runs Linux. 512 vmsvga_value_write: guest runs Linux.
294 </literallayout> 513 </literallayout>
295 </para> 514 </para>
296 </section> 515 </section>
297 516
298 <section id='prepare-to-use-menuconfig'> 517 <section id='prepare-to-use-menuconfig'>
299 <title>Prepare to use <filename>menuconfig</filename></title> 518 <title>Prepare to use <filename>menuconfig</filename></title>
@@ -383,7 +602,7 @@ It should just build whatever is necessary and not go through an entire build ag
383 total 5.1M 602 total 5.1M
384 drwxr-xr-x 2 srifenbark scottrif 4.0K 2011-08-01 08:18 . 603 drwxr-xr-x 2 srifenbark scottrif 4.0K 2011-08-01 08:18 .
385 drwxr-xr-x 66 srifenbark scottrif 4.0K 2011-08-01 08:14 .. 604 drwxr-xr-x 66 srifenbark scottrif 4.0K 2011-08-01 08:14 ..
386 -rw-r--r-- 1 srifenbark scottrif 5.0M 2011-08-01 08:18 vfat.img 605 -rw-r&dash;&dash;r&dash;&dash; 1 srifenbark scottrif 5.0M 2011-08-01 08:18 vfat.img
387 $ mkfs.vfat vfat.img [formats the disk image] 606 $ mkfs.vfat vfat.img [formats the disk image]
388 mkfs.vfat 3.0.7 (24 Dec 2009) 607 mkfs.vfat 3.0.7 (24 Dec 2009)
389 $ mkdir mnt [mounts the disk image] 608 $ mkdir mnt [mounts the disk image]
@@ -472,12 +691,12 @@ It should just build whatever is necessary and not go through an entire build ag
472 </literallayout> 691 </literallayout>
473 </para> 692 </para>
474 </section> 693 </section>
475 </section> 694 </section> -->
476</appendix> 695</appendix>
477 696
478
479<!-- 697<!--
480 698
699
481EXTRA STUFF I MIGHT NEED BUT NOW SURE RIGHT NOW. 700EXTRA STUFF I MIGHT NEED BUT NOW SURE RIGHT NOW.
482 701
483In the standard layer structure you have several areas that you need to examine or 702In the standard layer structure you have several areas that you need to examine or
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-12 15:52:35 +0000