BSP descriptions combine kernel types with hardware-specific features. 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:
mybsp.scc: define KMACHINE mybsp define KTYPE standard define KARCH i386 kconf mybsp.cfg
Every BSP description should define the
KMACHINE
,
KTYPE
,
and KARCH
variables.
These variables allow the OpenEmbedded build system to identify
the description as meeting the criteria set by the recipe being
built.
This simple example supports the "mybsp" machine for the "standard"
kernel and the "i386" architecture.
Be aware that a hard link between the
KTYPE
variable and a kernel type
description file does not exist.
Thus, if you do not have kernel types defined in your kernel
Metadata, you only need to ensure that the kernel recipe's
LINUX_KERNEL_TYPE
variable and the KTYPE
variable in the
BSP description file match.
KTYPE
in the BSP optional.
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" and including that description file in the BSP description file. See the "Kernel Types" section for more information.
You might also have multiple hardware configurations that you
aggregate into a single hardware description file that you
could include in the BSP description file, rather than referencing
a single .cfg
file.
Consider the following:
mybsp.scc: define KMACHINE mybsp define KTYPE standard define KARCH i386 include standard.scc include mybsp-hw.scc
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.
For information on how to break a complete
.config
file into the various
configuration fragments, see the
"Generating Configuration Files"
section.
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
Git repository:
fri2.scc: kconf hardware fri2.cfg 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
The fri2.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
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
(i.e. "standard", "preempt-rt", and "tiny").
Consider the "fri2" description for the "standard" kernel
type:
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
The include
command midway through the file
includes the fri2.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:
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" 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.
Notice again the three critical variables:
KMACHINE
, KTYPE
,
and KARCH
.
Of these variables, only the KTYPE
has changed.
It is now set to "tiny".