diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml
index 9b35a422db..c3bda983b2 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -145,9 +145,9 @@
The value of the entries in KERNEL_FEATURES
are dependent on their location within the kernel Metadata itself.
- The examples here are taken from the
- linux-yocto-3.4 repository where "features"
- and "cfg" are subdirectories within the
+ The examples here are taken from the meta
+ branch of the linux-yocto-3.19 repository.
+ Within that branch, "features" and "cfg" are subdirectories of the
meta/cfg/kernel-cache directory.
For more information, see the
"Kernel Metadata Syntax" section.
@@ -442,22 +442,27 @@
feature.
This feature consists of one or more Linux kernel configuration
parameters in a configuration fragment file
- (.cfg) and an .scc file
+ (.cfg) and a .scc file
that describes the fragment.
The Symmetric Multi-Processing (SMP) fragment included in the
- linux-yocto-3.4 Git repository
+ linux-yocto-3.19 Git repository
consists of the following two files:
cfg/smp.scc:
define KFEATURE_DESCRIPTION "Enable SMP"
+ define KFEATURE_COMPATIBILITY all
+
kconf hardware smp.cfg
cfg/smp.cfg:
CONFIG_SMP=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
You can find information on configuration fragment files in the
"Creating Configuration Fragments"
@@ -584,7 +589,7 @@
- As an example, the linux-yocto-3.4
+ As an example, the linux-yocto-3.19
tree defines three kernel types: "standard",
"tiny", and "preempt-rt":
@@ -671,15 +676,15 @@
The hardware-specific portion is typically defined
independently, and then aggregated with each supported kernel
type.
- Consider this simple BSP description that supports the "mybsp"
- machine:
+ Consider this simple BSP description that supports the
+ mybsp machine:
- mybsp.scc:
- define KMACHINE mybsp
+ mybsp.scc:
+ define KMACHINE mybsp
define KTYPE standard
define KARCH i386
- kconf mybsp.cfg
+ kconf mybsp.cfg
Every BSP description should define the
KMACHINE,
@@ -724,13 +729,13 @@
a single .cfg file.
Consider the following:
- mybsp.scc:
+ mybsp.scc:
define KMACHINE mybsp
define KTYPE standard
define KARCH i386
include standard.scc
- include mybsp-hw.scc
+ include mybsp-hw.scc
@@ -738,8 +743,10 @@
In the above example, standard.scc
aggregates all the configuration fragments, patches, and
features that make up your standard kernel policy whereas
- mybsp-hw.scc aggregates all those necessary
- to support the hardware available on the "mybsp" machine.
+ mybsp-hw.scc
+ aggregates all those necessary
+ to support the hardware available on the
+ mybsp machine.
For information on how to break a complete
.config file into the various
configuration fragments, see the
@@ -751,99 +758,98 @@
Many real-world examples are more complex.
Like any other .scc file, BSP
descriptions can aggregate features.
- Consider the Fish River Island 2 (fri2)
- BSP definition from the linux-yocto-3.4
+ Consider the Minnow BSP definition from the
+ linux-yocto-3.19
Git repository:
- fri2.scc:
- kconf hardware fri2.cfg
-
+ minnow.scc:
include cfg/x86.scc
include features/eg20t/eg20t.scc
include cfg/dmaengine.scc
- include features/ericsson-3g/f5521gw.scc
include features/power/intel.scc
include cfg/efi.scc
include features/usb/ehci-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
- The fri2.scc description file includes
+ The minnow.scc description file includes
a hardware configuration fragment
- (fri2.cfg) specific to the Fish River
- Island 2 BSP as well as several more general configuration
+ (minnow.cfg) specific to the Minnow
+ BSP as well as several more general configuration
fragments and features enabling hardware found on the
machine.
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").
- Consider the "fri2" description for the "standard" kernel
+ Consider the "minnow" description for the "standard" kernel
type:
- fri2-standard.scc:
- define KMACHINE fri2
+ minnow-standard.scc:
+ define KMACHINE minnow
define KTYPE standard
define KARCH i386
- include ktypes/standard/standard.scc
- branch fri2
+ include ktypes/standard
- git merge emgd-1.14
+ include minnow.scc
- include fri2.scc
-
- # Extra fri2 configs above the minimal defined in fri2.scc
+ # Extra minnow configs above the minimal defined in minnow.scc
include cfg/efi-ext.scc
- include features/drm-emgd/drm-emgd.scc
- include cfg/vesafb.scc
+ include features/media/media-all.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/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
The include command midway through the file
- includes the fri2.scc description that
+ includes the minnow.scc description that
defines all hardware enablements for the BSP that is common to all
kernel types.
Using this command significantly reduces duplication.
- This "fri2" standard description introduces a few more variables
- and commands that are worth further discussion.
- Notice the branch fri2 command, which creates
- a machine-specific branch into which source changes are applied.
- With this branch set up, the git merge command
- uses Git to merge in a feature branch named "emgd-1.14".
- You could also handle this with the patch
- command.
- However, for commonly used features such as this, feature branches
- are a convenient mechanism.
- See the "Feature Branches"
- section for more information.
-
-
-
- Now consider the "fri2" description for the "tiny" kernel type:
+ Now consider the "minnow" description for the "tiny" kernel type:
- fri2-tiny.scc:
- define KMACHINE fri2
+ minnow-tiny.scc:
+ define KMACHINE minnow
define KTYPE tiny
define KARCH i386
- include ktypes/tiny/tiny.scc
- branch fri2
+ include ktypes/tiny
- include fri2.scc
+ include minnow.scc
As you might expect, the "tiny" description includes quite a
bit less.
In fact, it includes only the minimal policy defined by the
"tiny" kernel type and the hardware-specific configuration required
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.
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
index 87cf2b3864..90a4f3876f 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -84,11 +84,11 @@
You also name it accordingly based on the linux-yocto recipe
you are using.
For example, if you are modifying the
- meta/recipes-kernel/linux/linux-yocto_3.4.bb
+ meta/recipes-kernel/linux/linux-yocto_3.19.bb
recipe, the append file will typically be located as follows
within your custom layer:
- your-layer/recipes-kernel/linux/linux-yocto_3.4.bbappend
+ your-layer/recipes-kernel/linux/linux-yocto_3.19.bbappend
The append file should initially extend the
FILESPATH
@@ -578,7 +578,7 @@
LINUX_VERSION:
The Linux kernel version you are using (e.g.
- "3.4").
+ "3.19").
LINUX_VERSION_EXTENSION:
The Linux kernel CONFIG_LOCALVERSION
that is compiled into the resulting kernel and visible
@@ -604,7 +604,7 @@
The combined results are a string with
the following form:
- 3.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+ 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
While lengthy, the extra verbosity in PV
helps ensure you are using the exact
@@ -844,7 +844,7 @@
Here is an example that looks at what has changed in the
emenlow branch of the
- linux-yocto-3.4 kernel.
+ linux-yocto-3.19 kernel.
The lower commit range is the commit associated with the
standard/base branch, while
the upper commit range is the commit associated with the
diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.xml b/documentation/kernel-dev/kernel-dev-maint-appx.xml
index a72dcff01b..6bb0cf6fd0 100644
--- a/documentation/kernel-dev/kernel-dev-maint-appx.xml
+++ b/documentation/kernel-dev/kernel-dev-maint-appx.xml
@@ -30,9 +30,9 @@
in the Yocto Project kernel in any clone of the Yocto Project kernel source repository
Git tree.
For example, the following command clones the Yocto Project baseline kernel that
- branched off of linux.org version 3.4:
+ branched off of linux.org version 3.19:
- $ git clone git://git.yoctoproject.org/linux-yocto-3.4
+ $ git clone git://git.yoctoproject.org/linux-yocto-3.19
For another example of how to set up a local Git repository of the Yocto Project
kernel files, see the
@@ -43,9 +43,9 @@
Once you have cloned the kernel Git repository on your local machine, you can
switch to the meta branch within the repository.
Here is an example that assumes the local Git repository for the kernel is in
- a top-level directory named linux-yocto-3.4:
+ a top-level directory named linux-yocto-3.19:
- $ cd linux-yocto-3.4
+ $ cd linux-yocto-3.19
$ git checkout -b meta origin/meta
Once you have checked out and switched to the meta branch,
@@ -135,7 +135,7 @@