On Fri, Aug 10, 2012 at 11:01 AM, Markus Hubig <mhu...@imko.de> wrote: > On Thu, Aug 09, 2012 at 03:10:36PM -0400, Bruce Ashfield wrote: >> On 12-08-09 01:24 PM, Bruce Ashfield wrote: >> >On 12-08-09 12:32 PM, Markus Hubig wrote: >> >>On Thu, Aug 09, 2012 at 10:48:30AM -0400, Bruce Ashfield wrote: >> >>>On Thu, Aug 9, 2012 at 10:46 AM, Markus Hubig<mhu...@imko.de> wrote: >> >> >> >>If I ran the kconf_check manually I get an output, but not a very >> >>promissing one :( >> >> >> >>| This BSP sets 4 invalid/obsolete kernel options. >> >>| These config options are not offered anywhere within this kernel. >> >>| The full list can be found in your workspace at: >> >>| linux/meta/cfg/standard/default/portuxg20/invalid.cfg >> >>| >> >>| This BSP sets 10 kernel options that are possibly non-hardware related. >> >>| The full list can be found in your workspace at: >> >>| linux/meta/cfg/standard/default/portuxg20/specified_non_hdw.cfg >> >>| >> >>| WARNING: There were 17 hardware options requested that do not >> >>| have a corresponding value present in the final ".config" file. >> >>| This probably means you aren't getting the config you wanted. >> >>| The full list can be found in your workspace at: >> >>| linux/meta/cfg/standard/default/portuxg20/mismatch.cfg >> >>| >> >>| Waiting a second to make sure you get a chance to see this... >> >>| ** NOTE: There were 0 required options requested that do not >> >> That's not all that bad for a first cut, that last "0" report is >> also fine, since nothing uses the "required" tag in denzil. > > Hmm ok ... > >> >>>If this is the same BSP, I can have a look and see about solving the >> >>>two problems at once. >> >> >> >>This would be very nice! I really stuck here ... The BSP can be found at: >> >> >> >>https://bitbucket.org/imko/meta-stamp9g20 (branch denzil) >> > >> >I have a clone and started a build. When I have some results .. I'll >> >send more email. >> >> Aha. yes, I knew this looked familiar. It's a fall out from the old >> branch based triggers for the tools. Your BSP is configuring properly, >> the report just isn't all that useful. >> >> It is (largely) fixed by this commit to the kern tools: >> >> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/commit/?id=4b5dd4d5b541ff98110e8b58f6d33923893e0950 >> >> Porting this to denzil .. may be possible, and I can give it a try, >> but I can't drag back all of the kern-tools enhancements, and many >> of the changes depend on associated changes in other scripts. > > Hmm no it's fine. I switched to 1.3_M3 and run a test build at the moment, > to give it a try ... (Hmm I actually didn't know if this commit is included > in the kernel 3.2 the 1.3_M3 branch uses ... ) > > Hmm just switching to the 1.3_M3 branch doesn't solve the warning, instead > the kernel build failed with error: > > | DEBUG: Executing shell function do_kernel_configme > | [INFO] doing kernel configme > | [INFO] Configuring target/machine combo: "standard/portuxg20" > | [INFO] collecting configs in ./meta/meta-series > | [##################################################] (completed in 4 > seconds) > | ERROR: could not sanitize configuration fragments > | errors are logged in meta/cfg/standard/portuxg20/config.log > | ERROR: Function failed: do_kernel_configme (see poky/build/tmp/work/\ > | portuxg20-poky-linux-gnueabi/linux-yocto-3.2.18+git1+ \ > | 486f7aec824b4127e91ef53228823e996b3696f0_1+\ > | 7cc31a952f78b8f8e8469eed93c23e9675a8eeb5-r4.0.1/temp/ \ > | log.do_kernel_configme.12375 for further information) > > I checked at meta/cfg/standard/portuxg20/config.log and found this: > > | ... > | [INFO] Sanitizing meta/cfg/kernel-cache/features/fuse/fuse.cfg > | [INFO] Sanitizing meta/cfg/kernel-cache/ktypes/standard/standard.cfg > | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/devtmpfs.cfg > | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/debugfs.cfg > | [INFO] Sanitizing meta/cfgportuxg20 > | [ERROR] Kern frag does not exist > > Hmm strange ... Now I cloned the tzanussi/yocto-bsp-master-update branch > from pocky-contrib (since I read the patch request from tzanussi on the ML) > and looked what his yocto-bsp script did.
That is interesting. I means something was detected as a configuration fragment ... that wasn't, or didn't get migrated to the source tree. I can reproduce this with the layer that you provided before ? > > The main difference I spotted was in stamp9g20-standard.scc > > | define KMACHINE stamp9g20 > | define KTYPE standard > | define KARCH arm > | > | include ktypes/standard > |-branch stamp9g20 > | > | include stamp9g20.scc > > But removing the branch statement didn't change the error (on the 1.3_M3 > branch) so I switched to using the shine new 3.4 kernel. > > But -> same error! OK maybe the 1.3_M3 is not that stable at all, so back > to denzil and 3.2. But with the branch statement removed ... That really is strange, Tom and I have both tested this recently. I'll need to take another look. > > Damn now I hit another strange error: > > | arm-poky-linux-gnueabi-ld: cannot find -lgcc > | make: *** [u-boot] Error 1 > | ERROR: oe_runmake failed > > See > https://bitbucket.org/imko/meta-stamp9g20/changeset/ebf8f19ea1932e1b6ed33e549023be44618481e7 > for further details ... > > And the warnings 'still stays on' ... > >> If you were to use a completely new branch (versus the re-use), the >> warning would also go a way (versus my current suggestion of >> ignoring it). > > To do this I had to make some modification to my linux-yocto_3.2.bbappend > file, like this, right? > > | COMPATIBLE_MACHINE_stamp9g20 = "stamp9g20" > | -KBRANCH_stamp9g20 = "standard/default/arm-versatile-926ejs" > | +KBRANCH_stamp9g20 = "standard/default/arm-versatile-926ejs/stamp9g20" > | +YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = > "standard/default/arm-versatile-926ejs/stamp9g20" > | KMACHINE_stamp9g20 = "stamp9g20" > > But do I need to set a YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20? In 3.2 you would. I'm out of the office today, but you shouldn't still be seeing errors with master or with 3.2. I'll do a complete build of your machine to see if bugs crept in. Cheers, Bruce > >> Was this BSP generating using the tooling, or by hand ? > > Initially I tried to build one by hand but then I learned about the yocto-bsp > so I created the BSP with the tool and included my modifications. > > Cheers, Markus > _______________________________________________ > 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" _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
