openembedded-core.git/meta/classes/kernel-arch.bbclass, branch master Mirror of openembedded-core kernel-arch.bbclass: conditional error message 2017-04-20T06:54:27+00:00 Juro Bystricky juro.bystricky@intel.com 2017-04-08T18:35:25+00:00 0b931e983b1f663d5d7dc65f1db7687334dd3ef2 The single purpose of "map_kernel_arch" is to set export ARCH = "some-arch" The case when "some-arch" is not a valid Linux architecture results in an error. This makes sense if the TARGET_OS is Linux, but that is not always the case. kernel-arch is also inherited by toolchain-script, which may be used to build toolchains for architectures not supported by Linux. Rather than modifying toolchain-script to provide its own version of "map_arch" this patch bypasses the error if the TARGET_OS is not linux. Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
The single purpose of "map_kernel_arch" is to set

   export ARCH = "some-arch"

The case when "some-arch" is not a valid Linux architecture results in an error.
This makes sense if the TARGET_OS is Linux, but that is not always the case.
kernel-arch is also inherited by toolchain-script, which may be used to build
toolchains for architectures not supported by Linux.

Rather than modifying toolchain-script to provide its own version of "map_arch"
this patch bypasses the error if the TARGET_OS is not linux.

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
kernel-arch: Lock the toolchain to use gcc compiler 2017-03-08T11:13:48+00:00 Khem Raj raj.khem@gmail.com 2017-03-02T16:54:16+00:00 75cf0f0690c9c192e4cbffb71015866f967c2e1f kernel and external modules are still using gcc to build Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
kernel and external modules are still using gcc to build

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
meta: remove True option to getVar calls 2016-12-16T08:30:03+00:00 Joshua Lock joshua.g.lock@intel.com 2016-12-14T21:13:04+00:00 7c552996597faaee2fbee185b250c0ee30ea3b5f getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
kernel-arch.bbclass: Add xtensa and arc into valid_archs table 2016-10-15T08:52:24+00:00 Juro Bystricky juro.bystricky@intel.com 2016-10-11T16:31:32+00:00 20d511cd1b7fe4891f7842be12f13a92da433c46 Both "arc" and "xtensa" are valid Linux architectures, add them into valid_archs table. Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Both "arc" and "xtensa" are valid Linux architectures, add
them into valid_archs table.

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
kernel-arch.bbclass: Add mipsisa{32, 64}r6{el, } support 2016-10-07T15:43:49+00:00 Zubair Lutfullah Kakakhel Zubair.Kakakhel@imgtec.com 2016-10-04T11:31:14+00:00 aecb57f2fd65a1bfbc2e9a23fba4984d44055c4c Add support for MIPS Release 6 ISA Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Add support for MIPS Release 6 ISA

Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Revert "kernel/kernel-arch: Explicitly mapping between i386/x86_64 and x86 for kernel ARCH" 2016-02-04T23:35:05+00:00 Ioan-Adrian Ratiu adrian.ratiu@ni.com 2016-02-02T09:01:56+00:00 bc02a478a5d4a5de7b3943ed809d5c22711f5b1f This reverts commit 8d310b24927d0f348fb431895f0583733db2aad0. That commit completely breaks KBUILD_DEFCONFIG because it relies on $ARCH to match between the target OE arch and the kernel subdirectory containing the defconfigs. In the kernel all defconfigs for everything x86-based (including x86_64) is stored in dir arch/x86/configs/ kernel-yocto.bbclass correctly searches for all the defconfigs inside ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} Commit 8d310b249 makes it search in wrong places and _only_ if you define TARGET_ARCH = "athlon" will it search x86 which is nonsensical. The commit further adds an if clause to hack the mungled kernel arches back to their original values (ugh) in do_shared_workdir which is run after do compile, but of course the build breaks before that in do_kernel_metadata because of the KBUILD_DEFCONFIG mentioned above (so that hack is useless). Please fix that corner case bug in another way which does not completely screw up the kernel arch mapping & defconfig logic. If 64bit configs are generated in the kernel for 32bit machines because the host is asked, then it it a bug in the kernel, it is of no use to hack around it in OE. Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
This reverts commit 8d310b24927d0f348fb431895f0583733db2aad0.

That commit completely breaks KBUILD_DEFCONFIG because it relies on
$ARCH to match between the target OE arch and the kernel subdirectory
containing the defconfigs. In the kernel all defconfigs for everything
x86-based (including x86_64) is stored in dir arch/x86/configs/

kernel-yocto.bbclass correctly searches for all the defconfigs inside
${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}

Commit 8d310b249 makes it search in wrong places and _only_ if you
define TARGET_ARCH = "athlon" will it search x86 which is nonsensical.

The commit further adds an if clause to hack the mungled kernel arches
back to their original values (ugh) in do_shared_workdir which is run
after do compile, but of course the build breaks before that in
do_kernel_metadata because of the KBUILD_DEFCONFIG mentioned above (so
that hack is useless).

Please fix that corner case bug in another way which does not completely
screw up the kernel arch mapping & defconfig logic. If 64bit configs are
generated in the kernel for 32bit machines because the host is asked,
then it it a bug in the kernel, it is of no use to hack around it in OE.

Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
kernel/kernel-arch: Explicitly mapping between i386/x86_64 and x86 for kernel ARCH 2016-01-15T15:44:37+00:00 Jianxun Zhang jianxun.zhang@linux.intel.com 2016-01-12T21:53:56+00:00 8d310b24927d0f348fb431895f0583733db2aad0 For a bare-bone kernel recipe which specifies 32 bit x86 target, a 64 bit .config will be generated from do_configure task when building 32-bit qemux86, once all of these conditions are true: * arch of host is x86_64 * kernel source tree used in build has commit ffee0de41 which actually chooses i386 or x86_64 defconfig by asking host when ARCH is "x86" (arch/x86/Makefile) * bare-bone kernel recipe inherits directly from kernel without other special treatments. Build will fail because of the mismatched kernel architecture. The patch sets ARCH i386 or x86_64 explicitly to configure task to avoid this host contamination. Kernel artifact is also changed so that it can map i386 and x64 back to arch/x86 when needed. Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
For a bare-bone kernel recipe which specifies 32 bit x86 target,
a 64 bit .config will be generated from do_configure task when
building 32-bit qemux86, once all of these conditions are true:

* arch of host is x86_64
* kernel source tree used in build has commit ffee0de41 which
  actually chooses i386 or x86_64 defconfig by asking host when
  ARCH is "x86" (arch/x86/Makefile)
* bare-bone kernel recipe inherits directly from kernel without
  other special treatments.

Build will fail because of the mismatched kernel architecture.

The patch sets ARCH i386 or x86_64 explicitly to configure
task to avoid this host contamination. Kernel artifact is also
changed so that it can map i386 and x64 back to arch/x86 when
needed.

Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel-arch: Add nios2 to valid archs 2015-09-21T22:05:44+00:00 Marek Vasut marex@denx.de 2015-09-19T22:43:12+00:00 f0af7d0d9316a6eeacc0686b8c4640491f255883 Add nios2 target to valid arch list definition. Based on previous work by Walter Goossens <waltergoossens@home.nl> at https://github.com/wgoossens/meta-nios2 . Signed-off-by: Marek Vasut <marex@denx.de> Cc: Walter Goossens <waltergoossens@home.nl> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Add nios2 target to valid arch list definition.

Based on previous work by Walter Goossens <waltergoossens@home.nl>
at https://github.com/wgoossens/meta-nios2 .

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Walter Goossens <waltergoossens@home.nl>
Signed-off-by: Ross Burton <ross.burton@intel.com>
kernel-arch: Force BFD kernel when using gcc for linking 2015-08-24T22:43:27+00:00 Khem Raj raj.khem@gmail.com 2015-08-19T17:44:56+00:00 5724e4d245f142ac6fb1ea211503fd220683354d We redefine LD to point to ld.bfd when building kernel, which works in most cases since kbuild system calls out for bare LD most of the time, however some of newer kernels e.g. 4.1+ have some code added which can call gcc directly to do the linking job e.g. arm vdso code This causes build failures when we have configured the default cross toolchain to use gold linker as default. Errors like BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try linking with -N | arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so[.hash]: Bad value start happening. With this patch we force gcc to choose bfd linker as well Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
We redefine LD to point to ld.bfd when building kernel, which works in
most cases since kbuild system calls out for bare LD most of the time,
however some of newer kernels e.g. 4.1+ have some code added which can
call gcc directly to do the linking job e.g. arm vdso code

This causes build failures when we have configured the default cross
toolchain to use gold linker as default. Errors like

BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
linking with -N
| arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so[.hash]: Bad
value

start happening.

With this patch we force gcc to choose bfd linker as well

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
kernel-arch: Update mapping for MicroBlaze architectures 2015-05-05T21:14:09+00:00 Nathan Rossi nathan.rossi@xilinx.com 2015-05-05T04:27:53+00:00 c2f488f629b3dd604db171772b762d46a28c2895 * Add pattern matching for the 'microblazeeb' architecture which maps to 'microblaze' in the same way as 'microblazeel' Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
* Add pattern matching for the 'microblazeeb' architecture which maps to
  'microblaze' in the same way as 'microblazeel'

Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>