openembedded-core.git/meta/classes/kernel-yocto.bbclass, branch fido

kernel-yocto: propagate in tree defconfigs to WORKDIR

2015-06-28T08:41:53+00:00

As reported by Steffen Pankratz , the
previous logic of KBUILD_DEFCONFIG processing would not propagate an in
tree defcofig to WORKDIR if one was not already present.

We fix the propagation by copying the in tee config if a defconfig is
not already in WORKDIR.

Additionally we only warn (versus copying) if an in tree configuration
is specified, is different than the WORKDIR version and isn't copied.

(From OE-Core rev: 58cc903a5156063b24e48011438a709cb6e09f54)

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie

linux-yocto: fix race between checkout and meta data generation

2015-06-28T08:41:53+00:00

There are two tasks that must run before a linux-yocto kernel is built.

  - Kernel checkout and relocation to work-shared (kernel_checkout)
  - Meta data gathering and configuration prep (kernel_metadata)

The current task definitions for both are simply "before do_patch",
which is correct, but kernel_checkout must run before and not race with
kernel_metadata.

So we set the definition of kernel_checkout to be more specific and
enforce the proper ordering.

[YOCTO: #7731]

(From OE-Core rev: 9d806f3d05de918952f839f5e595cb71cd1261db)

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie

kernel-yocto: merge duplicate kernel_configme task definitions

2015-03-31T21:21:42+00:00

The kernel_configme task was added twice (once in the .bbclass, one in a .inc)
with different ordering constraints.

Change this to be just one definition in the bbclass with the stronger ordering
constraints.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

linux-yocto: add kern-tools-native to kernel_metadata depends

2015-03-31T21:21:42+00:00

The autobuilder failed like this:

  temp/run.do_kernel_metadata.25242: line 165: createme: command not found

createme is provided by kern-tools-native.  do_patch has a dependency on
kern-tools-native, but do_kernel_metadata runs before do_patch.  So move the
dependency from do_patch to do_kernel_metadata, moving the statement from the
.inc to the class so it's alongside the task definition.

[ YOCTO #7531 ]

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

kernel-yocto: allow in-tree defconfigs

2015-03-24T22:51:07+00:00

In a similar manner to the kernel itself, which does the following to
bring a defconfig into the configuration:

    defconfig: $(obj)/conf
    ifeq ($(KBUILD_DEFCONFIG),)
        $< --defconfig $(Kconfig)
    else
        @echo "*** Default configuration is based on '$(KBUILD_DEFCONFIG)'"
        $(Q)$< --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
    endif

We do the same with the linux-yocto configuration processing. If a
defconfig is specified via the KBUILD_DEFCONFIG variable, we copy it
from the source tree, into a common location and normalized "defconfig"
name, where the rest of the process will include and incorporate it
into the configuration process.

If the fetcher has already placed a defconfig in WORKDIR (from the
SRC_URI), we don't overwrite it, but instead warn the user that SRC_URI
defconfigs take precedence.

[YOCTO: #7474]

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie

kernel-yocto: split meta data generation from patching phase

2015-03-20T11:03:17+00:00

The linux-yocto kernel has a meta-data component which accompanies the
actual tree. That meta-data is processed to generate a series file that
controls the patching and configuration of the kernel.

patching and configuration are two distinct phases, so when working on
kernel configuration, it doesn't make sense to always have to re-run
the patching step just to update configuration data in the meta-series.

To allow a more granular set of tasks, we break the meta-data generation
into a separate task, which runs before do_patch. This allows the task
to be explicitly called when working on configuration, but otherwise
has no impact on the build.

Signed-off-by: Bruce Ashfield

kernel-yocto: inhibit BSP description warnings for custom linux-yocto kernels

2015-03-02T22:05:02+00:00

We don't require that a yocto custom kernel + defconfig have a full BSP
description (but of course it would be better if they did). Since this
isn't a requirement, we shouldn't alarm users by generating a BSP
description warning.

To implement this, we add a bsp audit level flag (like the one that
exists for kconfig audits), and only set it to activate in the versioned
linux-yocto recipes.

[YOCTO: #7370]

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie

classes/kernel-yocto: extend SRCTREECOVEREDTASKS

2015-02-23T08:08:19+00:00

* Add do_shared_workdir which was added recently
* Add do_fetch and do_unpack to this list, because at the moment if you
  enable externalsrc through a bbappend the += in this class wipes out
  the original value from externalsrc (which is set with ?=)

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

linux-yocto: warn when a generated BSP description is used

2015-02-21T22:04:23+00:00

The meta data (in tree or out of tree) that describes a BSP, its patches
and configuration is not always available when a new/default or manually
configured machine is built.

When this happens, the tools generate a skeleton BSP and use a
architecture defconfig for the build. If this is by design, the build
is typically sane and everything works fine. If an existing BSP
description was expected, chances are that the resulting kernel will not
be correct.

To avoid surprising the user when a default/skeleton BSP is used for the
build, we can make it obvious to the user by emitting a warning like
the following:

   WARNING: [kernel]: An auto generated BSP description was used, this normally indicates a misconfiguration.
            Check that your machine (myqemux86-64) has an associated kernel description.

[YOCTO: #3383]

Signed-off-by: Bruce Ashfield 
Signed-off-by: Ross Burton

linux-yocto: make kernel configuration audit user visible

2015-02-20T18:16:53+00:00

After a linux-yocto style kernel is configured, a kernel configuration
audit is executed to detect common errors or issues with the config.

This output used to be visible, but was made less obvious to not alarm
users unnecessarily (since some configuration issues are acceptable).

There are some classes of configuration issue that are worth being
visible, and that is specified configuration values that do not make the
final .config. These dropped options can result in any number of runtime
failures, so flagging them at build time makes sense.

The visibility of auditing is controlled by KCONF_AUDIT_LEVEL:

   0: no reporting
   1: report options that are specified, but not in the final config
   2: report options that are not hardware related, but set by a BSP

The default level is 1, with level 2 and above being for BSP development
only.

If these conditions are detected, warnings will be generated as follows:

  WARNING: [kernel config]: specified values did not make it into the
  kernel's final configuration:

  Value requested for CONFIG_SND_PCSP not in final ".config"
  Requested value: "CONFIG_SND_PCSP=y"
  Actual value set: ""

or

  WARNING: [kernel config]: BSP specified non-hw configuration:

  CONFIG_BLOCK
  CONFIG_CFG80211_WEXT
  CONFIG_CORDIC
  CONFIG_CRC8
  CONFIG_EFIVAR_FS
  CONFIG_EFI_PARTITION
  CONFIG_NET
  CONFIG_NETDEVICES
  CONFIG_PARTITION_ADVANCED
  CONFIG_WEXT_CORE
  CONFIG_WEXT_PROC
  CONFIG_WIRELESS

At this point thse are only a warnings, since there needs to be time for
layers and configuration fragments to be validated against this new
check.

[YOCTO: #6943]

Signed-off-by: Bruce Ashfield