[OE-core] KBUILD_DEFCONFIG issue

[Bruce Ashfield]

On Wed, May 6, 2015 at 9:57 AM,  <Steffen.Pankratz at elektrobit.com> wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
>> Sent: Wednesday, May 06, 2015 3:37 PM
>> To: Pankratz, Steffen
>> Cc: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] KBUILD_DEFCONFIG issue
>
>
>> >> > 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.
>
> Ok.
>
>
>> >> 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 ?
>
> I did not see any questions or deltas:
>
> bitbake virtual/kernel -c devshell
>
> Then:
>
> cp arch/arm/configs/tegra_defconfig .config
> make oldconfig

odd. Is this something I can reproduce locally ? If you email me the details,
I'll poke at it and offer some suggestions.

Bruce

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