| Summary: | poky-tiny distro shows Kernel config warnings during qemux86 build | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Maxin B. John <maxin.john> |
| Component: | bsps-oe-core | Assignee: | Alejandro Hernandez <alejandro.hernandez> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | brian.avery, leonardo.sandoval.gonzalez, sgw |
| Version: | 2.2 | ||
| Target Milestone: | 2.4 M1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | Add release notes for 2.2 | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Maxin B. John
2016-10-13 11:16:18 UTC
Even after updating the linux-yocto-tiny kernel to 4.8, kernel config warnings are still there. ---- diff --git a/meta-poky/conf/distro/poky-tiny.conf b/meta-poky/conf/distro/poky-tiny.conf index 4d30bde..19d9392 100644 --- a/meta-poky/conf/distro/poky-tiny.conf +++ b/meta-poky/conf/distro/poky-tiny.conf @@ -37,7 +37,7 @@ TCLIBC = "musl" # Distro config is evaluated after the machine config, so we have to explicitly # set the kernel provider to override a machine config. PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny" -PREFERRED_VERSION_linux-yocto-tiny ?= "4.4%" +PREFERRED_VERSION_linux-yocto-tiny ?= "4.8%" This is also closely related but in these case, related to warnings on BSP produced with the yocto-bsp script. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10362 Perhaps this should be a separate bug but i am unsure as to how to use these error messages. I understand we are working to eliminate them, however, i think that a way for users to have a hope of tracking down the root cause in their special cases is important as well. For example, It appears that CONFIG_BT_RFCOMM was supposed to be set from bluetooth.cfg. In the actually created kernel, the VAR is not even present in the .config. We do point out that BT_BREDR is set to no which is why it is missing. How would one track down *why* it wasn't set or why BT_BREDR was set to no? "bitbake -e core-image-minimal" with the appropriate poky-tiny and qemux86 does not shed any light on why bluetooth.cfg was ignored or overridden. Nor does "bitbake -e" track the inclusion or exclusion of kernel variables. I agree with Brian this should be easier to debug, the .config is created within the kernel_configme task, where it calls the merge_config.sh script which is the one that actually does all the work, actually there is supposed to be a log file (which I couldn't find) but according to the script it should be located on the kernel-meta/cfg directory and called merge_config_build.log (I haven't figured out why the file isnt there yet), on this file one can see the scc/cfgs that are being looked at and the configs that are being changed, e.g.: Merging .kernel-meta/configs/standard/tiny/common-pc/features/bluetooth/bluetooth.cfg # CONFIG_BT is not set Value of CONFIG_BT is redefined by fragment .kernel-meta/configs/standard/tiny/common-pc/features/bluetooth/bluetooth.cfg: Previous value: # CONFIG_BT is not set New value: CONFIG_BT=y Now, looking at this log file I can see that the previously mentioned CONFIG values are not being changed, the example above is one CONFIG value that HAS been changed, and actually at the end of the file we can see a similar message to the one displayed by bitbake: Value requested for CONFIG_TINY_RCU not in final .config Requested value: CONFIG_TINY_RCU=y Actual value: So, the config is "created" using the merge_config.sh script; what this does is basically go through all the config fragments, and iterate looking for every CONFIG value on a default config file, and changing it to whatever we are requesting on the configuration fragments, after adding some debug statements I could see that we are actually considering (as we should) all the requested CONFIGs, for example with bluetooth.cfg: # CONFIG_BT is not set Value of CONFIG_BT is redefined by fragment .kernel-meta/configs/standard/tiny/common-pc/features/bluetooth/bluetooth.cfg: Previous value: # CONFIG_BT is not set New value: CONFIG_BT=y CHECKING CONFIG_BT_6LOWPAN on /home/aehernan/config_tmp CHECKING CONFIG_BT_RFCOMM on /home/aehernan/config_tmp CHECKING CONFIG_BT_RFCOMM_TTY on /home/aehernan/config_tmp and so on... So at the end our config_tmp file CONTAINS all the CONFIGs we have requested: CONFIG_BT=y CONFIG_BT_6LOWPAN=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y The problem comes when we actually create the new .config file using our temp file: $ make KCONFIG_ALLCONFIG=/home/aehernan/config_tmp allnoconfig GEN ./Makefile scripts/kconfig/conf --allnoconfig Kconfig # # configuration written to .config Where our newly created .config file DOES NOT contain the CONFIG variables we requested, the kernel make script is somehow (I believe on purpose) missing to include our requests, my point being that our scripts are working correctly, and to debug any further we need to check why the make script doesn't like our CONFIGs. As specified on Bug 10362 (similar), Kconfig does not like our CONFIGS because of dependency issues, I will list the warnings along with what dependency is missing and how it will be fixed: CONFIG_TINY_RCU Dependencies Missing: SMP=n PREEMPT=n How to fix it: More complicated than the others because tiny.cfg is parsed before smp.cfg, so if we fix it on tiny.cfg (which would be ideal since its specific for tiny), the value will be redefined by smp.cfg later, since tiny is based on common-pc and common-pc includes smp.cfg we need to figure out how to avoid including smp.cfg. ----------------------------------------- CONFIG_BT_6LOWPAN Dependencies Missing: BT_LE=y How to fix it: Add CONFIG_BT_LE=y to bluetooth.cfg ----------------------------------------- CONFIG_BT_RFCOMM Dependencies Missing: BT_BREDR=y How to fix it: Add CONFIG_BT_BREDR=y to bluetooth.cfg ----------------------------------------- CONFIG_BT_RFCOMM_TTY Dependencies Missing: BT_RFCOMM=y How to fix it: By adding CONFIG_BT_BREDR=y to bluetooth.cfg, the previous value (BT_RFCOMM) will have all its dependencies, hence it will become available as a dependency to BT_RFCOMM_TTY ----------------------------------------- CONFIG_BT_BNEP Dependencies Missing: BT_BREDR=y How to fix it: Add CONFIG_BT_BREDR=y to bluetooth.cfg ----------------------------------------- CONFIG_BT_BNEP_MC_FILTER Dependencies Missing: BT_BNEP=y How to fix it: By adding CONFIG_BT_BREDR=y to bluetooth.cfg, the previous value (BF_BNEP) will have all its dependencies, hence it will become available as a dependency to BT_BNEP_MC_FILTER ----------------------------------------- CONFIG_BT_BNEP_PROTO_FILTER Dependencies Missing: BT_BNEP=y How to fix it: By adding CONFIG_BT_BREDR=y to bluetooth.cfg, the previous value (BF_BNEP) will have all its dependencies, hence it will become available as a dependency to BT_BNEP_PROTO_FILTER ----------------------------------------- CONFIG_BT_CMTP Dependencies Missing: BT_BREDR=y How to fix it: Add CONFIG_BT_BREDR=y to bluetooth.cfg ----------------------------------------- CONFIG_BT_HIDP Dependencies Missing: BT_BREDR=y How to fix it: Add CONFIG_BT_BREDR=y to bluetooth.cfg ----------------------------------------- In the meantime, a patch will be sent adding CONFIG_BT_BREDR=y and CONFIG_BT_LE=y to bluetooth.cfg which will fix most of the warnings, we will need to deal with TINY_RCU later onces thats fixed. |