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

[Bruce Ashfield]

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