Date
1 - 8 of 8
Problem with BSP supporting different machines
Markus Hubig <mhubig@...>
Hi @all,
I'm having some trouble building a BSP supporting two different machines.
The machines in question are the Stamp9g20 and PortuxG20 from taskit. These
machines are just slightly different course the PortuxG20 is basically just
a small SBC built around the Stamp9G20.
You can have a look at my BSP here: http://bitbucket.org/imko/meta-stamp9g20
but take attention that you're selecting the denzil branch...
If I set MACHINE = stamp9g20 in local.conf all went fine, but with
MACHINE = portuxg20 I get a kernel for common-pc instead of
arm-versatile-926ejs ...
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 ...
Please can someone have a look? ;-)
Cheers, Markus
I'm having some trouble building a BSP supporting two different machines.
The machines in question are the Stamp9g20 and PortuxG20 from taskit. These
machines are just slightly different course the PortuxG20 is basically just
a small SBC built around the Stamp9G20.
You can have a look at my BSP here: http://bitbucket.org/imko/meta-stamp9g20
but take attention that you're selecting the denzil branch...
If I set MACHINE = stamp9g20 in local.conf all went fine, but with
MACHINE = portuxg20 I get a kernel for common-pc instead of
arm-versatile-926ejs ...
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 ...
Please can someone have a look? ;-)
Cheers, Markus
Bruce Ashfield
On Thu, Aug 9, 2012 at 10:46 AM, Markus Hubig <mhubig@...> wrote:
ran tests this
morning and denzil itself is clean, so there's definitely something
wrong in the layer.
If this is the same BSP, I can have a look and see about solving the
two problems at
once.
Bruce
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
Hi @all,Is this the same BSP producing the kconf check warnings on denzil ? I
I'm having some trouble building a BSP supporting two different machines.
The machines in question are the Stamp9g20 and PortuxG20 from taskit. These
machines are just slightly different course the PortuxG20 is basically just
a small SBC built around the Stamp9G20.
You can have a look at my BSP here: http://bitbucket.org/imko/meta-stamp9g20
but take attention that you're selecting the denzil branch...
If I set MACHINE = stamp9g20 in local.conf all went fine, but with
MACHINE = portuxg20 I get a kernel for common-pc instead of
arm-versatile-926ejs ...
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 ...
Please can someone have a look? ;-)
ran tests this
morning and denzil itself is clean, so there's definitely something
wrong in the layer.
If this is the same BSP, I can have a look and see about solving the
two problems at
once.
Bruce
Cheers, Markus
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
Markus Hubig <mhubig@...>
On Thu, Aug 09, 2012 at 10:48:30AM -0400, Bruce Ashfield wrote:
| -KMACHINE_portux9g20 = "portuxg20"
| +KMACHINE_portuxg20 = "portuxg20"
| 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
| have a corresponding value present in the final ".config" file.
| 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 ...
https://bitbucket.org/imko/meta-stamp9g20 (branch denzil)
Cheers, Markus
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
| have a corresponding value present in the final ".config" file.
| 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)
Cheers, Markus
Bruce Ashfield <bruce.ashfield@...>
On 12-08-09 12:32 PM, Markus Hubig wrote:
send more email.
Cheers,
Bruce
On Thu, Aug 09, 2012 at 10:48:30AM -0400, Bruce Ashfield wrote:I have a clone and started a build. When I have some results .. I'llOn 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
| have a corresponding value present in the final ".config" file.
| 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.
Cheers,
Bruce
Cheers, Markus
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
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
Markus Hubig <mhubig@...>
On Thu, Aug 09, 2012 at 03:10:36PM -0400, Bruce Ashfield wrote:
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' ...
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?
so I created the BSP with the tool and included my modifications.
Cheers, Markus
On 12-08-09 01:24 PM, Bruce Ashfield wrote:Hmm ok ...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: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.
Hmm no it's fine. I switched to 1.3_M3 and run a test build at the moment,Aha. yes, I knew this looked familiar. It's a fall out from the oldI have a clone and started a build. When I have some results .. I'llIf 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.
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), theTo do this I had to make some modification to my linux-yocto_3.2.bbappend
warning would also go a way (versus my current suggestion of
ignoring it).
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
Bruce Ashfield
On Fri, Aug 10, 2012 at 11:01 AM, Markus Hubig <mhubig@...> wrote:
fragment ...
that wasn't, or didn't get migrated to the source tree. I can
reproduce this with the
layer that you provided before ?
take another look.
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
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
On Thu, Aug 09, 2012 at 03:10:36PM -0400, Bruce Ashfield wrote:That is interesting. I means something was detected as a configurationOn 12-08-09 01:24 PM, Bruce Ashfield wrote:Hmm ok ...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: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.Hmm no it's fine. I switched to 1.3_M3 and run a test build at the moment,Aha. yes, I knew this looked familiar. It's a fall out from the oldI have a clone and started a build. When I have some results .. I'llIf 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.
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.
fragment ...
that wasn't, or didn't get migrated to the source tree. I can
reproduce this with the
layer that you provided before ?
That really is strange, Tom and I have both tested this recently. I'll need to
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 ...
take another look.
In 3.2 you would. I'm out of the office today, but you shouldn't still
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), theTo do this I had to make some modification to my linux-yocto_3.2.bbappend
warning would also go a way (versus my current suggestion of
ignoring it).
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?
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@...
https://lists.yoctoproject.org/listinfo/yocto
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
Markus Hubig <mhubig@...>
On Fri, Aug 10, 2012 at 12:50:00PM -0400, Bruce Ashfield wrote:
^^^^^^^^^^^^^^^^^
Something get's crippled here!
I got this error with 1.3_M3 (both poky and my bsp) and linux 3.2 & 3.4.
Cheers, Markus
On Fri, Aug 10, 2012 at 11:01 AM, Markus Hubig <mhubig@...> wrote:| [INFO] Sanitizing meta/cfgportuxg20On Thu, Aug 09, 2012 at 03:10:36PM -0400, Bruce Ashfield wrote:That is interesting. I means something was detected as a configurationOn 12-08-09 01:24 PM, Bruce Ashfield wrote:Hmm just switching to the 1.3_M3 branch doesn't solve the warning, insteadOn 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<mhubig@...> wrote:
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.
fragment ...
^^^^^^^^^^^^^^^^^
Something get's crippled here!
that wasn't, or didn't get migrated to the source tree. I canYes, but please pull bevor. I have two branches now 1.3_M3 and denzil.
reproduce this with the layer that you provided before ?
I got this error with 1.3_M3 (both poky and my bsp) and linux 3.2 & 3.4.
Nice, Thanks!That really is strange, Tom and I have both tested this recently. I'll need to
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 ...
take another look.Damn now I hit another strange error:In 3.2 you would. I'm out of the office today, but you shouldn't still
| 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), theTo do this I had to make some modification to my linux-yocto_3.2.bbappend
warning would also go a way (versus my current suggestion of
ignoring it).
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?
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, Markus