KBUILD_DEFCONFIG issue

KBUILD_DEFCONFIG issue

[Steffen.Pankratz]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

Hi

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.
Feedback is welcome.

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?


Kind regards
-Steffen

(1) https://bitbucket.org/kratz00/meta-jetson-tk1/src
(2) http://elinux.org/JetsonTK1

--
Steffen Pankratz
Expert, Software Integration & Services

EB - Driving the Future of Software
Phone:  +49 9131 7701-6605
Fax: +49 9131 7701 6333
steffen.pankratz@elektrobit.com
http://automotive.elektrobit.com/
PGP-Key: http://keyserver.elektrobit.com/

Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors Alexander Kocher, Gregor Zink Register Court Fürth HRB 488



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


[-- Attachment #2: 0001-Fixed-KBUILD_DEFCONFIG-feature-if-no-defconfig-file-.patch --]
[-- Type: application/octet-stream, Size: 1209 bytes --]

From 09995e03340120fe532dba0d89ab82edb4289808 Mon Sep 17 00:00:00 2001
From: Steffen Pankratz <steffen.pankratz@elektrobit.com>
Date: Wed, 6 May 2015 06:41:25 +0000
Subject: [PATCH] Fixed KBUILD_DEFCONFIG feature, if no defconfig file exists

Signed-off-by: Steffen Pankratz <steffen.pankratz@elektrobit.com>
---
 meta/classes/kernel-yocto.bbclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 650ae5a..f3f0e42 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -101,10 +101,10 @@ do_kernel_metadata() {
 				cmp "${WORKDIR}/defconfig" "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
 				if [ $? -ne 0 ]; then
 					bbnote "defconfig detected in WORKDIR. ${KBUILD_DEFCONFIG} skipped"
-				else
-					cp -f ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
-					sccs="${WORKDIR}/defconfig"
 				fi
+			else
+				cp -f ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
+				sccs="${WORKDIR}/defconfig"
 			fi
 		else
 			bbfatal "A KBUILD_DECONFIG '${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
-- 
1.9.1

Re: KBUILD_DEFCONFIG issue

[Bruce Ashfield]

On Wed, May 6, 2015 at 3:10 AM,  <Steffen.Pankratz@elektrobit.com> wrote:
> Hi
>
> 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.

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.

> Feedback is welcome.
>
> 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.

Cheers,

Bruce

>
>
> Kind regards
> -Steffen
>
> (1) https://bitbucket.org/kratz00/meta-jetson-tk1/src
> (2) http://elinux.org/JetsonTK1
>
> --
> Steffen Pankratz
> Expert, Software Integration & Services
>
> EB - Driving the Future of Software
> Phone:  +49 9131 7701-6605
> Fax: +49 9131 7701 6333
> steffen.pankratz@elektrobit.com
> http://automotive.elektrobit.com/
> PGP-Key: http://keyserver.elektrobit.com/
>
> Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors Alexander Kocher, Gregor Zink Register Court Fürth HRB 488
>
>
>
> ----------------------------------------------------------------
> 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.
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



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

Re: KBUILD_DEFCONFIG issue

[Steffen.Pankratz]

> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@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.

Re: KBUILD_DEFCONFIG issue

[Bruce Ashfield]

On Wed, May 6, 2015 at 9:28 AM,  <Steffen.Pankratz@elektrobit.com> wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@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"

Re: KBUILD_DEFCONFIG issue

[Steffen.Pankratz]

> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@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.

Re: KBUILD_DEFCONFIG issue

[Bruce Ashfield]

On Wed, May 6, 2015 at 9:57 AM,  <Steffen.Pankratz@elektrobit.com> wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@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"

Re: KBUILD_DEFCONFIG issue

[Steffen.Pankratz]

> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@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.

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

Re: KBUILD_DEFCONFIG issue

[Bruce Ashfield]

On Thu, May 7, 2015 at 3:27 AM,  <Steffen.Pankratz@elektrobit.com> wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@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"

Re: KBUILD_DEFCONFIG issue

[Steffen.Pankratz]

> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Thursday, May 07, 2015 9:45 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.

Adding ' KCONFIG_MODE="--alldefconfig"' did the trick.
Thank you very much Bruce.


-- 
Have a nice weekend
-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.