[OE-core] KBUILD_DEFCONFIG issue

[Bruce Ashfield]

On Wed, May 6, 2015 at 9:28 AM,  <Steffen.Pankratz at elektrobit.com> wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
>> Sent: Wednesday, May 06, 2015 2:47 PM
>
> Hi Bruce
>
>> > I am in the process of creating a board support package (1) for NVIDIAs
>> Jetson TK1 board (2).
>> >
>> > In my kernel recipe I am using 'KBUILD_DEFCONFIG = "tegra_defconfig"'
>> but the build failed always.
>> >
>> > I think the issue is in do_kernel_metadata (meta/classes/kernel-
>> yocto.bbclass), if no defconfig exists, the config specified in
>> KBUILD_DEFCONFIG is never copied.
>> > Attached you will find a possible patch for this issue.
>>
>> The patch doesn't look quite right to me. It's going to inhibit an in-tree
>> config from being copied out to the workdir when it is different than the
>> defconfig that is already sitting there.
>
> That was by intention. I was following the comments above the code,
> which say 'if a defconfig exists it will not be overwritten'.
> So I changed the code that it is never overwritten and kept the warning if the configs differ.
>

I'll apply the change here and have another look, but that's not what I see
(just looking at the snippet), since we do want to overwrite it if the configs
are different.

I can tweak the comment to be clear on that point.

>
>> The conditions that currently exist where for a specific use case, and I can
>> see that having the else clause you are adding would be useful if there isn't
>> already a defconfig on the SRC_URI (which is a different case then it was
>> created do handle).
>>
>> I can take your patch and stack it on my queue with a few changes, assuming
>> that is ok with you.
>
> Feel free to do so.
>
>
>> > Another, probably unrelated problem I face right now is, that basically
>> most of the options of the tegra_defconfig get removed by kconf_check.
>> > The kernel gets build, there are no warnings that things got removed but
>> in the files in .meta/cfg/standard/jetson-tk1  I see for example:
>> >
>> > Value requested for CONFIG_ARCH_TEGRA_124_SOC not in final .config
>> Requested value:  CONFIG_ARCH_TEGRA_124_SOC=y Actual value:
>> >
>> > Any ideas?
>>
>> The checking of the defconfig is inhibited on purpose. I only added the
>> functionality as an assist/crutch for folks that haven't migrated to a base
>> config + fragments.
>>
>> A defconfig does not specify whether or not options are important for the
>> board or not, whether or not it is a full defconfig or a minimal config, etc.
>> Without that
>> extra information generating screens full of warnings isn't useful, so it isn't
>> generated at all.
>
> I am not quite sure what the correct way would be to continue and get a kernel with everything I need and want.
> The config specified in KBUILD_DEFCONFIG gets stripped of many necessary options need for the board.
> So this is obviously not the right approach.

It would be the kernel configuration subsystem that is stripping the changes
when it processes the .config (i.e. nothing in the Yocto processing of those
same fragments).

If you manually copy the defconfig into place and do a make oldconfig, are you
seeing lots of delta and questions being asked ?

Bruce

> I could not find documentation about why options and what options get removed.
> Or instead of using KBUILD_DEFCONFIG, should I specify a defconfig in SRC_URI?
> Or do I need to create fragments for all the options which got removed?
>
>
> --
> Thanks and regards
> -Steffen
>
>
> ----------------------------------------------------------------
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"