[OE-core] KBUILD_DEFCONFIG issue

[Steffen.Pankratz at elektrobit.com]

> -----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.


> 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.
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.