[OE-core] KBUILD_DEFCONFIG issue

Bruce Ashfield bruce.ashfield at gmail.com
Thu May 7 19:44:54 UTC 2015


On Thu, May 7, 2015 at 3:27 AM,  <Steffen.Pankratz at elektrobit.com> wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
>> Sent: Wednesday, May 06, 2015 4:00 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).
>
> [...]
>
>
>> >> >> > 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.
>
> Thank you very much in advance Bruce.
>
> I think the easiest thing would be to get poky (dizzy branch), meta-openembedded (dizzy branch) and meta-jetson-tk1 (1).
> Apply the patch I send (to patch kernel-yocto.bbclass) and build an image for MACHINE jetson-tk1.
> I was building the core-image-weston, but I think the type of image used, doesn't matter in regards to my kernel issue.
>

I've sorted this out, using the kernel tree you are using, and a hacked up
qemuarm configuration (simpler .. less rebuilds).

Turns out that the in-tree defconfig doesn't like the default mode we have
for deconfig processing (allnoconfig), since it is of the minimal variety (not
a problem).

With the patch to copy the deconfig into place (I'll post that soon for
merging), and the following addition to the linux-yocto-custom recipe:

  KCONFIG_MODE="--alldefconfig"


I'm now seeing the TEGRA options make it into the config.

Give that a try, and let me know how it goes. I am running some other local
changes here, but they won't impact this part of the process.

Cheers,

Bruce


> (1) https://bitbucket.org/kratz00/meta-jetson-tk1
>
>
> --
> 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"



More information about the Openembedded-core mailing list