| Age | Commit message (Collapse) | Author |
|---|
|
This commit creates a new kernel feature to enable NTB (non transparent bridge)
network device in the BSP kernels. This ntb-netdev is used to access a network
device across the NTB bridge.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
This commit provides a feature for non-transparent-bridge which
enables the NTB kernel configuration.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
When booting qemumips and USB_UHCI_HCD built as a module, the following
trace is seen, and then prevents X from starting:
qemumips user.warn kernel: Call Trace:
qemumips user.warn kernel: [<c0028000>] uhci_check_bandwidth+0x0/0x160 [uhci_hcd]
qemumips user.warn kernel: [<c002e08c>] uhci_urb_enqueue+0xba4/0xc48 [uhci_hcd]
qemumips user.warn kernel: [<8058092c>] usb_hcd_submit_urb+0xdc/0x848
qemumips user.warn kernel: [<805b8fbc>] wacom_open+0x44/0x8c
qemumips user.warn kernel: [<805a1990>] input_open_device+0xac/0xec
qemumips user.warn kernel: [<805a8cec>] evdev_open+0x188/0x1bc
qemumips user.warn kernel: [<802331d8>] chrdev_open+0xc8/0x1c4
qemumips user.warn kernel: [<8022b338>] do_dentry_open+0x248/0x2e4
qemumips user.warn kernel: [<8022b418>] finish_open+0x44/0x68
qemumips user.warn kernel: [<8023e51c>] do_last.isra.29+0x2c0/0xcbc
qemumips user.warn kernel: [<8023efd8>] path_openat+0xc0/0x52c
qemumips user.warn kernel: [<8023f840>] do_filp_open+0x4c/0xbc
qemumips user.warn kernel: [<8022cc3c>] do_sys_open+0x128/0x20c
qemumips user.warn kernel: [<8010c07c>] stack_done+0x20/0x44
qemumips user.warn kernel: Code: (Bad address in epc)
qemumips user.warn kernel: ---[ end trace 8a48c6046870f8c2 ]---
Builing the module into the kernel fixes the problem, but the root
cause is still under investigation. The pipelines around jumps to
module addresses seem to be triggering invalid instructions.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The atom-pc preempt-rt BSP was omitting the config from common-pc,
resulting in very few drivers being built, including USB_STORAGE,
preventing preliminary boot testing.
Remove the "standard features" as those are covered by the common-pc
scc files.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
1, When do_kernel_configcheck(such as 3.8.1), it has the following warning:
log.do_kernel_configcheck:
NOTE: validating kernel config, see log.do_kernel_configcheck for details
DEBUG: [non-hardware (4)]: meta/cfg/standard/atom-pc/specified_non_hdw.cfg
This BSP sets config options that are possibly non-hardware related.
[invalid (1)]: meta/cfg/standard/atom-pc/invalid.cfg
This BSP sets config options that are not offered anywhere within this kernel
specified_non_hdw.cfg:
CONFIG_CRC_CCITT
CONFIG_STAGING
CONFIG_WEXT_PRIV
CONFIG_WIRELESS_EXT
invalid.cfg:
CONFIG_RT2860
2, CONFIG_RT2860 is invalid, because it is found in Linux kernels:
2.6.29–2.6.32, 2.6.33–2.6.39, and it is obsolete now. Use
CONFIG_RT2800PCI instead.
drivers/net/wireless/rt2x00/Kconfig:
56 config RT2800PCI
...
66 ---help---
67 This adds support for rt27xx/rt28xx/rt30xx wireless chipset family.
68 Supported chips: RT2760, RT2790, RT2860, RT2880, RT2890, RT3052,
69 RT3090, RT3091 & RT3092
3, STAGING is the menuconfig of RT2860, The menuconfig of current
RT2800PCI is RT2X00. Use CONFIG_RT2X00 instead of CONFIG_STAGING.
4, CONFIG_ATH9K_HW and CONFIG_ATH9K_COMMON could be removed,
because ATH9K has selected them.
drivers/net/wireless/ath/ath9k/Kconfig:
18 config ATH9K
...
21 select ATH9K_HW
...
25 select ATH9K_COMMON
5, CONFIG_CRC_CCITT could be removed, because RT2800PCI has
selected it.
drivers/net/wireless/rt2x00/Kconfig:
56 config RT2800PCI
...
64 select CRC_CCITT
6, CONFIG_WIRELESS_EXT and CONFIG_WEXT_PRIV do nothing which means
they don't exist in the configure file `.config', remove them.
http://cateee.net/lkddb/web-lkddb/RT2860.html
http://cateee.net/lkddb/web-lkddb/RT2800PCI.html
http://lxr.linux.no/linux/drivers/net/wireless/ath/ath9k/Kconfig
http://lxr.linux.no/linux/drivers/net/wireless/rt2x00/Kconfig
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
|
|
To support boot methods with a single integrated kernel, but yet want
to automount root filesystems, we can build autofs into the kernel
with little extra overhead.
This also fixes some sporadic module relocation issues reported on
MIPS machines.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
============
The linux-yocto kernel is composed of additions/modifications to the
kernel.org source, plus configuration/control data to manage and use those
changes.
Source code changes are seen as git commits to the kernel source tree, are
arranged into features (sometimes) separated by branches and marked by tags.
The configuration and control data is contained within a separate branch from
source changes called the meta branch. The configuration data is contained
within the kernel-cache directory structure, and represents the instructions
to modify the source tree and the configuration policies required to configure
and build the kernel.
While changes to the source code have already been applied to the tree, the
control and configuration data is used before and during the kernel build
process to generate a valid kernel config.
This README explains the configuration data and policies around the
organization of this information, it is not a guide to tree construction, scc
file syntax or linux-yocto architecture.
2.0 Configuration Policy
========================
The configuration data contained within the meta branch has the following
purposes:
- Documents and defines hardware, non-hardware, required and optional
configuration data that are used to keep software configuration policy
and board support configuration separate. It also tags configuration data
in a manner that an audit can be performed to ensure that polices make it
to the final .config and that required options are not overridden or
dropped from the final .config.
- Creates a baseline configuration that can be inherited/included to result
in consistent configuration across all derived kernel builds
- Groups patches and their configuration data into documented features. The
proper configuration and enablement of a kernel change is coupled with the
patches that make the change to the source.
- Creates named feature fragments that when included enable the required
options to implement a specific behaviour (i.e. USB boot)
- Defines BSPs (Board Support Packages) (machines) that select a policy
(features + config) and hardware options to form a buildable, bootable
configuration.
The policies that are contained within the meta branch can be overridden by
external descriptions using the same description format as the meta branch
configuration. This allows for flexible modification and extension of the
base policy. Also, if a previously defined BSP configuration is modified, it
can be audited against the software policy to generate a compliance report.
2.1 Kernel Types (ktypes)
-------------------------
Kernel types (ktypes) are the highest level policy containers and represent
a significant set of kernel functionality that has been grouped (and named)
or partitioned.
When functionality is partitioned it indicates that the features kept apart
since they won't work together (eg: schedulers (BFS vs CFS), or security
methods (grsec vs another LSM)). Grouped functionality means that there are
many items (features, configuration) that you want to collectively call a
"kernel type" and validate that they work together, but there's no
fundamental incompatibility between these features and others in the system.
Note: ktypes or KTYPES are seen as "define KTYPE <name>" in .scc files, and
are part of a BSP definition.
There are often significant differences between kernel types in the following
ways:
- source code: large or invasive features that cannot be cleanly disabled,
or that cannot co-exist with other features at a source code level are
separated by kernel type. The preempt-rt patches, alternate schedulers,
grsecurity, are some examples of patches that are important parts of
kernel type definition.
- behaviour: A kernel type defines a default behaviour, which is often a
trade off against other options.
- performance vs. determinism
- security vs. flexibility
- size vs features
- ...
are all common parts of behavioural differences between kernel types.
- feature support: different kernel types support different sets of features,
such as XIP or different block schedulers, tracers, network devices and
power management.
- board support: due to the source, behaviour and feature differences between
kernel types, they often dictate hardware/board support. A BSP
definition declares which kernel types it supports by providing
descriptions that include a kernel type and add board support configuration
data.
Kernel types can be inherited and extended. An example inheritance tree is
below:
base: common/basic functionality, upstream features and bug fixes
|
+--- standard: selected functionality and performance profile.
| |
| +--- preempt-rt: real time extensions for the base + standard
|
+--- tiny: base functionality + few additional features with a small footprint
2.2 Kernel Features
--------------------
Kernel features are named containers for changes to the kernel (via patches
and/or configuration) that implement or enable a defined feature. A feature
can be small, or large, simple or complex, but it always represents
functionality or behaviour that can be included by other features or kernel
types.
Within the kernel-cache, kernel features are found as $FEATURE.scc files.
If a feature contains patches, it must only be included once by a given BSP
or kernel type, since including that feature applies a source change to the
tree. Including it more than once would result in the double application of
the same patches, which will fail.
If functionality is added via patches, is frequently extended by patches, or
periodically contains patches, it is typically classified as a "feature". It
should be noted, that this is only a logical distinction from Kernel
Configuration features, since the underlying mechanism is the same.
Features are often sub-categorized into a directory structure that groups
them by maintainer defined attributes such as architecture, debug, boot, etc.
Full kernel features are found under: kernel/* in the directory tree.
Patches are a feature subtype and are simply a grouping of changes into a
named category. These typically are included by kernel types, and are not
meant to implement a defined functionality or be included multiple times.
These often contain bug fixes, backports or other small changes to the kernel
tree, and do not typically contain any kernel configuration fragments.
Configuration fragments are not required, since they are fixing bugs, or
adding simple functionality that does not need Kconfig options to be
enabled.
Patches are normally arranged into a directory structure that makes their
maintenance and carry forward easier and are found under "patches/*" in
the directory structure.
2.3 Config Features
--------------------
Config features are collections of configuration options that when included
enable a specific behaviour or functionality. Configuration features do not
contain patches, and can be included multiple times by any other feature or
kernel type.
The impact of configuration groups is additive, and order matters, since the
last included config group can override the behaviour of previous includes.
Pure Config features are found under "cfg/*" in the directory structure, and
are named <$config_feature>.scc.
Configuration fragments are the actual input to the linux kernel
configuration subsystem and are included by config features. Configuration
fragments are found throughout the tree, and are ".cfg" files.
Note: Depending on the architecture of the meta data, configuration groups
can be complete or partitioned.
Example:
complete.scc
include complete.cfg
complete.cfg
CONFIG_A=y
CONFIG_B=y
partitioned.scc
include partitioned_a.cfg
include partitioned_b.cfg
partitioned_a.cfg
CONFIG_A=y
partitioned_b.cfg
CONFIG_B=y
Complete config groups contain all the options required to enable
functionality while partitioned configurations rely on multiple includes to
build up a set of non-overlapping options to enable functionality. In the
preceding example, including complete.scc or partitioned.scc will result
in the same kernel configuration.
Complete groups are simpler to include, but make it more difficult to remove
or disable an option (since it can appear multiple times), while partitioned
configuration only has a single option in a single config group, but make it
more difficult to determine the right set of groups to include for the
desired functionality.
2.4 BSPs (Board Support Package)
--------------------------------
The BSP .scc files combine the policy from the kernel type with the
hardware requirements of the machine into a single place. This file
describes all the source code changes from patches and features and the
configuration changes that are used to configure and build the kernel.
There is one BSP description per kernel type that is located by a build
system when it starts the process of configuring and build a kernel for a
board.
To repeat an earlier point, one of the goals of the data in the meta branch
is the separation between software policy and board support configuration. As
such, BSP descriptions should set configuration options that are related
to physical devices (drivers, driver options, flash filesystems, error
checking, etc) and leave software policy to features or kernel types.
BSPs directly include kernel types to inherit their functionality. They
include feature and config fragments to define non-hardware configuration and
functionality. New or local configuration values introduced by a BSP should
not override non-hardware (or policy) values unless absolutely necessary, but
always should define the hardware they support.
2.5 Staged Features
-------------------
It is often desirable to manage some features independently from other
features in the tree to allow clean upstream fix integration and to avoid
managing large numbers of patches and contributions. These branches are
called "staged" features, and are included by BSP definitions by merging the
topic branch in their board description.
git merge emgd-1.14
is an example of merging a staged emgd feature into a BSP branch via a git
operation.
2.6 References
--------------
git://git.yoctoproject.org/yocto-kernel-cache
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
Nitin A Kamble
Bruce Ashfield
Darren Hart
Hongxu Jia