[OE-core] KBUILD_DEFCONFIG issue
Steffen.Pankratz at elektrobit.com
Steffen.Pankratz at elektrobit.com
Wed May 6 13:57:28 UTC 2015
> -----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
--
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.
More information about the Openembedded-core
mailing list