* [kernel config]: specified values did not make it into the kernel's final configuration @ 2015-04-03 20:34 Liam Maps 2015-04-04 18:10 ` Bruce Ashfield 0 siblings, 1 reply; 4+ messages in thread From: Liam Maps @ 2015-04-03 20:34 UTC (permalink / raw) To: yocto Hi, During the build of a core-image-base for BeagleBone using the master branch I was presented with the following warning: "WARNING: [kernel config]: specified values did not make it into the kernel's final configuration:" The full list of configuration values, which did not make it into kernel's configuration can be found here: http://pastebin.com/sAvXuNC8 Most variables seem to have something to do with things which are not applicable for my particular build and device. There is no need for any graphics so values such as CONFIG_FB_CFB_REV_PIXELS_IN_BYTE and CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY seem like they are not needed anyway. But there are a few which look less innocent such as for example CONFIG_ARCH_NR_GPIO and CONFIG_LEDS_GPIO. I did a few builds with poky-dizzy-12.0.1 before moving to the master branch and the mentioned warning was not issued during those builds. The only information about the warning I was able to find on the web is this: http://patchwork.openembedded.org/patch/89289/ So it seems that this is not that critical and somewhere during the build process some kernel configuration values are dropped. Since I do not have enough knowledge about the subject I would like to ask the more knowledgeable of you to reassure me that this warning is not critical. Also, if someone could give an example of why some values are dropped and by who/what, I would be most grateful. I should probably mention that I can successfully deploy the build despite the warnings and everything works as expected. Well, there is one thing and that is that one of requested packages is not built (ntfs-3g) but that is an issue for another thread, if I am unable to find the solution myself. Thank you. FYI: I am new to Yocto and this mailing list ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernel config]: specified values did not make it into the kernel's final configuration 2015-04-03 20:34 [kernel config]: specified values did not make it into the kernel's final configuration Liam Maps @ 2015-04-04 18:10 ` Bruce Ashfield 2015-04-04 19:55 ` Liam Maps 0 siblings, 1 reply; 4+ messages in thread From: Bruce Ashfield @ 2015-04-04 18:10 UTC (permalink / raw) To: Liam Maps; +Cc: Yocto Project Discussion On Fri, Apr 3, 2015 at 4:34 PM, Liam Maps <cca_liam_maps@mail.com> wrote: > Hi, > > During the build of a core-image-base for BeagleBone using the master branch > I was presented with the following warning: > > "WARNING: [kernel config]: specified values did not make it into the > kernel's final configuration:" > > The full list of configuration values, which did not make it into kernel's > configuration can be found here: > http://pastebin.com/sAvXuNC8 > > Most variables seem to have something to do with things which are not > applicable for my particular build and device. There is no need for any > graphics so values such as CONFIG_FB_CFB_REV_PIXELS_IN_BYTE and > CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY seem like they are not needed > anyway. But there are a few which look less innocent such as for example > CONFIG_ARCH_NR_GPIO and CONFIG_LEDS_GPIO. > > I did a few builds with poky-dizzy-12.0.1 before moving to the master branch > and the mentioned warning was not issued during those builds. > > The only information about the warning I was able to find on the web is > this: > http://patchwork.openembedded.org/patch/89289/ > > So it seems that this is not that critical and somewhere during the build > process some kernel configuration values are dropped. Since I do not have > enough knowledge about the subject I would like to ask the more > knowledgeable of you to reassure me that this warning is not critical. Also, > if someone could give an example of why some values are dropped and by > who/what, I would be most grateful. They are just that .. warnings. We have a patch for the beaglebone to clean up the input configs, it just didn't make it into master yet. Old values, values missing dependencies, etc, all may be dropped by the kernel configuration phase. The tools detect and warn if this happens, since it may be critical (i.e. boot failure) or not .. and if not, it does indicate that the input configuration fragments need some cleaning. Cheers, Bruce > > I should probably mention that I can successfully deploy the build despite > the warnings and everything works as expected. Well, there is one thing and > that is that one of requested packages is not built (ntfs-3g) but that is an > issue for another thread, if I am unable to find the solution myself. > > Thank you. > > FYI: I am new to Yocto and this mailing list > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernel config]: specified values did not make it into the kernel's final configuration 2015-04-04 18:10 ` Bruce Ashfield @ 2015-04-04 19:55 ` Liam Maps 2015-04-04 23:43 ` Bruce Ashfield 0 siblings, 1 reply; 4+ messages in thread From: Liam Maps @ 2015-04-04 19:55 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Yocto Project Discussion Thank you for the info. But who sets the .config "Requested value" of a configuration variable and who then overrides it and sets the "Actual value set"? (The quoted text is from the [kernel config] warning.) After a bit of research this is what I think I know: For my example when working with the master branch and building for BeagleBone, the CONFIG_ARCH_NR_GPIO config value gets set to 512 in the meta/cfg/kernel-cache/bsp/beaglebone/beaglebone.cfg. So the beaglebone bsp for the kernel. Somewhere that value then gets set to 0. But I can't find out where and by who. Shouldn't the bsp values be the final ones? It's the bsp who knows most about the target device after all. Or am I mistaken? Thank you. On 04/04/2015 08:10 PM, Bruce Ashfield wrote: > On Fri, Apr 3, 2015 at 4:34 PM, Liam Maps <cca_liam_maps@mail.com> wrote: >> Hi, >> >> During the build of a core-image-base for BeagleBone using the master branch >> I was presented with the following warning: >> >> "WARNING: [kernel config]: specified values did not make it into the >> kernel's final configuration:" >> >> The full list of configuration values, which did not make it into kernel's >> configuration can be found here: >> http://pastebin.com/sAvXuNC8 >> >> Most variables seem to have something to do with things which are not >> applicable for my particular build and device. There is no need for any >> graphics so values such as CONFIG_FB_CFB_REV_PIXELS_IN_BYTE and >> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY seem like they are not needed >> anyway. But there are a few which look less innocent such as for example >> CONFIG_ARCH_NR_GPIO and CONFIG_LEDS_GPIO. >> >> I did a few builds with poky-dizzy-12.0.1 before moving to the master branch >> and the mentioned warning was not issued during those builds. >> >> The only information about the warning I was able to find on the web is >> this: >> http://patchwork.openembedded.org/patch/89289/ >> >> So it seems that this is not that critical and somewhere during the build >> process some kernel configuration values are dropped. Since I do not have >> enough knowledge about the subject I would like to ask the more >> knowledgeable of you to reassure me that this warning is not critical. Also, >> if someone could give an example of why some values are dropped and by >> who/what, I would be most grateful. > They are just that .. warnings. We have a patch for the beaglebone to clean up > the input configs, it just didn't make it into master yet. > > Old values, values missing dependencies, etc, all may be dropped by the > kernel configuration phase. The tools detect and warn if this happens, since > it may be critical (i.e. boot failure) or not .. and if not, it does > indicate that > the input configuration fragments need some cleaning. > > Cheers, > > Bruce > > >> I should probably mention that I can successfully deploy the build despite >> the warnings and everything works as expected. Well, there is one thing and >> that is that one of requested packages is not built (ntfs-3g) but that is an >> issue for another thread, if I am unable to find the solution myself. >> >> Thank you. >> >> FYI: I am new to Yocto and this mailing list >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernel config]: specified values did not make it into the kernel's final configuration 2015-04-04 19:55 ` Liam Maps @ 2015-04-04 23:43 ` Bruce Ashfield 0 siblings, 0 replies; 4+ messages in thread From: Bruce Ashfield @ 2015-04-04 23:43 UTC (permalink / raw) To: Liam Maps; +Cc: Yocto Project Discussion On Sat, Apr 4, 2015 at 3:55 PM, Liam Maps <cca_liam_maps@mail.com> wrote: > Thank you for the info. But who sets the .config "Requested value" of a > configuration variable and who then overrides it and sets the "Actual value > set"? (The quoted text is from the [kernel config] warning.) The kernel development manual covers the details, but the linux-yocto tree carries meta-data that describes the baseline BSP (patches and configuration), and then configuration fragments and more patches are applied on top based on what is specified via recipes. Either those fragments, or the baseline configuration can have kernel config values that are missing dependencies or aren't valid for a given kernel (i.e. right after a new version has been introduced, there is some initial skew to adapt to new options). I only just re-exposed the configuration audit details to the build output, so what you see now, was happening before .. it was just hidden. Now that it is visible, the motivation to keep things up to date and clean is there. > > After a bit of research this is what I think I know: > For my example when working with the master branch and building for > BeagleBone, the CONFIG_ARCH_NR_GPIO config value gets set to 512 in the > meta/cfg/kernel-cache/bsp/beaglebone/beaglebone.cfg. So the beaglebone bsp > for the kernel. Correct, that's the baseline BSP configuration I mentioned above. > Somewhere that value then gets set to 0. But I can't find out where and by > who. Shouldn't the bsp values be the final ones? It's the bsp who knows most > about the target device after all. Or am I mistaken? That's the actual kernel Kconfig* values. They have a range restriction that is changing what is specified in that fragment to a value that is valid for the kernel in question. So no matter what we set it to, the kernel configuration system (i.e. korg, not yocto) has the final say. That's more than often what you are seeing when those values change. Bruce > > Thank you. > > > > On 04/04/2015 08:10 PM, Bruce Ashfield wrote: >> >> On Fri, Apr 3, 2015 at 4:34 PM, Liam Maps <cca_liam_maps@mail.com> wrote: >>> >>> Hi, >>> >>> During the build of a core-image-base for BeagleBone using the master >>> branch >>> I was presented with the following warning: >>> >>> "WARNING: [kernel config]: specified values did not make it into the >>> kernel's final configuration:" >>> >>> The full list of configuration values, which did not make it into >>> kernel's >>> configuration can be found here: >>> http://pastebin.com/sAvXuNC8 >>> >>> Most variables seem to have something to do with things which are not >>> applicable for my particular build and device. There is no need for any >>> graphics so values such as CONFIG_FB_CFB_REV_PIXELS_IN_BYTE and >>> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY seem like they are not needed >>> anyway. But there are a few which look less innocent such as for example >>> CONFIG_ARCH_NR_GPIO and CONFIG_LEDS_GPIO. >>> >>> I did a few builds with poky-dizzy-12.0.1 before moving to the master >>> branch >>> and the mentioned warning was not issued during those builds. >>> >>> The only information about the warning I was able to find on the web is >>> this: >>> http://patchwork.openembedded.org/patch/89289/ >>> >>> So it seems that this is not that critical and somewhere during the build >>> process some kernel configuration values are dropped. Since I do not have >>> enough knowledge about the subject I would like to ask the more >>> knowledgeable of you to reassure me that this warning is not critical. >>> Also, >>> if someone could give an example of why some values are dropped and by >>> who/what, I would be most grateful. >> >> They are just that .. warnings. We have a patch for the beaglebone to >> clean up >> the input configs, it just didn't make it into master yet. >> >> Old values, values missing dependencies, etc, all may be dropped by the >> kernel configuration phase. The tools detect and warn if this happens, >> since >> it may be critical (i.e. boot failure) or not .. and if not, it does >> indicate that >> the input configuration fragments need some cleaning. >> >> Cheers, >> >> Bruce >> >> >>> I should probably mention that I can successfully deploy the build >>> despite >>> the warnings and everything works as expected. Well, there is one thing >>> and >>> that is that one of requested packages is not built (ntfs-3g) but that is >>> an >>> issue for another thread, if I am unable to find the solution myself. >>> >>> Thank you. >>> >>> FYI: I am new to Yocto and this mailing list >>> -- >>> _______________________________________________ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >> >> >> > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-04 23:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-04-03 20:34 [kernel config]: specified values did not make it into the kernel's final configuration Liam Maps 2015-04-04 18:10 ` Bruce Ashfield 2015-04-04 19:55 ` Liam Maps 2015-04-04 23:43 ` Bruce Ashfield
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.