Re: Problem with BSP supporting different machines
Bruce Ashfield <bruce.ashfield@...>
On 12-08-09 01:24 PM, Bruce Ashfield wrote:
also fine, since nothing uses the "required" tag in denzil.
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.
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).
Was this BSP generating using the tooling, or by hand ?
Cheers,
Bruce
On 12-08-09 12:32 PM, Markus Hubig wrote:That's not all that bad for a first cut, that last "0" report isOn Thu, Aug 09, 2012 at 10:48:30AM -0400, Bruce Ashfield wrote:On Thu, Aug 9, 2012 at 10:46 AM, Markus Hubig<mhubig@...> wrote:<snip>Damn! Found the problem, just a typo :-)Comparing the output of "bitbake -e linux-yocto" for both MACHINE
settings
I notice that for stamp9g20 KMACHINE is "stamp9g20" but for
portuxg20 it's
"common-pc", which results in these "updateme" command:
| updateme --branch standard/default/arm-versatile-926ejs
-DKDESC=common-pc:standard
| --feature features/netfilter --feature features/taskstats arm
common-pc
| poky/meta-stamp9g20/recipes-kernel/linux/files/hardware.cfg
| poky/meta-stamp9g20/recipes-kernel/linux/files/non-hardware.cfg
|
poky/meta-stamp9g20/recipes-kernel/linux/files/portuxg20/portuxg20.cfg
|
poky/meta-stamp9g20/recipes-kernel/linux/files/portuxg20/portuxg20-preempt-rt.scc
|
poky/meta-stamp9g20/recipes-kernel/linux/files/portuxg20/portuxg20.scc
|
poky/meta-stamp9g20/recipes-kernel/linux/files/portuxg20/portuxg20-standard.scc
Which again (I think ...) leads to a kernel compile error ...
Unfortunately I was not able to find out why the KMACHINE variable
is not setup
correctly with my BSP for PortuxG20 ...
| -KMACHINE_portux9g20 = "portuxg20"
| +KMACHINE_portuxg20 = "portuxg20"Is this the same BSP producing the kconf check warnings on denzil ? IYes it's the same BSP and the kconf_check warnings are persistent!
ran tests this morning and denzil itself is clean, so there's definitely
something wrong in the layer.
| WARNING: Can't find any BSP hardware or required configuration
fragments.
| WARNING: Looked at
| linux/meta/cfg/standard/default/arm-versatile-926ejs/hdw_frags.txt
| and
| linux/meta/cfg/standard/default/arm-versatile-926ejs/required_frags.txt
| in directory:
| linux/meta/cfg/standard/default/arm-versatile-926ejs
As I mentiond before the files kconf_check should (IMHO) have a look
at are in:
| linux/meta/cfg/standard/default/portuxg20
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
also fine, since nothing uses the "required" tag in denzil.
Aha. yes, I knew this looked familiar. It's a fall out from the old| have a corresponding value present in the final ".config" file.I have a clone and started a build. When I have some results .. I'll
| This is a violation of the policy defined by the higher level config
| The full list can be found in your workspace at:
| linux/meta/cfg/standard/default/portuxg20/missing_required.cfg
So I'm not shure if my BSP is creating the kernel I wanna have ...If this is the same BSP, I can have a look and see about solving theThis would be very nice! I really stuck here ... The BSP can be found at:
two problems at once.
https://bitbucket.org/imko/meta-stamp9g20 (branch denzil)
send more email.
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.
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).
Was this BSP generating using the tooling, or by hand ?
Cheers,
Bruce
Cheers,
Bruce_______________________________________________
Cheers, Markus
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto