sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

kernel-dev: Scrubbed out the 3.4 kernel references. 

This kernel is not supported and is ancient.  Many of the examples
were referencing this kernel.  I switched to use the 3.19 version.

Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
(From yocto-docs rev: ba04c4f11a02b4562994d5d79838cd2cf90efc7e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2015-03-02 14:59:09 -08:00 committed by Richard Purdie
parent 043e02c5d8
commit e7e533028b
3 changed files with 77 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

128
documentation/kernel-dev/kernel-dev-advanced.xml
View File

@ -145,9 +145,9 @@
</literallayout> </literallayout>
The value of the entries in <filename>KERNEL_FEATURES</filename> The value of the entries in <filename>KERNEL_FEATURES</filename>
are dependent on their location within the kernel Metadata itself. are dependent on their location within the kernel Metadata itself.
The examples here are taken from the The examples here are taken from the <filename>meta</filename>
<filename>linux-yocto-3.4</filename> repository where "features" branch of the <filename>linux-yocto-3.19</filename> repository.
and "cfg" are subdirectories within the Within that branch, "features" and "cfg" are subdirectories of the
<filename>meta/cfg/kernel-cache</filename> directory. <filename>meta/cfg/kernel-cache</filename> directory.
For more information, see the For more information, see the
"<link linkend='kernel-metadata-syntax'>Kernel Metadata Syntax</link>" section. "<link linkend='kernel-metadata-syntax'>Kernel Metadata Syntax</link>" section.
@ -442,22 +442,27 @@
feature. feature.
This feature consists of one or more Linux kernel configuration This feature consists of one or more Linux kernel configuration
parameters in a configuration fragment file parameters in a configuration fragment file
(<filename>.cfg</filename>) and an <filename>.scc</filename> file (<filename>.cfg</filename>) and a <filename>.scc</filename> file
that describes the fragment. that describes the fragment.
</para> </para>
<para> <para>
The Symmetric Multi-Processing (SMP) fragment included in the The Symmetric Multi-Processing (SMP) fragment included in the
<filename>linux-yocto-3.4</filename> Git repository <filename>linux-yocto-3.19</filename> Git repository
consists of the following two files: consists of the following two files:
<literallayout class='monospaced'> <literallayout class='monospaced'>
cfg/smp.scc: cfg/smp.scc:
define KFEATURE_DESCRIPTION "Enable SMP" define KFEATURE_DESCRIPTION "Enable SMP"
define KFEATURE_COMPATIBILITY all
kconf hardware smp.cfg kconf hardware smp.cfg
cfg/smp.cfg: cfg/smp.cfg:
CONFIG_SMP=y CONFIG_SMP=y
CONFIG_SCHED_SMT=y CONFIG_SCHED_SMT=y
# Increase default NR_CPUS from 8 to 64 so that platform with
# more than 8 processors can be all activated at boot time
CONFIG_NR_CPUS=64
</literallayout> </literallayout>
You can find information on configuration fragment files in the You can find information on configuration fragment files in the
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-config-fragments'>Creating Configuration Fragments</ulink>" "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-config-fragments'>Creating Configuration Fragments</ulink>"
@ -584,7 +589,7 @@
</para> </para>
<para> <para>
As an example, the <filename>linux-yocto-3.4</filename> As an example, the <filename>linux-yocto-3.19</filename>
tree defines three kernel types: "standard", tree defines three kernel types: "standard",
"tiny", and "preempt-rt": "tiny", and "preempt-rt":
<itemizedlist> <itemizedlist>
@ -671,15 +676,15 @@
The hardware-specific portion is typically defined The hardware-specific portion is typically defined
independently, and then aggregated with each supported kernel independently, and then aggregated with each supported kernel
type. type.
Consider this simple BSP description that supports the "mybsp" Consider this simple BSP description that supports the
machine: <replaceable>mybsp</replaceable> machine:
<literallayout class='monospaced'> <literallayout class='monospaced'>
mybsp.scc: <replaceable>mybsp</replaceable>.scc:
define KMACHINE mybsp define KMACHINE <replaceable>mybsp</replaceable>
define KTYPE standard define KTYPE standard
define KARCH i386 define KARCH i386
kconf mybsp.cfg kconf <replaceable>mybsp</replaceable>.cfg
</literallayout> </literallayout>
Every BSP description should define the Every BSP description should define the
<ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>, <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
@ -724,13 +729,13 @@
a single <filename>.cfg</filename> file. a single <filename>.cfg</filename> file.
Consider the following: Consider the following:
<literallayout class='monospaced'> <literallayout class='monospaced'>
mybsp.scc: <replaceable>mybsp</replaceable>.scc:
define KMACHINE mybsp define KMACHINE mybsp
define KTYPE standard define KTYPE standard
define KARCH i386 define KARCH i386
include standard.scc include standard.scc
include mybsp-hw.scc include <replaceable>mybsp</replaceable>-hw.scc
</literallayout> </literallayout>
</para> </para>
@ -738,8 +743,10 @@
In the above example, <filename>standard.scc</filename> In the above example, <filename>standard.scc</filename>
aggregates all the configuration fragments, patches, and aggregates all the configuration fragments, patches, and
features that make up your standard kernel policy whereas features that make up your standard kernel policy whereas
<filename>mybsp-hw.scc</filename> aggregates all those necessary <replaceable>mybsp</replaceable><filename>-hw.scc</filename>
to support the hardware available on the "mybsp" machine. aggregates all those necessary
to support the hardware available on the
<replaceable>mybsp</replaceable> machine.
For information on how to break a complete For information on how to break a complete
<filename>.config</filename> file into the various <filename>.config</filename> file into the various
configuration fragments, see the configuration fragments, see the
@ -751,99 +758,98 @@
Many real-world examples are more complex. Many real-world examples are more complex.
Like any other <filename>.scc</filename> file, BSP Like any other <filename>.scc</filename> file, BSP
descriptions can aggregate features. descriptions can aggregate features.
Consider the Fish River Island 2 (fri2) Consider the Minnow BSP definition from the
BSP definition from the <filename>linux-yocto-3.4</filename> <filename>linux-yocto-3.19</filename>
Git repository: Git repository:
<literallayout class='monospaced'> <literallayout class='monospaced'>
fri2.scc: minnow.scc:
kconf hardware fri2.cfg
include cfg/x86.scc include cfg/x86.scc
include features/eg20t/eg20t.scc include features/eg20t/eg20t.scc
include cfg/dmaengine.scc include cfg/dmaengine.scc
include features/ericsson-3g/f5521gw.scc
include features/power/intel.scc include features/power/intel.scc
include cfg/efi.scc include cfg/efi.scc
include features/usb/ehci-hcd.scc include features/usb/ehci-hcd.scc
include features/usb/ohci-hcd.scc include features/usb/ohci-hcd.scc
include features/iwlwifi/iwlwifi.scc include features/usb/usb-gadgets.scc
include features/usb/touchscreen-composite.scc
include cfg/timer/hpet.scc
include cfg/timer/rtc.scc
include features/leds/leds.scc
include features/spi/spidev.scc
include features/i2c/i2cdev.scc
# Earlyprintk and port debug requires 8250
kconf hardware cfg/8250.cfg
kconf hardware minnow.cfg
kconf hardware minnow-dev.cfg
</literallayout> </literallayout>
</para> </para>
<para> <para>
The <filename>fri2.scc</filename> description file includes The <filename>minnow.scc</filename> description file includes
a hardware configuration fragment a hardware configuration fragment
(<filename>fri2.cfg</filename>) specific to the Fish River (<filename>minnow.cfg</filename>) specific to the Minnow
Island 2 BSP as well as several more general configuration BSP as well as several more general configuration
fragments and features enabling hardware found on the fragments and features enabling hardware found on the
machine. machine.
This description file is then included in each of the three This description file is then included in each of the three
"fri2" description files for the supported kernel types "minnow" description files for the supported kernel types
(i.e. "standard", "preempt-rt", and "tiny"). (i.e. "standard", "preempt-rt", and "tiny").
Consider the "fri2" description for the "standard" kernel Consider the "minnow" description for the "standard" kernel
type: type:
<literallayout class='monospaced'> <literallayout class='monospaced'>
fri2-standard.scc: minnow-standard.scc:
define KMACHINE fri2 define KMACHINE minnow
define KTYPE standard define KTYPE standard
define KARCH i386 define KARCH i386
include ktypes/standard/standard.scc include ktypes/standard
branch fri2
git merge emgd-1.14 include minnow.scc
include fri2.scc # Extra minnow configs above the minimal defined in minnow.scc
# Extra fri2 configs above the minimal defined in fri2.scc
include cfg/efi-ext.scc include cfg/efi-ext.scc
include features/drm-emgd/drm-emgd.scc include features/media/media-all.scc
include cfg/vesafb.scc include features/sound/snd_hda_intel.scc
# default policy for standard kernels # The following should really be in standard.scc
# USB live-image support
include cfg/usb-mass-storage.scc include cfg/usb-mass-storage.scc
include cfg/boot-live.scc
# Basic profiling
include features/latencytop/latencytop.scc
include features/profiling/profiling.scc
# Requested drivers that don't have an existing scc
kconf hardware minnow-drivers-extra.cfg
</literallayout> </literallayout>
The <filename>include</filename> command midway through the file The <filename>include</filename> command midway through the file
includes the <filename>fri2.scc</filename> description that includes the <filename>minnow.scc</filename> description that
defines all hardware enablements for the BSP that is common to all defines all hardware enablements for the BSP that is common to all
kernel types. kernel types.
Using this command significantly reduces duplication. Using this command significantly reduces duplication.
</para> </para>
<para> <para>
This "fri2" standard description introduces a few more variables Now consider the "minnow" description for the "tiny" kernel type:
and commands that are worth further discussion.
Notice the <filename>branch fri2</filename> command, which creates
a machine-specific branch into which source changes are applied.
With this branch set up, the <filename>git merge</filename> command
uses Git to merge in a feature branch named "emgd-1.14".
You could also handle this with the <filename>patch</filename>
command.
However, for commonly used features such as this, feature branches
are a convenient mechanism.
See the "<link linkend='feature-branches'>Feature Branches</link>"
section for more information.
</para>
<para>
Now consider the "fri2" description for the "tiny" kernel type:
<literallayout class='monospaced'> <literallayout class='monospaced'>
fri2-tiny.scc: minnow-tiny.scc:
define KMACHINE fri2 define KMACHINE minnow
define KTYPE tiny define KTYPE tiny
define KARCH i386 define KARCH i386
include ktypes/tiny/tiny.scc include ktypes/tiny
branch fri2
include fri2.scc include minnow.scc
</literallayout> </literallayout>
As you might expect, the "tiny" description includes quite a As you might expect, the "tiny" description includes quite a
bit less. bit less.
In fact, it includes only the minimal policy defined by the In fact, it includes only the minimal policy defined by the
"tiny" kernel type and the hardware-specific configuration required "tiny" kernel type and the hardware-specific configuration required
for booting the machine along with the most basic functionality of for booting the machine along with the most basic functionality of
the system as defined in the base "fri2" description file. the system as defined in the base "minnow" description file.
</para> </para>
<para> <para>

10
documentation/kernel-dev/kernel-dev-common.xml
View File

@ -84,11 +84,11 @@
You also name it accordingly based on the linux-yocto recipe You also name it accordingly based on the linux-yocto recipe
you are using. you are using.
For example, if you are modifying the For example, if you are modifying the
<filename>meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename> <filename>meta/recipes-kernel/linux/linux-yocto_3.19.bb</filename>
recipe, the append file will typically be located as follows recipe, the append file will typically be located as follows
within your custom layer: within your custom layer:
<literallayout class='monospaced'> <literallayout class='monospaced'>
<replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.4.bbappend <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.19.bbappend
</literallayout> </literallayout>
The append file should initially extend the The append file should initially extend the
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink> <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
@ -578,7 +578,7 @@
</para></listitem> </para></listitem>
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION'><filename>LINUX_VERSION</filename></ulink>: <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION'><filename>LINUX_VERSION</filename></ulink>:
The Linux kernel version you are using (e.g. The Linux kernel version you are using (e.g.
"3.4").</para></listitem> "3.19").</para></listitem>
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION_EXTENSION'><filename>LINUX_VERSION_EXTENSION</filename></ulink>: <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION_EXTENSION'><filename>LINUX_VERSION_EXTENSION</filename></ulink>:
The Linux kernel <filename>CONFIG_LOCALVERSION</filename> The Linux kernel <filename>CONFIG_LOCALVERSION</filename>
that is compiled into the resulting kernel and visible that is compiled into the resulting kernel and visible
@ -604,7 +604,7 @@
The combined results are a string with The combined results are a string with
the following form: the following form:
<literallayout class='monospaced'> <literallayout class='monospaced'>
3.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
</literallayout> </literallayout>
While lengthy, the extra verbosity in <filename>PV</filename> While lengthy, the extra verbosity in <filename>PV</filename>
helps ensure you are using the exact helps ensure you are using the exact
@ -844,7 +844,7 @@
<para> <para>
Here is an example that looks at what has changed in the Here is an example that looks at what has changed in the
<filename>emenlow</filename> branch of the <filename>emenlow</filename> branch of the
<filename>linux-yocto-3.4</filename> kernel. <filename>linux-yocto-3.19</filename> kernel.
The lower commit range is the commit associated with the The lower commit range is the commit associated with the
<filename>standard/base</filename> branch, while <filename>standard/base</filename> branch, while
the upper commit range is the commit associated with the the upper commit range is the commit associated with the

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

@ -30,9 +30,9 @@
in the Yocto Project kernel in any clone of the Yocto Project kernel source repository in the Yocto Project kernel in any clone of the Yocto Project kernel source repository
Git tree. Git tree.
For example, the following command clones the Yocto Project baseline kernel that For example, the following command clones the Yocto Project baseline kernel that
branched off of <filename>linux.org</filename> version 3.4: branched off of <filename>linux.org</filename> version 3.19:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/linux-yocto-3.4 $ git clone git://git.yoctoproject.org/linux-yocto-3.19
</literallayout> </literallayout>
For another example of how to set up a local Git repository of the Yocto Project For another example of how to set up a local Git repository of the Yocto Project
kernel files, see the kernel files, see the
@ -43,9 +43,9 @@
Once you have cloned the kernel Git repository on your local machine, you can Once you have cloned the kernel Git repository on your local machine, you can
switch to the <filename>meta</filename> branch within the repository. switch to the <filename>meta</filename> branch within the repository.
Here is an example that assumes the local Git repository for the kernel is in Here is an example that assumes the local Git repository for the kernel is in
a top-level directory named <filename>linux-yocto-3.4</filename>: a top-level directory named <filename>linux-yocto-3.19</filename>:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ cd linux-yocto-3.4 $ cd linux-yocto-3.19
$ git checkout -b meta origin/meta $ git checkout -b meta origin/meta
</literallayout> </literallayout>
Once you have checked out and switched to the <filename>meta</filename> branch, Once you have checked out and switched to the <filename>meta</filename> branch,
@ -135,7 +135,7 @@
<!-- <!--
<para> <para>
<emphasis>AR - Darrren Hart:</emphasis> Some parts of this section <emphasis>AR - Darren Hart:</emphasis> Some parts of this section
need to be in the need to be in the
"<link linkend='using-an-iterative-development-process'>Using an Iterative Development Process</link>" "<link linkend='using-an-iterative-development-process'>Using an Iterative Development Process</link>"
section. section.