[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:
>> make ARCH=$KARCH O=$BUILD_DIR \
>> 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
> SRC_URI),
> 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
needed.
Signed-off-by: Jianxun Zhang <jianxun.zhang at linux.intel.com>
diff --git a/meta/classes/kernel-arch.bbclass
b/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/
fi
- if [ -d arch/${ARCH}/include/generated ]; then
- mkdir -p $kerneldir/arch/${ARCH}/include/generated/
- cp -fR arch/${ARCH}/include/generated/*
$kerneldir/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
$kerneldir/arch/${KERNEL_SRCARCH}/include/generated/
+ cp -fR arch/${KERNEL_SRCARCH}/include/generated/*
$kerneldir/arch/${KERNEL_SRCARCH}/include/generated/
fi
}
Thanks
>>
>>
>> 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