| Summary: | kern-tools add recipe defconfig to meta-series twice, breaks merge-config.sh | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Darren Hart <dvhart> |
| Component: | kernel | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | High | CC: | andrea.adami, bruce.ashfield, richard.purdie, song.liu, tom.zanussi |
| Version: | 1.2 | ||
| Target Milestone: | 1.2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | (1.2) Fixed. Requires 2d for testing. | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Darren Hart
2012-04-05 19:17:19 UTC
I've got a fix pepped. But need to run some regression tests before sending it out, it may break some other defconfig cases. The fix broke. But I've now figured out the real problem, the duplicate defconfig is wrong (and I have a fix for it), but it's not the issue. The issue here as that the linux-yocto-tiny is sitting on top of the common-pc kmachine. That kmachine is based on the x86 architecture. So when merge_config is called, it uses ARCH=i386 which completely throws away any ARM based configs and hence the POODLE options. This is what we switched in the 3.2 variant. Before this was working more by luck than by design. I need to run more tests for a better fix, but right now this is working as designed, since the base machine is an x86 variant. common-pc is only used b/c I specify KMACHINE="common-pc" as the default. If Andrea were to specify KMACHINE="", should that bypass the common-pc bits? Without it, will he still get the tiny.scc for the basic policy? Using a defconfig with tiny is also probably the wrong approach. One would expect the defconfig to trump everything, which means the defconfig is going to overwrite policy, which basically defeats the purpose of using the linux-yocto-tiny in the first place. So - what do we want to specify as "correct behavior" here? Andrea, in any event, I suspect if you want to use linux-yocto-tiny, you should be using config fragments to enable your hardware rather than a defconfig. ie: SRC_URI += " poodle.cfg" Which defines the options and their dependencies that you specifically care about, and nothing else, leaving the policy to the linux-yocto-tiny meta-data. Using a defconfig on top of tiny wouldn't be the correct approach, since it fundamentally throws out all of the tuning and policy that has been crafted for tiny. It really does just need to be a fragment adding whatever extras or board specific parts really need to be added. If you really want a defconfig, and only want the userspace or other tiny parts of the tiny distro, it is best to just stick with linux-yocto or another custom kernel recipe. And definitely, the default KMACHINE of common-pc is what is triggering the config to behave as it is (and it's working properly). Setting KMACHINE at a minimum to be another ARM board, or creating a quick out of tree BSP description would be required if KMACHINE changes to something that isn't already in the tree. What I'm considering is if it is worth doing anything special to allow generic machines to pickup the base config without this. I have something that can do the above, but it's hard to disentangle from other post 1.2 updates. I'll post a sample board description as well, but that will be a day or so, since it's a long weekend here. To make this configure as expected (with the defconfig), all you need is the following:
diff --git a/recipes-kernel/linux/linux-yocto-tiny_3.2.bbappend b/recipes-kernel/linux/linux-yocto-tiny_3.2.bbappend
index 5f5c591..1cb31f7 100644
--- a/recipes-kernel/linux/linux-yocto-tiny_3.2.bbappend
+++ b/recipes-kernel/linux/linux-yocto-tiny_3.2.bbappend
@@ -3,6 +3,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:${THISDIR}/files:"
COMPATIBLE_MACHINE = "poodle"
SRC_URI += "\
+ file://poodle-tiny.scc \
file://defconfig \
file://${LOGO_SIZE}/logo_linux_clut224.ppm.bz2 \
"
@@ -20,7 +21,7 @@ KERNEL_FEATURES = ""
## KBRANCH = "${KMACHINE}"
# NEW
-#KMACHINE = "common-pc"
+KMACHINE = "poodle"
#KBRANCH = "standard/tiny"
#LINUX_KERNEL_TYPE = "tiny"
#KCONFIG_MODE = "--allnoconfig"
-----------------------------------------
cat linux-yocto-tiny/poodle/poodle-tiny.scc
define KMACHINE poodle
define KTYPE tiny
define KARCH arm
include ktypes/tiny
---------------------------------------------
And that's it. The options end up in the final config. Change out the defconfig for a fragment
and put it in the poodle-tiny.scc file as:
kconf hardware poodle.cfg
And you'll have a poodle tiny board, reusing the standard/tiny/base branch and working
as designed.
> grep POODLE linux-poodle-tiny-build/.config
CONFIG_MACH_POODLE=y
CONFIG_SND_PXA2XX_SOC_POODLE=m
-----------------------------------------------
I'll send my duplicate defconfig patch out, but it isn't strictly required, and I'll consider if
the risk of porting kern tools changes is worth it, since we have an acceptable/designed
workflow that does need to be document .. but it valid.
one last update. It is possible to get away without defining poodle-standard.scc, as long as the KMACHINE is set to poodle, the common-pc description won't be found as applicable as a configuration base, which means an autogenerated description is used. The result is that the defconfig is still applied and a selected branch used. But this lack of specification isn't ideal, since the system can only guess so much about what is really intended. (In reply to comment #6) > one last update. It is possible to get away without defining > poodle-standard.scc, as long > as the KMACHINE is set to poodle, the common-pc description won't be found as > applicable as a configuration base, which means an autogenerated description is > used. > The result is that the defconfig is still applied and a selected branch used. > > But this lack of specification isn't ideal, since the system can only guess so > much about > what is really intended. I tested that 'quick & dirty' method and it does indeed work. Not satisfied, I spent some time and created a linux-yocto-tiny_3.2.bbappend which is also producing a valid .config. (Dev repo: https://github.com/andrea-adami/meta-handheld ) One observation: in both cases I had to re-expand the defconfigs produced by do_savedefconfig task, otherwise the provided defconfig was ignored and the resulting .config was totally wrong. (I tried to add a "yes '' | oe_runmake oldconfig" to re-expand it in do_configure_prepend but I could not inject it early enough to be considered by the kernel scripts. Probably need to be done there and not in recipe-space.) Now the last step will be to tweak the $machine.cfg and purge it of the not-hardware, undesidered fragments. I'll report the progress. Thanks again for your help. Regards Andrea The defconfig re-expansion that you required would be due to the default behaviour of using allnoconfig, if a defconfig is detected. We typically feed full defconfigs to the recipes as a technique to reset the baseline configuration and then build it back up (as a stop gap when developing policies). To do that, all configs that are not explicitly enabled should be off (hence the allnoconfig). Your minimal defconfig would be losing options due to the allnoconfig and not alldefconfig being run. That's just one reason why I typically don't use defconfigs (they count on the Kconfig and baseline being static). (In reply to comment #8) > The defconfig re-expansion that you required would be due to the default > behaviour of using allnoconfig, if a defconfig is detected. We typically feed > full defconfigs to the recipes as a technique to reset the baseline > configuration > and then build it back up (as a stop gap when developing policies). To do that, > all configs that are not explicitly enabled should be off (hence the > allnoconfig). > Your minimal defconfig would be losing options due to the allnoconfig and not > alldefconfig being run. That's just one reason why I typically don't use > defconfigs > (they count on the Kconfig and baseline being static). I see, this is the behavior in case of a provided file called 'defconfig'. Tough, it happens also when you have a 'proper' BSP with .scc and .cfg. In this case defconfig is not provided, having been renamed to $machine.cfg. Regards Andrea Hmm. I've never seen this myself, if you can provide the appends and config files somewhere accessible, I can have a closer look. (In reply to comment #10) > Hmm. I've never seen this myself, if you can provide the appends and config > files somewhere accessible, I can have a closer look. The files are under recipes-kernel in https://github.com/andrea-adami/meta-handheld In the linux-3.2 folder you'll find the minimalistic defconfigs whereby in linux-yocto-tiny are the expanded versions. Regards Andrea P.S. recipe needs a couple of fixes, one being a missing KMACHINE_spitz = "spitz" Can you clarify this for me ? "One observation: in both cases I had to re-expand the defconfigs produced by do_savedefconfig task, otherwise the provided defconfig was ignored and the resulting .config was totally wrong." I don't work with do_savedefconfig at all, so it's not something that I ever feed into the configuration process. How were you taking the output of do_savedefconfig and feeding it back into the configuration of the board ? (In reply to comment #12) > Can you clarify this for me ? > > "One observation: in both cases I had to re-expand the defconfigs produced by > do_savedefconfig task, otherwise the provided defconfig was ignored and the > resulting .config was totally wrong." > > I don't work with do_savedefconfig at all, so it's not something that I ever > feed > into the configuration process. > > How were you taking the output of do_savedefconfig and feeding it back > into the configuration of the board ? After doing bitbake -c menuconfig I do bitbake -c savedefconfig you get two files in your workdir: .config and defconfig. The latter has been processed according to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7cf3d73b4360e91b14326632ab1aeda4cb26308d I just committed those defconfigs in the respective folders of the linux recipes. Regards Andrea ok all good. I know what save_defconfig does, when you say you committed it back to the recipe, you did this as a .cfg ? If you did it as a defconfig, the behaviour I mentioned (allnoconfig) will kick in, and if it's a .cfg, it's incremental on top of the baseline config provided by the inherited kernel and features. Either way your baseline will change the way that the defconfig is processed. To work with the minimal defconfig, that would be a new mode. We want all the old configuration items thrown out, and a baseline created using alldefconfig vs allnoconfig. Which is something different than we've done before. If you take the full .config and use it, and set KCONFIG_MODE="--alldefconfig", the behaviour should be what you are looking for. I haven't tested it here, if it doesn't work, I can port a change back to the 1.2 release. my --alldeconfig suggestion won't work standalone. porting a fix to allow it. I have a set of changes prep'd for this now that fix some gaps in the 1.2 implementation: - duplicate deconfigs and patches are removed - .cfg, .scc, .patch and defconfigs are all kept in order - generation of automatic features is moved back into the tools (but is generally the same) - the include of other .scc files from recipe space include files works - --alldefconfig can be forced from a recipe .. and best of all, it configures and works for the poodle example, and the other default cases. These are legitimate issues with 1.2 and should be fixed, but this will require a day or so of testing. (In reply to comment #14) > ok all good. I know what save_defconfig does, when you say you committed it > back to the recipe, you did this as a .cfg ? > Just to be sure I did explain it properly, once expanded the poodle defconfig, I tried both ways: > If you did it as a defconfig, the behaviour I mentioned (allnoconfig) will kick > in, 1- 'quick hack', providing the file 'defconfig' in SRC_URI and setting KMACHINE_poodle = "poodle" This produces a valid .config > and if it's a .cfg, it's incremental on top of the baseline config provided by > the inherited kernel and features. Either way your baseline will change the > way that the defconfig is processed. 2- 'wannabe-yocto', renaming the defconfig to $MACHINE.cfg and providing .scc as described by you above This also produces a valid .config > > To work with the minimal defconfig, that would be a new mode. We want > all the old configuration items thrown out, and a baseline created using > alldefconfig vs allnoconfig. Which is something different than we've done > before. I see. I don't have particular interest in that. We were managing the defconfigs because of their smaller size and because it was easier to diff them. > > If you take the full .config and use it, and set KCONFIG_MODE="--alldefconfig", > the behaviour should be what you are looking for. I haven't tested it here, if > it > doesn't work, I can port a change back to the 1.2 release. The full .config has been used more for testing than for other purposes. I fully realize there are many extraneous fragments which are provided by the separate pieces of the yocto(-tiny) framework. This cleaning of the .cfg files will happen very soon. About KCONFIG_MODE="--alldefconfig", I'll have to test. It already seems doing what I am looking for. The linux-yocto-tiny_3.2 recipe in oe-core does set KCONFIG_MODE = "--allnoconfig" and I don't change it in my .bbappend. Regards Andrea |