[linux-yocto] [PATCH] configme : Match KARCH onto kernel.org arch

Jianxun Zhang jianxun.zhang at linux.intel.com
Tue Jan 12 14:32:49 PST 2016

On 01/06/2016 06:06 AM, Bruce Ashfield wrote:
> On 16-01-06 02:22 AM, Dey, Megha wrote:
>> I am trying to build the kernel(v4.3) for a 32 bit architecture. I use
>> a custom linux kernel recipe and do not use any defconfig file
>> explicitly. I expect yocto to assume the right config file based on
>> the MACHINE variable specified.
>> The config file is generated by this command in the configme script:
>>              KBUILD_DEFCONFIG=../../../$META_DIR/cfg/$KTGT/$CFGFILE \
>>              defconfig > $META_DIR/cfg/$KTGT/config.log 2>&1
> What branch are you using ... master ?
> What you quote above, shouldn't be running, it is protected by "if [ -n
> "$VERIFY_CONFIG" ]; then",
> and VERIFY_CONFIG is no longer set. The job of verifying the
> configuration is done in a separate
> script.
>> In this case, KARCH is set to x86, which leads to the expansion of
>> make ARCH=x86 defconfig, which takes the x86-64 defconfig, and thus
>> gives an error while compiling. I also use a config fragment which has
>> the configs required to build a particular test suite.
> That's the thing, any assumptions about a baseline configuration that has
> not been explicitly provided in the recipe (via a 'deconfig' on the
> or via the KBUILD_DEFCONFIG variable is doomed to never be correct. It
> breaks quickly on non-x86 arches, where the right in tree defconfig doesn't
> have a mapping to the MACHINE name.
> There is some sanity / fallback code in the createme script, that calls a
> simple script 'get_defconfig', and uses that if nothing has been provided
> by the time it is called.  That is where the defconfig that you see being
> used is found and injected into the configuration.
> Alternatively, I could make that a hard error and offer some advice via a
> warning/error message. I considered that when writing up the configuration
> processing years ago.
>> On the other hand, when we build linux-yocto, the KARCH is set to
>> i386, which results in make ARCH=i386 defconfig and a 32 bit config
>> file. Hence ,there is no error.
> The x86 kernel unification went through a lot of work to remove i386 and
> map it to x86, with config variables controlling the 32 or 64 bit elements
> of the builds. It is true that one of the last hold over's is a
> i386_defconfig,
> but it isn't something that I'd rely on. See below for ideas in that area.
>> Is there some other way to ensure a 32 bit config is generated when a
>> 32 bit MACHINE type is selected?
> Automatically, not really, at least not without creating more complex
> heuristics that
> work sometimes, and break in others.
> Configurations should be explicit, by one of the means that  I described
> above, or a
> BSP definition created that explicitly adds a kernel type, and
> configuration fragments
> to completely control (and audit) the configuration.
> Bruce
>> -----Original Message-----
>> From: Saul Wold [mailto:sgw at linux.intel.com]
>> Sent: Tuesday, January 5, 2016 9:45 PM
>> To: Ashfield, Bruce (Wind River) <bruce.ashfield at windriver.com>; Dey,
>> Megha <megha.dey at intel.com>; linux-yocto at yoctoproject.org
>> Cc: Ricardo Neri <ricardo.neri-calderon at linux.intel.com>
>> Subject: Re: [linux-yocto] [PATCH] configme : Match KARCH onto
>> kernel.org arch
>> On Tue, 2016-01-05 at 23:16 -0500, Bruce Ashfield wrote:
>>> On 2016-01-05 5:12 PM, Megha Dey wrote:
>>>> When qemux86 is selected as MACHINE type, and a custom linux kernel
>>>> is built, yocto assumes KARCH to be x86. This leads to a 64 bit
>>>> config file getting generated instead of a 32 bit one. Hence, always
>>>> make KARCH as i386 when a 32 bit MACHINE type is selected.
>>>> Signed-off-by: Megha Dey <megha.dey at intel.com>
>>>> ---
>>>>    tools/configme | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>> diff --git a/tools/configme b/tools/configme index 903b3c1..9651280
>>>> 100755
>>>> --- a/tools/configme
>>>> +++ b/tools/configme
>>>> @@ -201,6 +201,9 @@ run_board_config()
>>>>        if [ $KARCH == "mips64" ]; then
>>>>      KARCH=mips
>>>>        fi
>>>> +    if [ $KARCH == "x86" ]; then
>>>> +   KARCH=i386
>>> i386 is obsolete, and x86 should be used with the appropriate
>>> 32 bit configs.
>>> I purged all i386 references quite some time ago, since they can
>>> trigger other subtle errors.
>>> Can you elaborate on what exactly what you are building, and what
>>> fragments are in play that a 64 bit kernel is being generated
>>> incorrectly ? We always go out of our way to specify
>>> 32 or 64 bit for that reason.
>> Is this similar to the problem that Jianxun encountered and sent a
>> patch before the break to the OE-Core list
>> http://lists.openembedded.org/pipermail/openembedded-core/2015-December
>> /113708.html
>> It looks very close, we are working on validating this patch with a
>> lttng-modules failures first.

I feel this could be the same issue I was facing, I just submitted V2 
for review to the OE-core mailing list. The basic test shows the 
lttng-modules error is fixed. But I still suggest maintainer do more 
test before merging since there are multiple references around ARCH in 
poky. Pasted patch as below for your reference.
commit 3e8c03a740e2c9935057ade43fcb4e45a9b974cb
Author: Jianxun Zhang <jianxun.zhang at linux.intel.com>
Date:   Sun Nov 29 20:09:29 2015 -0800

     Explicitly mapping between i386/x86_64 and x86 for kernel ARCH

     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

     Signed-off-by: Jianxun Zhang <jianxun.zhang at linux.intel.com>

diff --git a/meta/classes/kernel-arch.bbclass 
index 3ed5986..d8b180e 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -21,7 +21,9 @@ def map_kernel_arch(a, d):

      valid_archs = d.getVar('valid_archs', True).split()

-    if   re.match('(i.86|athlon|x86.64)$', a):  return 'x86'
+    if   re.match('i.86$', a):                  return 'i386'
+    elif re.match('x86.64$', a):                return 'x86_64'
+    elif re.match('athlon$', a):                return 'x86'
      elif re.match('armeb$', a):                 return 'arm'
      elif re.match('aarch64$', a):               return 'arm64'
      elif re.match('aarch64_be$', a):            return 'arm64'
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 997376d..5c3287b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -317,9 +317,18 @@ do_shared_workdir () {
                 cp -fR include/generated/* $kerneldir/include/generated/

-       if [ -d arch/${ARCH}/include/generated ]; then
-               mkdir -p $kerneldir/arch/${ARCH}/include/generated/
-               cp -fR arch/${ARCH}/include/generated/* 
+       # When ARCH is set to i386 or x86_64, we need to map ARCH to the 
real name of src
+       # dir (x86) under arch/ of kenrel tree, so that we can find 
correct source to copy.
+       if [ "${ARCH}" = "i386" ] || [ "${ARCH}" = "x86_64" ]; then
+               KERNEL_SRCARCH=x86
+       else
+               KERNEL_SRCARCH=${ARCH}
+       fi
+       if [ -d arch/${KERNEL_SRCARCH}/include/generated ]; then
+               mkdir -p 
+               cp -fR arch/${KERNEL_SRCARCH}/include/generated/* 


>> Sau!
>>> Bruce
>>>> +    fi
>>>>        if [ -z "$BUILD_DIR" ]; then
>>>>      echo No build dir specified.  Use \"-o\" to specify one.

More information about the linux-yocto mailing list