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 KMACHINEmybsp
define KTYPE standard define KARCH i386 kconfmybsp
.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 includemybsp
-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 Minnow BSP definition from the
linux-yocto-3.19
Git repository:
minnow.scc: include cfg/x86.scc include features/eg20t/eg20t.scc include cfg/dmaengine.scc include features/power/intel.scc include cfg/efi.scc include features/usb/ehci-hcd.scc include features/usb/ohci-hcd.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 minnow.scc
description file includes
a hardware configuration fragment
(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
"minnow" description files for the supported kernel types
(i.e. "standard", "preempt-rt", and "tiny").
Consider the "minnow" description for the "standard" kernel
type:
minnow-standard.scc: define KMACHINE minnow define KTYPE standard define KARCH i386 include ktypes/standard include minnow.scc # Extra minnow configs above the minimal defined in minnow.scc include cfg/efi-ext.scc include features/media/media-all.scc include features/sound/snd_hda_intel.scc # 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 minnow.scc
description that
defines all hardware enablements for the BSP that is common to all
kernel types.
Using this command significantly reduces duplication.
Now consider the "minnow" description for the "tiny" kernel type:
minnow-tiny.scc: define KMACHINE minnow define KTYPE tiny define KARCH i386 include ktypes/tiny 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 "minnow" 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".