summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTom Zanussi <tom.zanussi@intel.com>2010-09-21 09:21:26 -0500
committerRichard Purdie <rpurdie@linux.intel.com>2010-09-21 23:35:36 +0100
commitc0317494aa8c338c4eb528a362e806c5da1210fd (patch)
tree90b222209053d64bfd8f87ec930e954c83b751da
parent7450c1a2db8adb5645b72ea5796bd7f51e6b158b (diff)
downloadpoky-c0317494aa8c338c4eb528a362e806c5da1210fd.tar.gz
Fix some typos and grammatical errors in Poky handbook
While going through the BSP section, I noticed some minor problems - these are my cleanup fixes. Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
-rw-r--r--handbook/bsp.xml58
1 files changed, 29 insertions, 29 deletions
diff --git a/handbook/bsp.xml b/handbook/bsp.xml
index b897f0691d..7511a03b6b 100644
--- a/handbook/bsp.xml
+++ b/handbook/bsp.xml
@@ -7,19 +7,19 @@
7 7
8 <para> 8 <para>
9 A Board Support Package (BSP) is a collection of information which together 9 A Board Support Package (BSP) is a collection of information which together
10 defines how to support a particular hardware device, set of devices or 10 defines how to support a particular hardware device, set of devices, or
11 hardware platform. It will include information about the hardware features 11 hardware platform. It will include information about the hardware features
12 present on the device, kernel configuration information along with any 12 present on the device and kernel configuration information along with any
13 additional hardware drivers required and also any additional software 13 additional hardware drivers required. It will also list any additional software
14 components required in addition to a generic Linux software stack for both 14 components required in addition to a generic Linux software stack for both
15 essential and optional platform features. 15 essential and optional platform features.
16 </para> 16 </para>
17 17
18 <para> 18 <para>
19 The intend of this document is to define a structure for these components 19 The intent of this document is to define a structure for these components
20 so that BSPs follow a commonly understood layout allowing them to be 20 so that BSPs follow a commonly understood layout, allowing them to be
21 provided in a common way that everyone understands. It also allows end 21 provided in a common form that everyone understands. It also allows end-users
22 users to become familiar with one common format and encourages standardisation 22 to become familiar with one common format and encourages standardisation
23 of software support of hardware. 23 of software support of hardware.
24 </para> 24 </para>
25 25
@@ -36,7 +36,7 @@
36 </para> 36 </para>
37 37
38 <para> 38 <para>
39 The BSP specification does not include a build system or other tools, 39 The BSP specification does not include a build system or other tools -
40 it is concerned with the hardware specific components only. At the end 40 it is concerned with the hardware specific components only. At the end
41 distribution point the BSP may be shipped combined with a build system 41 distribution point the BSP may be shipped combined with a build system
42 and other tools, but it is important to maintain the distinction that these 42 and other tools, but it is important to maintain the distinction that these
@@ -80,10 +80,10 @@ meta-bsp/prebuilds/
80 <title>Prebuilt User Binaries (meta-bsp/binary/*)</title> 80 <title>Prebuilt User Binaries (meta-bsp/binary/*)</title>
81 81
82 <para> 82 <para>
83 This optional area cotains useful prebuilt kernels and userspace filesystem 83 This optional area contains useful prebuilt kernels and userspace filesystem
84 images appropriate to the target system. Users could use these to get a system 84 images appropriate to the target system. Users could use these to get a system
85 running and quickly get started on development tasks. The exact types of binaries 85 running and quickly get started on development tasks. The exact types of binaries
86 present will be highly hardware dependent but a README file should be present 86 present will be highly hardware-dependent but a README file should be present
87 explaining how to use them with the target hardware. If prebuilt binaries are 87 explaining how to use them with the target hardware. If prebuilt binaries are
88 present, source code to meet licensing requirements must also be provided in 88 present, source code to meet licensing requirements must also be provided in
89 some form. 89 some form.
@@ -96,7 +96,7 @@ meta-bsp/prebuilds/
96 96
97 <para> 97 <para>
98 This file identifies the structure as a Poky layer. This file identifies the 98 This file identifies the structure as a Poky layer. This file identifies the
99 contents of the layer and how contains information about how Poky should use 99 contents of the layer and contains information about how Poky should use
100 it. In general it will most likely be a standard boilerplate file consisting of: 100 it. In general it will most likely be a standard boilerplate file consisting of:
101 </para> 101 </para>
102 102
@@ -182,7 +182,7 @@ TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse"
182 182
183 <para> 183 <para>
184 These files make up the definition of a kernel to use with this 184 These files make up the definition of a kernel to use with this
185 hardware. In this case it is a complete self contained kernel with its own 185 hardware. In this case it is a complete self-contained kernel with its own
186 configuration and patches but kernels can be shared between many 186 configuration and patches but kernels can be shared between many
187 machines as well. Taking some specific example files: 187 machines as well. Taking some specific example files:
188 </para> 188 </para>
@@ -194,7 +194,7 @@ meta-bsp/packages/linux/linux-bsp_2.6.50.bb
194 <para> 194 <para>
195 which is the core kernel recipe which firstly details where to get the kernel 195 which is the core kernel recipe which firstly details where to get the kernel
196 source from. All standard source code locations are supported so this could 196 source from. All standard source code locations are supported so this could
197 be a release tarball, some git repository or source included in 197 be a release tarball, some git repository, or source included in
198 the directory within the BSP itself. It then contains information about which 198 the directory within the BSP itself. It then contains information about which
199 patches to apply and how to configure and build it. It can reuse the main 199 patches to apply and how to configure and build it. It can reuse the main
200 Poky kernel build class, so the definitions here can remain very simple. 200 Poky kernel build class, so the definitions here can remain very simple.
@@ -206,7 +206,7 @@ linux-bsp-2.6.50/*.patch
206 </para> 206 </para>
207 <para> 207 <para>
208 which are patches which may be applied against the base kernel, wherever 208 which are patches which may be applied against the base kernel, wherever
209 that may have been obtained from. 209 they may have been obtained from.
210 </para> 210 </para>
211 <para> 211 <para>
212 <programlisting> 212 <programlisting>
@@ -218,7 +218,7 @@ meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
218 </para> 218 </para>
219 <para> 219 <para>
220 Examples of kernel recipes are available in Poky itself. These files are 220 Examples of kernel recipes are available in Poky itself. These files are
221 optional since a kernel from Poky itself could be selected although it 221 optional since a kernel from Poky itself could be selected, although it
222 would be unusual not to have a kernel configuration. 222 would be unusual not to have a kernel configuration.
223 </para> 223 </para>
224 </section> 224 </section>
@@ -229,7 +229,7 @@ meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
229 <para> 229 <para>
230 This area includes other pieces of software which the hardware may need for best 230 This area includes other pieces of software which the hardware may need for best
231 operation. These are just examples of the kind of things that may be 231 operation. These are just examples of the kind of things that may be
232 encountered. The are standard .bb file recipes in the usual Poky format, 232 encountered. These are standard .bb file recipes in the usual Poky format,
233 so for examples, see standard Poky recipes. The source can be included directly, 233 so for examples, see standard Poky recipes. The source can be included directly,
234 referred to in source control systems or release tarballs of external software projects. 234 referred to in source control systems or release tarballs of external software projects.
235 </para> 235 </para>
@@ -273,18 +273,18 @@ meta-bsp/packages/image-creator/image-creator-native_0.1.bb
273 <title>Append BSP specific information to existing recipes</title> 273 <title>Append BSP specific information to existing recipes</title>
274 274
275 <para> 275 <para>
276 Say you have a recipe like pointercal which has machine specific information in it, 276 Say you have a recipe like pointercal which has machine-specific information in it,
277 and then you have your new bsp code in a layer. Before .bbappend extension is 277 and then you have your new BSP code in a layer. Before the .bbappend extension was
278 introduced, you have to copy the whole pointercal recipe and files into your layer, 278 introduced, you'd have to copy the whole pointercal recipe and files into your layer,
279 and then add the single file for your machine which is ugly. 279 and then add the single file for your machine, which is ugly.
280 280
281 .bbappend makes above work much easier, to allow bsp specific information merged 281 .bbappend makes the above work much easier, to allow BSP-specific information to be merged
282 with original recipe easily. When bitbake finds any X.bbappend files, they will be 282 with the original recipe easily. When bitbake finds any X.bbappend files, they will be
283 included after bitbake loads X.bb but before finalise and any anonymous methods run. 283 included after bitbake loads X.bb but before finalise or anonymous methods run.
284 This allows bsp layer to poke around and do whatever it might want to customise 284 This allows the BSP layer to poke around and do whatever it might want to customise
285 the original recipe. 285 the original recipe.
286 286
287 .bbappend is expected to include below two lines in the head (which may be changed 287 .bbappend is expected to include the below two lines in the head (which may be changed
288 in the future): 288 in the future):
289 </para> 289 </para>
290 290
@@ -294,8 +294,8 @@ FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
294 </programlisting> 294 </programlisting>
295 295
296 <para> 296 <para>
297 Then bsp could add machine specific config files in layer directory, which will be 297 Then the BSP could add machine-specific config files in layer directory, which will be
298 added by bitbake. You could look at meta-emenlow/packages/formfactor as example 298 added by bitbake. You can look at meta-emenlow/packages/formfactor as an example.
299 </para> 299 </para>
300 </section> 300 </section>
301 301
@@ -303,9 +303,9 @@ FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
303 <title>Prebuild Data (meta-bsp/prebuilds/*)</title> 303 <title>Prebuild Data (meta-bsp/prebuilds/*)</title>
304 304
305 <para> 305 <para>
306 The location can contains a precompiled representation of the source code 306 The location can contain a precompiled representation of the source code
307 contained elsewhere in the BSP layer. It can be processed and used by 307 contained elsewhere in the BSP layer. It can be processed and used by
308 Poky to provide much faster build times assuming a compatible configuration is used. 308 Poky to provide much faster build times, assuming a compatible configuration is used.
309 </para> 309 </para>
310 310
311 <para> 311 <para>