mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-09-14 03:49:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

kernel-dev: Edits to "Build Strategy" section.

Browse Source 
This section was written before the yocto-kernel-cache strategy
existed and was thus incorrect.  I updated it with how I understand
things to work.

(From yocto-docs rev: 629f24c9312a168ddcd28b0d9dde92ff06068483)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2017-10-03 12:36:57 -07:00
committed by Richard Purdie
parent 766770aa35
commit cb9150394d
1 changed files with 63 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

101
documentation/kernel-dev/kernel-dev-maint-appx.xml
View File

@@ -56,7 +56,7 @@
<para> <para>
Once you have cloned the kernel Git repository and the Once you have cloned the kernel Git repository and the
cache of Metadata on your local machine, you can discover the cache of Metadata on your local machine, you can discover the
branches that are avilable in the repository using the following branches that are available in the repository using the following
Git command: Git command:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ git branch -a $ git branch -a
@@ -188,7 +188,7 @@
<emphasis>Clone Base Repository:</emphasis> <emphasis>Clone Base Repository:</emphasis>
The base repository is cloned, and the actions The base repository is cloned, and the actions
listed in the <filename>yocto-kernel-cache</filename> listed in the <filename>yocto-kernel-cache</filename>
irectories are applied to the tree. directories are applied to the tree.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<emphasis>Perform Cleanup:</emphasis> <emphasis>Perform Cleanup:</emphasis>
@@ -228,74 +228,99 @@
<title>Build Strategy</title> <title>Build Strategy</title>
<para> <para>
Once a local Git repository of the Yocto Project kernel exists on a development system, Once you have cloned a Yocto Linux kernel repository and the
you can consider the compilation phase of kernel development - building a kernel image. cache repository (<filename>yocto-kernel-cache</filename>) onto
Some prerequisites exist that are validated by the build process before compilation your development system, you can consider the compilation phase
starts: of kernel development, which is building a kernel image.
Some prerequisites exist that are validated by the build process
before compilation starts:
</para> </para>
<itemizedlist> <itemizedlist>
<listitem><para>The <listitem><para>
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> points The
to the kernel Git repository.</para></listitem> <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
<listitem><para>A BSP build branch exists. points to the kernel Git repository.
This branch has the following form: </para></listitem>
<listitem><para>
A BSP build branch with Metadata exists in the
<filename>yocto-kernel-cache</filename> repository.
The branch is based on the Yocto Linux kernel version and
has configurations and features grouped under the
<filename>yocto-kernel-cache/bsp</filename> directory.
For example, features and configurations for the
BeagleBone Board assuming a
<filename>linux-yocto_4.12</filename> kernel reside in the
following area of the <filename>yocto-kernel-cache</filename>
repository:
<literallayout class='monospaced'> <literallayout class='monospaced'>
<replaceable>kernel_type</replaceable>/<replaceable>bsp_name</replaceable> yocto-kernel-cache/bsp/beaglebone
</literallayout></para></listitem> </literallayout>
<note>
In the previous example, the "yocto-4.12" branch is
checked out in the <filename>yocto-kernel-cache</filename>
repository.
</note>
</para></listitem>
</itemizedlist> </itemizedlist>
<para> <para>
The OpenEmbedded build system makes sure these conditions exist before attempting compilation. The OpenEmbedded build system makes sure these conditions exist
before attempting compilation.
Other means, however, do exist, such as as bootstrapping a BSP. Other means, however, do exist, such as as bootstrapping a BSP.
</para> </para>
<para> <para>
Before building a kernel, the build process verifies the tree Before building a kernel, the build process verifies the tree
and configures the kernel by processing all of the and configures the kernel by processing all of the
configuration "fragments" specified by feature descriptions in the <filename>.scc</filename> configuration "fragments" specified by feature descriptions
files. in the <filename>.scc</filename> files.
As the features are compiled, associated kernel configuration fragments are noted As the features are compiled, associated kernel configuration
and recorded in the <filename>meta-*</filename> series of directories in their compilation order. fragments are noted and recorded in the series of directories
The fragments are migrated, pre-processed and passed to the Linux Kernel in their compilation order.
Configuration subsystem (<filename>lkc</filename>) as raw input in the form The fragments are migrated, pre-processed and passed to the
of a <filename>.config</filename> file. Linux Kernel Configuration subsystem (<filename>lkc</filename>) as
The <filename>lkc</filename> uses its own internal dependency constraints to do the final raw input in the form of a <filename>.config</filename> file.
processing of that information and generates the final <filename>.config</filename> file The <filename>lkc</filename> uses its own internal dependency
that is used during compilation. constraints to do the final processing of that information and
generates the final <filename>.config</filename> file that is used
during compilation.
</para> </para>
<para> <para>
Using the board's architecture and other relevant values from the board's template, Using the board's architecture and other relevant values from
kernel compilation is started and a kernel image is produced. the board's template, kernel compilation is started and a kernel
image is produced.
</para> </para>
<para> <para>
The other thing that you notice once you configure a kernel is that The other thing that you notice once you configure a kernel is that
the build process generates a build tree that is separate from your kernel's local Git the build process generates a build tree that is separate from
source repository tree. your kernel's local Git source repository tree.
This build tree has a name that uses the following form, where This build tree has a name that uses the following form, where
<filename>${MACHINE}</filename> is the metadata name of the machine (BSP) and "kernel_type" is one <filename>${MACHINE}</filename> is the metadata name of the
of the Yocto Project supported kernel types (e.g. "standard"): machine (BSP) and "kernel_type" is one of the Yocto Project
supported kernel types (e.g. "standard"):
<literallayout class='monospaced'> <literallayout class='monospaced'>
linux-${MACHINE}-<replaceable>kernel_type</replaceable>-build linux-${MACHINE}-<replaceable>kernel_type</replaceable>-build
</literallayout> </literallayout>
</para> </para>
<para> <para>
The existing support in the <filename>kernel.org</filename> tree achieves this The existing support in the <filename>kernel.org</filename> tree
default functionality. achieves this default functionality.
</para> </para>
<para> <para>
This behavior means that all the generated files for a particular machine or BSP are now in This behavior means that all the generated files for a particular
the build tree directory. machine or BSP are now in the build tree directory.
The files include the final <filename>.config</filename> file, all the <filename>.o</filename> The files include the final <filename>.config</filename> file,
files, the <filename>.a</filename> files, and so forth. all the <filename>.o</filename> files, the <filename>.a</filename>
files, and so forth.
Since each machine or BSP has its own separate Since each machine or BSP has its own separate
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
in its own separate branch in its own separate branch of the Git repository, you can easily
of the Git repository, you can easily switch between different builds. switch between different builds.
</para> </para>
</section> </section>
</appendix> </appendix>