This makes the external module compilation a bit more robust for
cases where external module recipes may be passing extra params
to make via EXTRA_OEMAKE, and more than often one needs to pass
M=$(PWD) when building external modules and if we use EXTRA_OEMAKE
that would mean that it would appear in do_make_scripts as well
and since we are only changing the reference kernel src tree here
it will not run the make scripts in desired directory.
It is also well explained in top makefile in kernel tree around
line# 1335 in 3.4
|else # KBUILD_EXTMOD
|
|###
|# External module support.
|# When building external modules the kernel used as basis is considered
|# read-only, and no consistency checks are made and the make
|# system is not used on the basis kernel. If updates are required
|# in the basis kernel ordinary make commands (without M=...) must
|# be used.
Therefore passing M=... will not do the updates in the basis
kernel as expected with 'make scripts' so we have to bypass EXTRA_OEMAKE
[Yocto #3787]
(From OE-Core rev: 0e0a5ee405bab478f35690e95219a1e5f2ac7aa6)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel compiler is not special and we currently have it so
we want to pass -march and -mtune options as CFLAGS to kernel
build so that compiler picks the right subarch flags when
compiling assembly files in particular. Otherwise defaults
are chosen which may not be right in many case e.g. when
compiling kernel for collie machine we should use arch=armv4
but it uses toolchain/as defaults which is armv5te
in some case e.g. thumb1 we know that kernel can not be compiled
in thumb1 mode so we can provide that information e.g. -marm
option through KERNEL_HOST_CC_ARCH variable as we do now
(From OE-Core rev: c49f967384ccbfe131bbb33ee518014f3fc4b38f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's sometimes useful to have this function available to recipes which
don't wish to use module.bbclass for whatever reason.
(From OE-Core rev: 7632b44e7f487180811d47fbe9c29aa8e58868a2)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_LD was using ${LD} in it's definition, which is not correct for
different ABIs such as x32 or i386 on x86_64 machine. This brings it
into sync with the corresponding gcc settings, likewise the same with
the KERNEL_AR variable.
[RP: Updated commit message]
(From OE-Core rev: 9c525241c564a458db8ecd9ba325edeb13ec1c58)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel-source do not exist in STAGING_KERNEL_DIR any longer.
Remove the exported KERNEL_SOURCE as the STAGING_KERNEL_DIR can
be used in module recipes directly.
(From OE-Core rev: b67ef579db4c1906d6e508a8451cd2b01b7b62ab)
Signed-off-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Khem Raj
Phil Blundell
Nitin A Kamble
Anders Darander
Marcin Juszkiewicz
Richard Purdie