When working on the yocto-bsp and kernel-lab update for yocto 1.2
we found it was impossible for a end-user BSP to isolate patches
on a branch, since with the following commit:

  [kernel-yocto: enforce SRC_URI specified branch]

Any new branch would be switched to whatever was specified on the
SRC_URI and undoing the work that the yocto-bsp tool did to support
board specific patches.

To fix this, we'll keep the enforcing of branch consistency enabled
by default, but introduce a variable "KMETA_AUDIT" that when not
set will skip the check.

There's no impact for existing users, and it is only something that
other plumbing commands and tools will need to use (or care about).

[YOCTO: #9120]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

We only have a short description, so set SUMMARY and DESCRIPTION
will be defaulted from it.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Make nios2 kernel depend on libgcc.

In arch/nios2/Makefile, it adds LIBGCC to libs-y:

LIBGCC          := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
libs-y          += $(LIBGCC)

In file Makefile in top directory, libs-y is assigned to to var
KBUILD_VMLINUX_MAIN. It uses script link-vmlinux.sh to link vmlinux.o,
and when execute function vmlinux_link() in link-vmlinux.sh,
KBUILD_VMLINUX_MAIN is passed to ${LD}.

If build without libgcc, the value of LIBGCC is just libgcc.a without
parent directory. linux-yocto fails to build:

|   LD      vmlinux.o
| nios2-poky-linux-ld.bfd: cannot find libgcc.a: No such file or directory

Add libgcc to nios2 kernel dependency.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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 <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <bruce.ashfield@windriver.com>

linux-yocto is updated to pass the sysroot path to the compiler when necessary.

linux-yocto_ver.bb are updated to reference the correct linux-yocto branchs and
SRCREVs.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Make aarch aarch64 kernel depend on libgcc.

In arch/arm64/Makefile, it adds LIBGCC to libs-y:

LIBGCC          := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
libs-y          += $(LIBGCC)

In file Makefile in top directory, libs-y is assigned to to var
KBUILD_VMLINUX_MAIN. It uses script link-vmlinux.sh to link vmlinux.o,
and when execute function vmlinux_link() in link-vmlinux.sh,
KBUILD_VMLINUX_MAIN is passed to ${LD}.

If build without libgcc, the value of LIBGCC is just libgcc.a without
parent directory. linux-yocto fails to build:

|   LD      vmlinux.o
| aarch64-poky-linux-ld.bfd: cannot find libgcc.a: No such file or directory

Add libgcc to aarch64 kernel dependency.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>