mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-03 13:49:49 +00:00
Code Issues Projects Releases Wiki Activity

kernel-dev: Formatted the "BSP Descriptions" section.

Browse Source 
(From yocto-docs rev: 9cfccb3372f47094479fb0a5ad095cf2b46f906e)

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
2012-12-27 14:23:23 -06:00
committed by Richard Purdie
parent d675ef0878
commit fe1b20f80a
1 changed files with 152 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/kernel-dev/kernel-dev-advanced.xml
+152 -110
View File
@@ -1016,133 +1016,175 @@ Note: It is not strictly necessary to create a ktype scc file. The BSP file can
<title>BSP Descriptions</title> <title>BSP Descriptions</title>
<para> <para>
3.3.5 BSP Descriptions BSP descriptions combine kernel types with hardware-specific
---------- features.
BSP descriptions combine kernel types (see 3.3.4) with hardware-specific The hardware specific portion is typically defined
features (see 3.3.3). The hardware specific portion is typically defined independently, and then aggregated with each supported kernel
independently, and then aggregated with each supported kernel type. Consider a type.
simple example: Consider a simple example:
<literallayout class='monospaced'>
mybsp.scc:
define KMACHINE mybsp
define KTYPE standard
define KARCH i386
mybsp.scc: kconf mybsp.cfg
define KMACHINE mybsp </literallayout>
define KTYPE standard Every BSP description should include the definition of the
define KARCH i386 <filename>KMACHINE</filename>, <filename>KTYPE</filename>,
and <filename>KARCH</filename> variables.
These variables allow the build-system to identify this
description as meeting the criteria set by the recipe being built.
This particular description can be said to support the "mybsp"
machine for the "standard" kernel type and the "i386" architecture.
Be aware that there is no hard link between the
<filename>KTYPE</filename> and a ktype description file.
If you do not have kernel types defined in your metadata, you
only need to ensure that the recipe
<filename>LINUX_KERNEL_TYPE</filename> and the
<filename>KTYPE</filename> here match.
<note>
Future versions of the tooling make the specification of
<filename>KTYPE</filename> in the BSP optional.
</note>
</para>
kconf mybsp.cfg <para>
If you did want to separate your kernel policy from your
hardware configuration, you could do so by specifying a kernel
type, such as "standard" (see 3.3.4) and including that
description in the BSP description.
You might also have multiple hardware configurations that you
aggregate into a single hardware description file which you
could include here, rather than referencing a single
<filename>.cfg</filename> file.
Consider the following:
<literallayout class='monospaced'>
mybsp.scc:
define KMACHINE mybsp
define KTYPE standard
define KARCH i386
Every BSP description should include the definition of the KMACHINE, KTYPE, and include standard.scc
KARCH variables. These variables allow the build-system to identify this include mybsp.scc
description as meeting the criteria set by the recipe being built. This </literallayout>
particular description can be said to support the "mybsp" machine for the </para>
"standard" kernel type and the "i386" architecture. Note that there is no hard
link between the KTYPE and a ktype description file. If you do not have kernel
types defined in your meta-data, you only need to ensure that the recipe
LINUX_KERNEL_TYPE and the KTYPE here match.
NOTE: future versions of the tooling make the specification of KTYPE in the BSP <para>
optional. In the above example, <filename>standard.scc</filename>
aggregates all the configuration fragments, patches, and
features that make up your standard kernel policy whereas
<filename>mybsp.scc</filename> aggregates all those necessary
to support the hardware available on the <filename>mybsp</filename>
machine.
For information on how to break a complete <filename>.config</filename>
into the various, see the
"<link linkend='generating-configuration-files'>Generating Configuration Files</link>"
section.
</para>
If you did want to separate your kernel policy from your hardware configuration, <para>
you could do so by specifying a kernel type, such as "standard" (see 3.3.4) and Many real-world examples are more complex.
including that description in the BSP description. You might also have multiple Like any other <filename>scc</filename> file, BSP
hardware configurations that you aggregate into a single hardware description descriptions can aggregate features.
file which you could include here, rather than referencing a single .cfg file. Consider the Fish River Island II (fri2)
Consider the following: BSP definitions from the linux-yocto-3.4 repository:
<literallayout class='monospaced'>
mybsp.scc: fri2.scc:
define KMACHINE mybsp kconf hardware fri2.cfg
define KTYPE standard
define KARCH i386
include standard.scc
include mybsp.scc
In the above example standard.scc aggregates all the configuration fragments,
patches, and features that make up your standard kernel policy whereas mybsp.scc
aggregates all those necessary to support the hardware available on the mybsp
machine. For information on how to break a complete .config into the various
fragments, see 2.3.1.
Many real-world examples are more complex. Like any other scc file, BSP
descriptions can aggregate features. Consider the Fish River Island II (fri2)
BSP definitions from the linux-yocto-3.4 repository:
fri2.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 nclude 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/iwlwifi/iwlwifi.scc
</literallayout>
</para>
The fri2.scc description file includes a hardware configuration fragment <para>
(fri2.cfg) specific to the fri2 BSP as well as several more general The <filename>fri2.scc</filename> description file includes
configuration fragments and features enabling hardware found on the fri2. This a hardware configuration fragment
description is then included in each of the three machine-ktype descriptions (<filename>fri2.cfg</filename>) specific to the fri2 BSP
(standard, preempt-rt, and tiny). Consider the fri2 standard description: as well as several more general configuration fragments and
features enabling hardware found on the fri2.
This description is then included in each of the three
machine-ktype descriptions (standard, preempt-rt, and tiny).
Consider the fri2 standard description:
<literallayout class='monospaced'>
fri2-standard.scc:
define KMACHINE fri2
define KTYPE standard
define KARCH i386
include ktypes/standard/standard.scc
branch fri2
git merge emgd-1.14
include fri2.scc
# Extra fri2 configs above the minimal defined in fri2.scc
include cfg/efi-ext.scc
include features/drm-emgd/drm-emgd.scc
include cfg/vesafb.scc
# default policy for standard kernels
include cfg/usb-mass-storage.scc
</literallayout>
The "include fri2.scc" line about midway through the file defines
all hardware enablement common to the BSP for all kernel types.
Including the statement significantly reduces duplication.
</para>
fri2-standard.scc: <para>
define KMACHINE fri2 This description introduces a few more variables and commands
define KTYPE standard worthy of further discussion.
define KARCH i386 Notice the "branch" command, which is used to create a
machine-specific branch into which source changes can be applied.
include ktypes/standard/standard.scc With this branch set up, the <filename>git merge</filename> command
branch fri2 uses Git to merge in a feature branch "emgd-1.14".
This could also be handled with the patch command, but for
git merge emgd-1.14 commonly used features such as this, feature branches can be a
convenient mechanism.
include fri2.scc See the "<link linkend='feature-branches'>Feature Branches</link>"
section for more information.
# Extra fri2 configs above the minimal defined in fri2.scc </para>
include cfg/efi-ext.scc
include features/drm-emgd/drm-emgd.scc
include cfg/vesafb.scc
# default policy for standard kernels
include cfg/usb-mass-storage.scc
Note the "include fri2.scc" line about midway through the file. By defining all <para>
hardware enablement common to the BSP for all kernel types, duplication is Now consider the Fish River Island 2 tiny
significantly reduced. (<filename>fri2-tiny</filename>) BSP description:
<literallayout class='monospaced'>
This description introduces a few more variables and commands worthy of further fri2-tiny.scc:
discussion. Note the "branch" command which is used to create a define KMACHINE fri2
machine-specific branch into which source changes can be applied. With this define KTYPE tiny
branch set up, the "git merge" command uses the git SCM to merge in a feature define KARCH i386
branch "emgd-1.14". This could also be handled with the patch command, but for
commonly used features such as this, feature branches can be a convenient
mechanism (see 3.5).
Next consider the fri2 tiny description:
fri2-tiny.scc:
define KMACHINE fri2
define KTYPE tiny
define KARCH i386
include ktypes/tiny/tiny.scc include ktypes/tiny/tiny.scc
branch fri2 branch fri2
include fri2.scc include fri2.scc
</literallayout>
As you might expect, the tiny description includes quite a bit less.
In fact, it includes only the minimal policy defined by the
tiny ktype and the hardware-specific configuration required for
boot and the most basic functionality of the system as defined in
the base fri2 description file.
</para>
As you might expect, the tiny description includes quite a bit less. In fact, <para>
it includes only the minimal policy defined by the tiny ktype and the Notice again the three critical variables: <filename>KMACHINE</filename>,
hardware-specific configuration required for boot and the most basic <filename>KTYPE</filename>, and <filename>KARCH</filename>.
functionality of the system as defined in the base fri2 description file. Note Of these, only the <filename>KTYPE</filename> has changed.
again the three critical variables: KMACHINE, KTYPE, and KARCH. Of these, only It is now set to "tiny".
the KTYPE has changed, now set to "tiny".
</para> </para>
<para> <para>
Original text: Original text:
<literallayout class='monospaced'> <literallayout class='monospaced'>
3.3.5 BSP Descriptions
----------
BSP descriptions combine kernel types (see 3.3.4) with hardware-specific BSP descriptions combine kernel types (see 3.3.4) with hardware-specific
features (see 3.3.3). The hardware specific portion is typically defined features (see 3.3.3). The hardware specific portion is typically defined
independently, and then aggregated with each supported kernel type. Consider a independently, and then aggregated with each supported kernel type. Consider a