documentation/dev-manual/dev-manual-model.xml: first pass of kernel steps added. (From yocto-docs rev: a8354af008306f4deeae7b2167c3dbd604d8b275)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
4285c3c968
commit
46af251ce0
|
@ -84,13 +84,18 @@
|
|||
process and tools you need.
|
||||
For information on how to get these files, see the
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> section in this manual.</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>: Having
|
||||
the BSP files on your system gives you access to the build
|
||||
process and tools you need.
|
||||
For information on how to get these files, see
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.</para></listitem>
|
||||
<listitem><para><emphasis>Choose a Yocto Project-supported BSP as your base BSP</emphasis>:
|
||||
The Yocto Project ships with several BSPs that support various hardware.
|
||||
It is best to base your new BSP on an existing BSP rather than create all the
|
||||
recipes and configuration files from scratch.
|
||||
While it is possible to create everything from scratch, basing your new BSP
|
||||
on something that is close is much easier.
|
||||
Or, at a minimum, it gives you some structure with which to start.</para>
|
||||
Or, at a minimum, it gives you some structure with which to start.</para>
|
||||
<para>At this point you need to understand your target hardware well enough to determine which
|
||||
existing BSP it most closely matches.
|
||||
Things to consider are your hardware’s on-board features such as CPU type and graphics support.
|
||||
|
@ -102,13 +107,8 @@
|
|||
<para>To see the supported BSPs, go to the Yocto Project
|
||||
<ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click
|
||||
on “BSP Downloads.”</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>: Having
|
||||
the BSP files on your system gives you access to the build
|
||||
process and tools you need.
|
||||
For information on how to get these files, see
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.</para></listitem>
|
||||
<listitem><para><emphasis>Create your own BSP layer</emphasis>: Layers are ideal for
|
||||
isolating and storing work for a given piece of hardware.
|
||||
isolating and storing work for a given piece of hardware.
|
||||
A layer is really just a location or area in which you place the recipes for your BSP.
|
||||
In fact, a BSP is, in itself, a special type of layer.
|
||||
Consider an application as another example that illustrates a layer.
|
||||
|
@ -119,8 +119,8 @@
|
|||
all the relevant information for the project that the Yocto Project build
|
||||
system knows about.</para>
|
||||
<note>The Yocto Project supports four BSPs that are part of the
|
||||
Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
|
||||
<filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
|
||||
Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
|
||||
<filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
|
||||
The recipes and configurations for these four BSPs are located and dispersed
|
||||
within local Yocto Project files.
|
||||
Consequently, they are not totally isolated in the spirit of layers unless you think
|
||||
|
@ -129,7 +129,7 @@
|
|||
N450, and Sugar Bay are isolated.</note>
|
||||
<para>When you set up a layer for a new BSP you should follow a standard layout.
|
||||
This layout is described in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>
|
||||
Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development
|
||||
Guide.
|
||||
In the standard layout you will notice a suggested structure for recipes and
|
||||
|
@ -137,13 +137,15 @@
|
|||
You can see the standard layout for the Crown Bay BSP in this example by examining the
|
||||
directory structure of the <filename>meta-crownbay</filename> layer inside the
|
||||
local Yocto Project files.</para></listitem>
|
||||
<listitem><para><emphasis>Make configuration and recipe changes to your new BSP
|
||||
<listitem><para><emphasis>Make configuration changes to your new BSP
|
||||
layer</emphasis>: The standard BSP layer structure organizes the files you need to edit in
|
||||
<filename>conf</filename> and several <filename>recipes-*</filename> within the
|
||||
BSP layer.</para>
|
||||
<para>Configuration changes identify where your new layer is on the local system
|
||||
BSP layer.
|
||||
Configuration changes identify where your new layer is on the local system
|
||||
and identify which kernel you are going to use.
|
||||
Recipe changes include altering recipes (<filename>.bb</filename> files), removing
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>: Recipe
|
||||
changes include altering recipes (<filename>.bb</filename> files), removing
|
||||
recipes you don't use, and adding new recipes that you need to support your hardware.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the
|
||||
|
@ -225,8 +227,225 @@
|
|||
<title><anchor id='kernel-spot' />Modifying the Kernel</title>
|
||||
|
||||
<para>
|
||||
Text needed here.
|
||||
Kernel modification involves changing the Linux Yocto kernel, which could involve changing
|
||||
configuration variables as well as adding new kernel recipes.
|
||||
Configuration changes can be added in the form of configuration fragments, while recipe
|
||||
modification comes through the kernel's <filename>recipes-kernel</filename> area
|
||||
in a kernel layer you create.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The remainder of this section presents a high-level overview of the Linux Yocto
|
||||
kernel architecture and the steps to modify the Linux Yocto kernel.
|
||||
For a complete discussion of the kernel, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
|
||||
Yocto Project Kernel Architecture and Use Manual</ulink>.
|
||||
You can reference <xref linkend='dev-manual-kernel-appendix'>Kernel Modification Example</xref>
|
||||
for a detailed example that changes the configuration of a kernel.
|
||||
</para>
|
||||
|
||||
<section id='kernel-overview'>
|
||||
<title>Kernel Overview</title>
|
||||
|
||||
<para>
|
||||
When one thinks of the source files for a kernel they usually think of a fixed structure
|
||||
of files that contain kernel patches.
|
||||
The Yocto Project, however, employs mechanisims that in a sense result in a kernel source
|
||||
generator.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project uses the source code management (SCM) tool Git to manage and track Yocto
|
||||
Project files.
|
||||
Git employs branching strategies that effectively produce a tree-like structure whose
|
||||
branches represent diversions from more general code.
|
||||
For example, suppose two kernels are basically identical with the exception of a couple
|
||||
different features in each.
|
||||
In the Yocto Project source repositories managed by Git a main branch can contain the
|
||||
common or shared
|
||||
parts of the kernel source and two branches that diverge from that common branch can
|
||||
each contain the features specific to the respective kernel.
|
||||
The result is a managed tree whose "leaves" represent the end of a specific path that yields
|
||||
a set of kernel source files necessary for a specific piece of hardware and its features.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A big advantage to this scheme is the sharing of common features by keeping them in
|
||||
"larger" branches that are further up the tree.
|
||||
This practice eliminates redundant storage of similar features shared among kernels.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When you build the kernel on your development system all files needed for the build
|
||||
are taken from the Yocto Project source repositories pointed to by the
|
||||
<filename>SRC_URI</filename> variable and gathered in a temporary work area
|
||||
where they are subsequently used to create the unique kernel.
|
||||
Thus, in a sense, the process constructs a local source tree specific to your
|
||||
kernel to generate the new kernel image - a source generator if you will.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For a complete discussion of the Yocto Project kernel's architcture and its branching strategy,
|
||||
see the <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
|
||||
The Yocto Project Kernel Architecture and Use Manual</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='kernel-modification-workflow'>
|
||||
<title>Kernel Modification Workflow</title>
|
||||
|
||||
<para>
|
||||
This illustration and the following list summarizes the kernel modification general workflow.
|
||||
</para>
|
||||
|
||||
<!-- <para>
|
||||
<imagedata fileref="figures/bsp-dev-flow.png" width="6in" depth="8.5in" align="left" scale="100" />
|
||||
</para> -->
|
||||
|
||||
<para>
|
||||
[WRITER'S NOTE: Need new flow illustration here]
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Set up your host development system to support
|
||||
development using the Yocto Project</emphasis>: See
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>
|
||||
The Linux Distributions</ulink> section and
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
|
||||
The Packages</ulink> section both
|
||||
in the Yocto Project Quick Start for requirements.
|
||||
You will also need a release of Yocto Project installed on the host.</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of the Yocto Project files on your
|
||||
system</emphasis>: You need to have the Yocto Project files available on your host system.
|
||||
Having the Yocto Project files on your system gives you access to the build
|
||||
process and tools you need.
|
||||
For information on how to get these files, see the bulleted item
|
||||
<link linkend='local-yp-release'>Yocto Project Release</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local kernel layer by copying the
|
||||
<filename>meta-skeleton</filename> layer</emphasis>: When you set up a kernel layer
|
||||
for your changes you should follow a standard layout.
|
||||
For kernel layers you can start with <filename>meta-skeleton</filename>, which
|
||||
is a minimal, base kernel layer in the local Yocto Project files.
|
||||
You can examine <filename>meta-skeleton</filename>
|
||||
in the <filename>poky</filename> Git repository.</para>
|
||||
<para>A layer is really just a location or area in which you place configuration
|
||||
fragments and recipes that modify your kernel.
|
||||
The layer, in this case, would be where all the recipes that define those dependencies
|
||||
are kept.
|
||||
The key point for a layer is that it is an isolated area that contains
|
||||
all the relevant information for the project that the Yocto Project build
|
||||
system knows about.</para>
|
||||
<para></para></listitem>
|
||||
<listitem><para><emphasis>Iteratively make kernel configuration changes
|
||||
to your local kernel layer</emphasis>: Use <filename>menuconfig</filename>
|
||||
to enable and disable the configurations to the Linux Yocto kernel.
|
||||
Using <filename>menuconfig</filename> allows you to develop and test the
|
||||
configuration changes you are making to the kernel.</para></listitem>
|
||||
<listitem><para><emphasis>Iteratively make kernel recipe changes to your new kernel
|
||||
layer</emphasis>: The standard layer structure organizes the files you need to edit in
|
||||
<filename>conf</filename> and several <filename>recipes-*</filename> within the
|
||||
layer.
|
||||
Recipe changes include altering recipes (<filename>.bb</filename> files), removing
|
||||
recipes you don't use, and adding new recipes that you need to support your hardware.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the
|
||||
changes to your kernel layer there remains a few things
|
||||
you need to do for the Yocto Project build system in order for it to create your image.
|
||||
You need to get the build environment ready by sourcing an environment setup script
|
||||
and you need to be sure two key configuration files are configured appropriately.</para>
|
||||
<para>The entire process for building an image is overviewed in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
Building an Image</ulink> section of the Yocto Project Quick Start.
|
||||
You might want to reference this information.</para></listitem>
|
||||
<listitem><para><emphasis>Build the image</emphasis>: The Yocto Project uses the BitBake
|
||||
tool to build images based on the type of image
|
||||
you want to create.
|
||||
You can find more information on BitBake
|
||||
<ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
|
||||
<para>The build process supports several types of images to satisfy different needs.
|
||||
When you issue the BitBake command you provide a “top-level” recipe that essentially
|
||||
starts the process off of building the type of image you want.</para>
|
||||
<para>[WRITER'S NOTE: Consider moving this to the Poky Reference Manual.]</para>
|
||||
<para>You can find these recipes in the <filename>meta/recipes-core/images</filename> and
|
||||
<filename>meta/recipes-sato/images</filename> directories of your local Yocto Project
|
||||
file structure (Git repository or extracted release tarball).
|
||||
Although the recipe names are somewhat explanatory, here is a list that describes them:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Base</emphasis> – A foundational basic image without support
|
||||
for X that can be reasonably used for customization.</para></listitem>
|
||||
<listitem><para><emphasis>Core</emphasis> – A foundational basic image with support for
|
||||
X that can be reasonably used for customization.</para></listitem>
|
||||
<listitem><para><emphasis>Direct Disk</emphasis> – An image that you can copy directory to
|
||||
the disk of the target device.</para></listitem>
|
||||
<listitem><para><emphasis>Live</emphasis> – An image you can run from a USB device or from
|
||||
a CD without having to first install something.</para></listitem>
|
||||
<listitem><para><emphasis>Minimal</emphasis> – A small image without a GUI.
|
||||
This image is not much more than a kernel with a shell.</para></listitem>
|
||||
<listitem><para><emphasis>Minimal Development</emphasis> – A Minimal image suitable for
|
||||
development work.</para></listitem>
|
||||
<listitem><para><emphasis>Minimal Direct Disk</emphasis> – A Minimal Direct
|
||||
Disk image.</para></listitem>
|
||||
<listitem><para><emphasis>Minimal RAM-based Initial Root Filesystem</emphasis> –
|
||||
A minimal image
|
||||
that has the <filename>initramfs</filename> as part of the kernel, which allows the
|
||||
system to find the first “init” program more efficiently.</para></listitem>
|
||||
<listitem><para><emphasis>Minimal Live</emphasis> – A Minimal Live image.</para></listitem>
|
||||
<listitem><para><emphasis>Minimal MTD Utilities</emphasis> – A minimal image that has support
|
||||
for the MTD utilities, which let the user interact with the MTD subsystem in
|
||||
the kernel to perform operations on flash devices.</para></listitem>
|
||||
<listitem><para><emphasis>Sato</emphasis> – An image with Sato support, a mobile environment
|
||||
and visual style that works well with mobile devices.</para></listitem>
|
||||
<listitem><para><emphasis>Sato Development</emphasis> – A Sato image suitable for
|
||||
development work.</para></listitem>
|
||||
<listitem><para><emphasis>Sato Direct Disk</emphasis> – A Sato Direct
|
||||
Disk image.</para></listitem>
|
||||
<listitem><para><emphasis>Sato Live</emphasis> – A Sato Live image.</para></listitem>
|
||||
<listitem><para><emphasis>Sato SDK</emphasis> – A Sato image that includes the Yocto Project
|
||||
toolchain and development libraries.</para></listitem>
|
||||
<listitem><para><emphasis>Sato SDK Direct Disk</emphasis> – A Sato SDK Direct
|
||||
Disk image.</para></listitem>
|
||||
<listitem><para><emphasis>Sato SDK Live</emphasis> – A Sato SDK Live
|
||||
image.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Make your configuration and recipe changes available
|
||||
in the kernel layer</emphasis>: Up to this point all the changes to the
|
||||
kernel have been done and tested iteratively.
|
||||
Once they are tested and ready to go you can move them into the kernel layer,
|
||||
which allows you to distribute the layer.</para></listitem>
|
||||
<listitem><para><emphasis>Make your configuration and recipe changes to the
|
||||
linux Yocto Git repository (in-tree changes)</emphasis>: If the changes you made
|
||||
are suited for all Linux Yocto users you might want to push the changes up into
|
||||
the Linux Yocto Git repository so that they become part of the kernel tree
|
||||
and available to everyone using the kernel.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find a web interface to the Yocto Project source repository at
|
||||
<ulink url='http://git.yoctoproject.org/'></ulink>.
|
||||
Within the interface you will see groups of related source code, each of which can
|
||||
be cloned using Git to result in a working Git repository on your local system
|
||||
(referred to as the "local Yocto Project files" in this manual).
|
||||
The Yocto Project supports four types of kernels in its source repositories at
|
||||
<ulink url='http://git.yoctoproject.org/'></ulink>:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The
|
||||
stable Linux Yocto kernel that is based on the Linux 2.6.34 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The current
|
||||
Linux Yocto kernel that is based on the Linux 2.6.37 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
|
||||
kernel based on the Linux 2.6.39-rc1 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-2.6</filename></emphasis> - A kernel based on
|
||||
minimal Linux mainline tracking.
|
||||
[WRITER'S NOTE: I don't know which Git repository the user needs to clone to get this
|
||||
repository on their development system.]</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
|
Loading…
Reference in New Issue