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