mirror of
https://git.yoctoproject.org/poky
synced 2026-06-03 13:49:49 +00:00
kernel-dev: Formatted the "BSP Descriptions" section.
(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
committed by
Richard Purdie
Richard Purdie
parent
d675ef0878
commit
fe1b20f80a
@@ -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'>
|
||||||
|
fri2.scc:
|
||||||
|
kconf hardware fri2.cfg
|
||||||
|
|
||||||
mybsp.scc:
|
include cfg/x86.scc
|
||||||
define KMACHINE mybsp
|
include features/eg20t/eg20t.scc
|
||||||
define KTYPE standard
|
include cfg/dmaengine.scc
|
||||||
define KARCH i386
|
nclude 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
|
||||||
|
</literallayout>
|
||||||
|
</para>
|
||||||
|
|
||||||
include standard.scc
|
<para>
|
||||||
include mybsp.scc
|
The <filename>fri2.scc</filename> description file includes
|
||||||
|
a hardware configuration fragment
|
||||||
|
(<filename>fri2.cfg</filename>) specific to the fri2 BSP
|
||||||
|
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
|
||||||
|
|
||||||
In the above example standard.scc aggregates all the configuration fragments,
|
include ktypes/standard/standard.scc
|
||||||
patches, and features that make up your standard kernel policy whereas mybsp.scc
|
branch fri2
|
||||||
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
|
git merge emgd-1.14
|
||||||
descriptions can aggregate features. Consider the Fish River Island II (fri2)
|
|
||||||
BSP definitions from the linux-yocto-3.4 repository:
|
|
||||||
|
|
||||||
fri2.scc:
|
include fri2.scc
|
||||||
kconf hardware fri2.cfg
|
|
||||||
|
|
||||||
include cfg/x86.scc
|
# Extra fri2 configs above the minimal defined in fri2.scc
|
||||||
include features/eg20t/eg20t.scc
|
include cfg/efi-ext.scc
|
||||||
include cfg/dmaengine.scc
|
include features/drm-emgd/drm-emgd.scc
|
||||||
include features/ericsson-3g/f5521gw.scc
|
include cfg/vesafb.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
|
|
||||||
|
|
||||||
The fri2.scc description file includes a hardware configuration fragment
|
# default policy for standard kernels
|
||||||
(fri2.cfg) specific to the fri2 BSP as well as several more general
|
include cfg/usb-mass-storage.scc
|
||||||
configuration fragments and features enabling hardware found on the fri2. This
|
</literallayout>
|
||||||
description is then included in each of the three machine-ktype descriptions
|
The "include fri2.scc" line about midway through the file defines
|
||||||
(standard, preempt-rt, and tiny). Consider the fri2 standard description:
|
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.
|
||||||
|
With this branch set up, the <filename>git merge</filename> command
|
||||||
|
uses Git to merge in a feature 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 the "<link linkend='feature-branches'>Feature Branches</link>"
|
||||||
|
section for more information.
|
||||||
|
</para>
|
||||||
|
|
||||||
include ktypes/standard/standard.scc
|
<para>
|
||||||
branch fri2
|
Now consider the Fish River Island 2 tiny
|
||||||
|
(<filename>fri2-tiny</filename>) BSP description:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
fri2-tiny.scc:
|
||||||
|
define KMACHINE fri2
|
||||||
|
define KTYPE tiny
|
||||||
|
define KARCH i386
|
||||||
|
|
||||||
git merge emgd-1.14
|
include ktypes/tiny/tiny.scc
|
||||||
|
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>
|
||||||
|
|
||||||
# Extra fri2 configs above the minimal defined in fri2.scc
|
<para>
|
||||||
include cfg/efi-ext.scc
|
Notice again the three critical variables: <filename>KMACHINE</filename>,
|
||||||
include features/drm-emgd/drm-emgd.scc
|
<filename>KTYPE</filename>, and <filename>KARCH</filename>.
|
||||||
include cfg/vesafb.scc
|
Of these, only the <filename>KTYPE</filename> has changed.
|
||||||
|
It is now set to "tiny".
|
||||||
# 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
|
|
||||||
hardware enablement common to the BSP for all kernel types, duplication is
|
|
||||||
significantly reduced.
|
|
||||||
|
|
||||||
This description introduces a few more variables and commands worthy of further
|
|
||||||
discussion. Note the "branch" command which is used to create a
|
|
||||||
machine-specific branch into which source changes can be applied. With this
|
|
||||||
branch set up, the "git merge" command uses the git SCM to merge in a feature
|
|
||||||
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
|
|
||||||
branch fri2
|
|
||||||
|
|
||||||
include fri2.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 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. Note
|
|
||||||
again the three critical variables: KMACHINE, KTYPE, and KARCH. Of these, only
|
|
||||||
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
|
||||||
|
|||||||
Reference in New Issue
Block a user