| Age | Commit message (Collapse) | Author |
|---|
|
The Beagleboard needs the USB PHY drivers in the kernel in order to enable
USB and Ethernet functionality. This fix ensures that they are built in
by tweaking the kernel config.
Tested on Beagleboard xM Rev. C2.
Signed-off-by: Sebastian Lenartowicz <Sebastian.Lenartowicz@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Create a set of wifi features. Create a common fragment for things like
the MAC, CONFIG, and WIRELESS_EXT configs.
Create a fragment for common drivers. Create vendor/class specific
fragments where there is an obvious grouping or where a particular
driver pulls in features that are not generally useful.
Create a complete feature which includes all drivers, but do not move
existing features (such as iwl*), these can be moved under the
features/wifi directory in linux-yocto-dev and forward.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Remove the patches from the BSP scc that have been moved to
standard/base or to the minnow-io feature. The MinnowBoard BSP will
select the minnow-io feature from "recipe-space"
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The MinnowBoard GPIO keys and leds drivers are not upstreamable in their
current form, but the ACPI device description support for the correct
implementation is not yet available. Include these "boardfiles" as a
feature until such time as the proper ACPI description becomes
available.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The eg20t is an anachronism, remove it from the minnow scc.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
and config files
To create Haswell Platform (Walnut Canyon CRB) cfg & scc files
for linux-yocto_3.10 meta branch.
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
|
|
linux-yocto-3.10
This commit will turn on some legacy block drivers configuration,
e.g. SMBus, LPC-ICH, and Watchdog timer.
Signed-off-by: Chang, Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Remove namespaces-experimental.cfg since USER_NS is not experimental anymore.
Add CONFIG_USER_NS into namespaces.cfg.
Add CONFIG_MACVLAN into lxc to avoid the below missing report from
lxc-checkconfig:
|
|
Add lxc-enable.scc used by lxc feature template and lxc kernel configs.
Signed-off-by: Yang Shi <yang.shi@windriver.com>
|
|
Due to the change of x86 Kconfig, ARCH=x86 means X86_64 only, so enable
X86_32 and disable 64BIT for 32 bit x86 BSPs explicitly.
Signed-off-by: Yang Shi <yang.shi@windriver.com>
Signed-off-by: Michel Thebeau <michel.thebeau@windriver.com>
|
|
The oe-core live class now fully support compressed ISO images this is
the corresponding kernel change.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
|
Include the input.scc to get the CONFIG_INPUT_EVDEV enabled.
The evdev kernel driver is needed to create /dev/input/event* devices.
These devices are used by Xserver to connect to keyboard & mouse kind
of input devices. Without this change some of the BSPs need
AutoAddDevices = false
in their xorg.conf, which is considered as an undesired hack around
the issue.
Fixes Bug:
[YOCTO #5279]
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
Right now the CONFIG_INPUT_* options are scattered at various
places in config fragments. The plan is to get them in one place
for cleanliness.
To begin with a new feature is created with name input.scc.
And it is populated with the needed CONFIG_INPUT_EVDEV .
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
We have BSPs that reference these cfg fragments, but they were not added
to the tree in that same commit. This causes a processing error of the
64 bit mips BSPs
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Add these Kernel driver config options for Sugarbay platform.
- i915 graphics
- 8250 serial port
- usb webcam drivers
- generic power management support to enable proper suspend/resume
Fixes Bug:
[YOCTO #5117]
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
This enables broadcom wifi driver modules for the common-pc(-64)
machines.
Fixes Bug:
[YOCTO #5238]
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
The only users were the mips machines, which don't use it any more,
and it doesn't really make sense to completely disable ftrace anyway
(just don't enable it if you don't want it).
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The problem the mips machines apparently ran into was due to
CONFIG_FUNCTION_TRACER et al - no need to disable all of the tracing
infrastructure (CONFIG_FTRACE) to disable that.
Also, the ftrace-disable feature they were using disabled
CONFIG_DEBUG_KERNEL too, which is just a switch to allow other options
to be enabled but doesn't enable anything on itself, so no need for
that either.
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This turns off CONFIG_FUNCTION_TRACER, CONFIG_FUNCTION_GRAPH_TRACER,
and CONFIG_DYNAMIC_FTRACE, which can cause problems on some
architectures such as mips
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Include cfg/mips64.scc to add the support for o32 and n32
userspace binaries.
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The 64 bit common-pc BSP will not by default enable USB 3.0 devices
because it was missing the xhci fragment with the CONFIG_USB_XHCI_HCD
option. This is generally safe for a generic BSP as the driver is
properly probed and detected.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Factor out the x86_64 CPU-specific options into common-pc-64-cpu.cfg and
move any missing driver CONFIGs into common-pc-drivers.cfg. Reuse the
eth, wifi, gfx, and drivers config fragments from common-pc. Remove
common-pc-64-graphics.cfg.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Enable reuse of the drivers fragment by separating it out from the CPU
specific CONFIG options. Split common-pc.cfg into common-pc-cpu.cfg and
common-pc-drivers.cfg.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
These fragments were suffering from an identity crisis. Help them along
by keeping graphics in graphics and non-graphics in the core cfg.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Add ATH9K, RT2X00, and RT2800PCI by popular demand.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Add the 8139*, R8169, and ATL1E drivers per popular demand.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Keep the kernel size down for the common-pc BSPs and continue standard
practice, building drivers as modules. For extremely commonly used
drivers where lack of NFS booting is a commonly reported failure, leave
them as built-in (TIGON3, E1000, and PCNET32).
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Since v1
* Keep MII, TIGON3, and E1000 as built-in
|
|
Allow the reuse of these options by common-pc-64 and
provide a clear location for making networking configuration changes.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Some driver configs have changed and they should be updated to
adapt to the latest kernel.
Signed-off-by: Simarpreet Singh <simar@linux.com>
Signed-off-by: Liming Wang <liming.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
When collapsing standard-nocfg back into standard.scc, the configuration
block for the kernel type was put with the smaller features. This is
incorrect, and it should be a the top, giving indvidual feature and architecture
blocks the ability to override baseline settings.
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>
|
Bruce Ashfield
Darren Hart
Laurentiu Palcu
Ong Boon Leong
Chang, Rebecca Swee Fun
Yang Shi
Jason Wessel
Nitin A Kamble
Tom Zanussi
Jackie Huang
Liming Wang