Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor

[Elvis Dowson]

Hi,

On Aug 9, 2012, at 8:47 PM, Elvis Dowson wrote:

> I switched to using gcc-4.6 from the meta-openembedded layer, and still get 
> the same issue, i.e. no login or bash prompt with init=/bin/sh

I decided to switch to code sourcery external toolchain, to try and narrow the 
cause to see if it was indeed a compiler issue. 

Which building with the mentor-2012.03-71-powerpc-mentor-linux-gnu.bin 
toolchain, I get a bunch of failures similar to the one shown below:

| ./.libs/libsqlite3.so: undefined reference to `__gcc_qtod'
| ./.libs/libsqlite3.so: undefined reference to `__gcc_qneg'
| ./.libs/libsqlite3.so: undefined reference to `__gcc_qge'
| ./.libs/libsqlite3.so: undefined reference to `__gcc_qlt'
| ./.libs/libsqlite3.so: undefined reference to `__gcc_itoq'
| ./.libs/libsqlite3.so: undefined reference to `__gcc_qtoi'
| ./.libs/libsqlite3.so: undefined reference to `__gcc_qgt'
| ./.libs/libsqlite3.so: undefined reference to `__gcc_dtoq'

My target process is a PowerPC 440 with no hardware floating point unit, and my 
ppc440 tune has been setup to use software floating point.

The above errors appear to somehow related to the floating point type. 

How can I get past these type of errors? I don't get these errors with 
gcc-4.5.1, 4.6 and 4.7 recipes. It only appears with the mentor sourcery cross 
compiler for powerpc.

Getting yocto to build using the sourcery toolchain for the powerpc440, might 
yield some clues for narrowing down the issue related with the dynamic linker.

point___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running gcc test suites for current machine configuration architecture (e.g. powerpc), from within yocto

[Khem Raj]

On Thu, Aug 9, 2012 at 9:29 PM, Elvis Dowson  wrote:
> Hi,
>   Is there a way to run the gcc test suites for the current machine 
> configuration architecture (e.g. powerpc), from within yocto?

yes. Go into build dir of gcc-cross and there is a script thats
generated.

./powerpc-oe-linux-testgcc root@

make sure that root or whatever user you have on target
can be connected using passwordless ssh access.

>
> Elvis Dowson
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Hob workflow

[Trevor Woerner]

Hi Jessica,

Thanks so much for considering my feedback :-)
I do tend to be "wordy", don't I? :-)

On Fri, Aug 10, 2012 at 6:56 PM, Zhang, Jessica  wrote:
> Am I missing any point that you're also trying to make here?

No, I think you've captured everything quite succinctly.

Expanding on point 1 a little bit:

> 1. hob should save the customization into the project's configuration, 
> instead of using its own configuration saving mechanism.  In this way, people 
> will be able to achieve same customized build result from command line or 
> using hob.

Due to the fact you have to be "in a project build" (i.e. you have to
have already sourced oe-init-build-env) in order to run Hob I thought
the configurations I was performing in Hob were changing the
configurations of the project from which Hob was started. So I was
really confused that I couldn't find any of the changes anywhere. But
what is even more confusing is that when Hob starts it begins by
taking your project's base configuration. I feel Hob sort of "sits on
the fence" in the way it starts with the project's configuration, but
then doesn't update it (back again) as it goes along. Since I was
hoping to use Hob, and then look through the project's configuration
to see how my Hob changes were changing the underlying configuration
files I was getting a bit of a run-around since none of the changes
from Hob were showing up anywhere I could find.

If someone wanted to say "Hob is independent of the project from which
it is started" I would be okay with that, but in that case Hob
shouldn't start with the given project's configuration and shouldn't
need to be run after sourcing a particular project's oe-init-build-env
file.

In fact I was originally going to send an email asking where Hob's
configuration changes were being saved until I started playing with
the "save as template" thing.

With respect to number 2:
> 2. Current "Save template" wording is confusing.

On the one hand I would prefer to be able to save the configuration as
I go along. It looks like the only time I can save a given
configuration is after I have successfully built an image (?). Perhaps
I take a long time to sift through the available packages, maybe I
don't complete that all in one step. So I'd like to be able to save as
I go along. Then, after building my packages, perhaps I then take more
time to sift through the build artifacts to determine which I want in
my image. Again this step can take quite a while and I'd prefer to be
able to save intermediate configurations as I go along (just in case
of a crash or whatever).

On the other hand I can't help think that if Hob could be saving the
configuration to the current project's configuration files as I go
along then having an explicit "save template/configuration" wouldn't
even be required. If one instance of Hob is meant to work with only
one given project then what to save and where to save it would become
explicit, so perhaps Hob could just save with every click as I go
along?

> I think these are valid points, could you file enhancement bugs for them in 
> Yocto project bugzilla for us to track them and plan the future work for them 
> accordingly?

Yes, thank you.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Hob workflow

[Zhang, Jessica]

Hi Trevor,

Thanks for using hob and provide your valuable feedbacks, I'm trying to 
summarize your desired behavior/usage of hob as:

1. hob should save the customization into the project's configuration, instead 
of using its own configuration saving mechanism.  In this way, people will be 
able to achieve same customized build result from command line or using hob.
2. Current "Save template" wording is confusing.

Am I missing any point that you're also trying to make here?  I think these are 
valid points, could you file enhancement bugs for them in Yocto project 
bugzilla for us to track them and plan the future work for them accordingly?

Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Trevor Woerner
Sent: Thursday, August 09, 2012 6:16 AM
To: yocto@yoctoproject.org
Subject: [yocto] Hob workflow

Hi everyone,

I've been using Hob lately and I'm completely blown away by how useful it is! 
Kudos to everyone: from those insisting there exist such a tool to those 
working on it :-)

While using it, however, I must admit it took me quite a while to get my head 
around some workflow issues and I was wondering if others felt the same way or 
if it's just me. (At this point I must to point out that I'm still only working 
my way through the Yocto Developer Manual and have not yet read the Hob 
documentation.)

I do my Yocto work in ~/devel/yocto. Under ~/devel/yocto I have:

1) git-method/
which contains some bare yocto kernels
various build directories for builds using the latest git
a poky/ directory with all the yocto git goodness

2) releases/
which contains various yocto project releases, which in turn contain 
various directories of builds

Let's say I decided I wanted to work on a PPC image and I decided I wanted to 
use the latest git from which to work. I would go to ~/devel/yocto/git-method 
and run:

$ source poky/oe-init-build-env ppc-image

I would then find myself in ~/devel/yocto/git-method/ppc-image from which I 
could start my work. Now, if I was a yocto guru (like everyone else is) I could 
just start tweaking and playing around with various configuration files by hand 
(e.g. conf/local.conf) and then invoke "bitbake " on the cmdline. If, 
however, I'm still learning and/or simply prefer not to tweak configuration 
files by hand, it would seem natural to assume I could, instead, invoke "hob" 
and start working on my PPC image using the GUI. This assumption, however, 
turns out to be not entirely correct.

If, before invoking "hob", I edit conf/local.conf then any changes there will 
show up in the hob configuration (i.e. DL_DIR or number of threads). But (and 
this is the really confusing part for me) any changes I make to those 
parameters while in Hob are not reflected in the relevant configuration files! 
If I quit Hob and then restarted, any changes made while in Hob would be lost; 
unless I clicked on "Save" explicitly, but even then any changes are only saved 
to a ~/devel/yocto/git-method/ppc-image/.hob directory, not in this project's 
configuration files themselves. Then, when I am done configuring and building 
an image just the way I want it, none of my changes are saved to any of the 
~/devel/yocto/git-method/ppc-image
configuration files... unless I click on "save template".

As a native english speaker I find the use of the term "template" to be 
incorrect. I wasn't interested in saving a template of my work I wanted to save 
my current configuration. For days I was frustrated that any tweaks I made to 
my configuration would be lost when I quit Hob. A "template", to me, implies 
some of the data will not be saved, which is distinct from the idea of saving 
my full, current, configuration (which is what "save template" is doing).

As a further example, while working on my PPC image let's say I also wanted to 
use Hob to work on an ARM image. In that case I'd go to 
~/devel/yocto/git-method and run "poky/oe-init-build-env arm-image", find 
myself in ~/devel/yocto/git-method/arm-image, and then invoke "hob". I now 
would have two instances of Hob running, but there is nothing to say that the 
Hob I invoked from the ARM project directory is modifying the ARM project and 
that the Hob invoked from the PPC project is modifying the PPC project. I could 
use the Hob invoked from the ARM project to "save as a template" for the PPC 
work.

It just seems more natural to me that if I started Hob from a given project 
directory (which is required since it needs bitbake), and if this instance of 
Hob is smart enough to start by using various configuration items from said 
project directory, that any changes or images made using this instance of Hob 
should be reflected back to the same configuration files and should tweak the 
project's configuration files based on the changes made while running Hob 
without having to explicitly save the configuration or "save as a tem

[yocto] [meta-fsl-ppc][PATCH] u-boot: correct path to config files

[Vladimir Zapolskiy]

The trivial change fixes u-boot compilation task, boot_format utility installs
board configuration files into a subdirectory of STAGING_DATADIR_NATIVE.

Signed-off-by: Vladimir Zapolskiy 
Cc: Matthew McClintock 
---
 recipes-kernel/u-boot/u-boot_git.bb |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/u-boot/u-boot_git.bb 
b/recipes-kernel/u-boot/u-boot_git.bb
index 8ced122..4dfb723 100644
--- a/recipes-kernel/u-boot/u-boot_git.bb
+++ b/recipes-kernel/u-boot/u-boot_git.bb
@@ -59,7 +59,7 @@ do_compile () {
cp ${S}/${board}/u-boot.bin  
${S}/${board}/${UBOOT_TARGET}.bin
else
${STAGING_BINDIR_NATIVE}/boot_format \
-   
${STAGING_DATADIR_NATIVE}/${BOOTFORMAT_CONFIG} \
+   
${STAGING_DATADIR_NATIVE}/boot_format/${BOOTFORMAT_CONFIG} \
${S}/${board}/u-boot.bin -spi 
${S}/${board}/${UBOOT_TARGET}.bin
fi 
fi
-- 
1.7.10.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 0/3] [meta-intel] Move Matrox MGA Xorg driver to common

[Tom Zanussi]

On Fri, 2012-08-10 at 12:02 -0700, kishore.k.bo...@intel.com wrote:
> From: Kishore Bodke 
> 
> Hi,
> 
> These patches are for moving the Matrox MGA Xorg driver from
> meta-romley to meta-intel/common and adding a variable to 
> include the mga recipe in the respective BSPs which uses them.
> 
> Romley BSP has been successfully booted with sato desktop.
> 
> Please pull into meta-intel/master.
> 

Thanks for making those changes, Kishore.

Pulled into meta-intel/master.

Tom

> Thanks
> Kishore.
> 
> The following changes since commit ff7fdafba88a5b7676f601b3d16a97ce7d48c4a9:
> 
>   crownbay: make v3.4 the default kernel (2012-07-31 23:08:05 -0500)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/meta-intel-contrib kishore/matrox-mga
>   
> http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=kishore/matrox-mga
> 
> Kishore Bodke (3):
>   meta-romley: Move Matrox MGA Xorg driver to meta-intel/common
>   meta-intel:Add a MATROX MGA variable to ia32-base.inc
>   meta-romley: Add Matrox MGA variable to romley.conf
> 
>  .../xorg-driver/xf86-video-mga_1.4.13.bb   |0
>  conf/machine/include/ia32-base.inc |4 
>  meta-romley/conf/machine/romley.conf   |3 +--
>  3 files changed, 5 insertions(+), 2 deletions(-)
>  rename {meta-romley => 
> common}/recipes-graphics/xorg-driver/xf86-video-mga_1.4.13.bb (100%)
> 


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_deploy[sstate-inputdirs]

[Robert P. J. Day]

On Fri, 10 Aug 2012, Robert P. J. Day wrote:

> On Fri, 10 Aug 2012, Jim Rucker wrote:
>
> > I've been trying to figure out why I've had such trouble getting my 
> > tmp/deploy/uImage files to
> > update after performing a "bitbake -f -c compile virtual/kernel", and I've 
> > come across something I I
> > don't understand. In deploy.bbclass, we have:
> > do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
> >
> > However, the only place DEPLOYDIR is ever used is as 
> > a install destination within the
> > kernel_do_deploy functions. Therefore, from what I can tell, DEPLOYDIR is 
> > never updated and
> > therefore do_deploy is never called - even if you run "bitbake -f -c deploy 
> > virtual/kernel" (note
> > that I'm using the 6.0.2 poky release, not top of tree). From what I 
> > understand, the best way to fix
> > this is to make the following changes:
> >
> > kernel.bbclass:
> > OUTPUTDIR ?= "arch/${ARCH}/boot
> > KERNEL_OUTPUT ?= "${OUTPUTDIR}/${KERNEL_IMAGETYPE}
> >
> > deploy.bblass
> > do_deploy[sstate-inputdirs] = "${OUTPUT_DIR}"
> > do_deploy[sstate-outputdirs] = "${DEPLOYDIR}
> >
> > Am I barking up the right or wrong tree here?
>
>   i'm sort of sure that what you're after is the "do_uboot_mkimage"
> task.

  oh, crap, never mind, i just misread that.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_deploy[sstate-inputdirs]

[Robert P. J. Day]

On Fri, 10 Aug 2012, Jim Rucker wrote:

> I've been trying to figure out why I've had such trouble getting my 
> tmp/deploy/uImage files to
> update after performing a "bitbake -f -c compile virtual/kernel", and I've 
> come across something I I
> don't understand. In deploy.bbclass, we have:
> do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
>
> However, the only place DEPLOYDIR is ever used is as 
> a install destination within the
> kernel_do_deploy functions. Therefore, from what I can tell, DEPLOYDIR is 
> never updated and
> therefore do_deploy is never called - even if you run "bitbake -f -c deploy 
> virtual/kernel" (note
> that I'm using the 6.0.2 poky release, not top of tree). From what I 
> understand, the best way to fix
> this is to make the following changes:
>
> kernel.bbclass:
> OUTPUTDIR ?= "arch/${ARCH}/boot
> KERNEL_OUTPUT ?= "${OUTPUTDIR}/${KERNEL_IMAGETYPE}
>
> deploy.bblass
> do_deploy[sstate-inputdirs] = "${OUTPUT_DIR}"
> do_deploy[sstate-outputdirs] = "${DEPLOYDIR}
>
> Am I barking up the right or wrong tree here?

  i'm sort of sure that what you're after is the "do_uboot_mkimage"
task.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] do_deploy[sstate-inputdirs]

[Jim Rucker]

I've been trying to figure out why I've had such trouble getting my
tmp/deploy/uImage files to update after performing a "bitbake -f -c compile
virtual/kernel", and I've come across something I I don't understand. In
deploy.bbclass, we have:

*do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"*

However, the only place DEPLOYDIR is ever used is as a install
*destination* within
the kernel_do_deploy functions. Therefore, from what I can tell, DEPLOYDIR
is never updated and therefore do_deploy is never called - even if you run
"bitbake -f -c deploy virtual/kernel" (note that I'm using the 6.0.2 poky
release, not top of tree). From what I understand, the best way to fix this
is to make the following changes:

kernel.bbclass:
OUTPUTDIR ?= "arch/${ARCH}/boot
KERNEL_OUTPUT ?= "${OUTPUTDIR}/${KERNEL_IMAGETYPE}

deploy.bblass
do_deploy[sstate-inputdirs] = "${OUTPUT_DIR}"
do_deploy[sstate-outputdirs] = "${DEPLOYDIR}

Am I barking up the right or wrong tree here?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 00/19] yocto-bsp updates for master, v2

[Tom Zanussi]

Oops, had wrong version for this, resending a new version to avoid
confusion...

Tom

On Fri, 2012-08-10 at 14:03 -0500, tom.zanu...@intel.com wrote:
> From: Tom Zanussi 
> 
> This patchset fixes yocto bugs [YOCTO #2693] and [YOCTO #2587], and
> fixes some other minor usability problems reported by users.
> 
> Please pull into poky/master.
> 
> v2: This is the same patchset as the previous one, but an additional
> couple of patches fixing problems found in testing has been tacked on.
> 
> v3: This removes all instances of YOCTO_KERNEL_EXTERNAL_BRANCH usage
>  - some were missed the last time around.
> 
> The following changes since commit 2dec760b79bb7e2e79c33c5127fa64685bd86a18:
> 
>   foomatic: fix perl path for target (2012-08-08 10:06:00 +0100)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib.git 
> tzanussi/yocto-bsp-master-update.v3
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/yocto-bsp-master-update.v3
> 
> Tom Zanussi (19):
>   yocto-bsp: add new strip_base() function
>   yocto-bsp: strip '/base' from kernel branches in templates
>   yocto-bsp: update default branch names
>   yocto-bsp: allow branch display filtering
>   yocto-bsp: use branches_base
>   yocto-bsp: add standard branch mapping
>   yocto-bsp: use standard branch mapping in bsp templates
>   yocto-bsp: use rstrip() for assignment lines
>   yocto-bsp: remove 'branch' statements in .scc if reusing branch
>   yocto-bsp: add some standard policy
>   yocto-bsp: add i586 option for i386
>   yocto-bsp: use emgd 1.10 for i386 template
>   yocto-bsp: generate default properties even if json specified
>   yocto-bsp: add 3.4/remove 3.0 kernel from templates
>   yocto-bsp: update standard branch mapping
>   yocto-bsp: use emgd 1.14 for i386 template
>   yocto-bsp: remove YOCTO_KERNEL_EXTERNAL_BRANCH usage
>   yocto-bsp: use base branches for qemu 'newbranch' case
>   yocto-bsp: add missing xserver-xf86-config .bbappend for qemu
> 
>  scripts/lib/bsp/engine.py  |   44 
> ++--
>  scripts/lib/bsp/kernel.py  |   19 +
>  .../linux/files/{{=machine}}-standard.scc  |1 +
>  .../arm/recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |   13 +++---
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |   13 +++---
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../arch/i386/conf/machine/{{=machine}}.conf   |   14 ---
>  .../linux/files/{{=machine}}-preempt-rt.scc|7 
>  .../linux/files/{{=machine}}-standard.scc  |   14 ++-
>  .../recipes-kernel/linux/files/{{=machine}}.scc|2 +-
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../linux/files/{{=machine}}-standard.scc  |1 +
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../linux/files/{{=machine}}-standard.scc  |1 +
>  .../recipes-kernel/linux/files/{{=machine}}.scc|3 --
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |2 +
>  .../linux/files/{{=machine}}-preempt-rt.scc|5 +--
>  .../linux/files/{{=machine}}-standard.scc  |9 ++--
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |   25 +--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   29 ++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |   25 +--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   29 ++---
>  .../linux/files/{{=machine}}-preempt-rt.scc|7 
>  .../linux/files/{{=machine}}-standard.scc  |   10 -
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |   39 -
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   36 
>  ...linux-y

[yocto] [PATCH 19/19] yocto-bsp: add missing xserver-xf86-config .bbappend for qemu

[tom . zanussi]

From: Tom Zanussi 

Re-add xserver-xf86-config which was inadvertently removed.

Signed-off-by: Tom Zanussi 
---
 .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 
scripts/lib/bsp/substrate/target/arch/qemu/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend

diff --git 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
new file mode 100644
index 000..d3420e0
--- /dev/null
+++ 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
@@ -0,0 +1,2 @@
+THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
+FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 13/19] yocto-bsp: generate default properties even if json specified

[tom . zanussi]

From: Tom Zanussi 

Users seem to want to specify incomplete property sets when using json
input.  Allow this by generating default properties before the
user-specified properties are applied; the user will then get the
defaults for any unspecified values, and avoid cryptic backtraces.

Signed-off-by: Tom Zanussi 
---
 scripts/lib/bsp/engine.py |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index af90e91..9d16b19 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1245,10 +1245,10 @@ def yocto_bsp_create(machine, arch, scripts_path, 
bsp_output_dir, codedump, prop
 
 gen_program_header_lines(program_lines)
 
+gen_initial_property_vals(input_lines, program_lines)
+
 if properties:
 gen_supplied_property_vals(properties, program_lines)
-else:
-gen_initial_property_vals(input_lines, program_lines)
 
 gen_program_machine_lines(machine, program_lines)
 
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 18/19] yocto-bsp: use base branches for qemu 'newbranch' case

[tom . zanussi]

From: Tom Zanussi 

The branch updating for the [YOCTO #2587] fix inadvertently changed
some of the qemu branch names incorrectly, fix it.

Signed-off-by: Tom Zanussi 
---
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |2 +-
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |2 +-
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |6 +++---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |6 +++---
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git 
"a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
index 7bb3ee9..6d6f4b6 100644
--- "a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"   
+++ "b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"   
@@ -13,7 +13,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
 {{ input type:"choicelist" name:"existing_kbranch" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "y" and qemuarch == "powerpc": }}
-{{ input type:"choicelist" name:"new_kbranch" nameappend:"powerpc" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/qemu-ppc32" }}
+{{ input type:"choicelist" name:"new_kbranch" nameappend:"powerpc" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "n" and qemuarch == "powerpc": }}
 {{ input type:"choicelist" name:"existing_kbranch" nameappend:"powerpc" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/qemu-ppc32" }}
diff --git 
"a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend"
index 13e96ad..2e3bb00 100644
--- "a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend"   
+++ "b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend"   
@@ -13,7 +13,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
 {{ input type:"choicelist" name:"existing_kbranch" nameappend:"arm" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "y" and qemuarch == "powerpc": }}
-{{ input type:"choicelist" name:"new_kbranch" nameappend:"powerpc" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/qemu-ppc32" }}
+{{ input type:"choicelist" name:"new_kbranch" nameappend:"powerpc" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "n" and qemuarch == "powerpc": }}
 {{ input type:"choicelist" name:"existing_kbranch" nameappend:"powerpc" 
gen:"bsp.kernel.all_branches" branches_base:"standard/preempt-rt" prio:"20" 
msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/qemu-ppc32" }}
diff --git 
"a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend"
index 1f8ad71..5f3ec83 100644
--- "a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" 
+++ "b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" 
@@ -7,13 +7,13 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
 {{ input type:"boolean" name:"need_new_kbranch" prio:"20" msg:"Do you need a 
new machine branch for this BSP (the alternative is to re-use an existing 
branch)? [y/n]" default:"y" }}
 
 {{ if nee

[yocto] [PATCH 17/19] yocto-bsp: remove YOCTO_KERNEL_EXTERNAL_BRANCH usage

[tom . zanussi]

From: Tom Zanussi 

YOCTO_KERNEL_EXTERNAL_BRANCH is now obsolete, so remove it from the
templates.

Signed-off-by: Tom Zanussi 
---
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |3 ---
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |3 ---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |3 ---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |5 -
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |3 ---
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |3 ---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |3 ---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |5 -
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |3 ---
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |3 ---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |3 ---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |5 -
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |3 ---
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |3 ---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |3 ---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |5 -
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |3 ---
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |3 ---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |3 ---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |3 ---
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |3 ---
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |3 ---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |3 ---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |5 -
 24 files changed, 82 deletions(-)

diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
index a2b4726..25b8ef9 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
+++ "b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
@@ -17,9 +17,6 @@ KBRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
 {{ if need_new_kbranch == "n": }}
 KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
 
-{{ if need_new_kbranch == "y": }}
-YOCTO_KERNEL_EXTERNAL_BRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
-
 KMACHINE_{{=machine}}  = "{{=machine}}"
 
 {{ input type:"boolean" name:"smp" prio:"30" msg:"Do you need SMP support? 
(y/n)" default:"y"}}
diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend"
index f80989c..094cf5c 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend"
+++ "b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend"
@@ -17,9 +17,6 @@ KBRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
 {{ if need_new_kbranch == "n": }}
 KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
 
-{{ if need_new_kbranch == "y": }}
-YOCTO_KERNEL_EXTERNAL_BRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
-
 KMACHINE_{{=machine}}  = "{{=machine}}"
 
 {{ input type:"boolean" name:"smp" prio:"30" msg:"Do you need SMP support? 
(y/n)" default:"y"}}
diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend"
index 87f6cf1..730b07a 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend"  
+++ "b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.2\": }} linux-yocto_3.2.bbappend"  
@@ -17,9 +17,6 @@ KBRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
 {{ if need_new_kbranch == "n": }}
 KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
 
-{{ if need_new_kbranch == "y": }}
-YOCTO_KERNEL_EXTERNAL_BRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
-
 KMACHINE_{{=machine}}  = "{{=machine}}"
 
 {{ input type:"boolean" name:"smp" prio:"30" msg:"Do you need SMP support? 
(y/n)" default:"y"}}
diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if k

[yocto] [PATCH 16/19] yocto-bsp: use emgd 1.14 for i386 template

[tom . zanussi]

From: Tom Zanussi 

Make i386 template use emgd 1.14, along with associated changes.

Signed-off-by: Tom Zanussi 
---
 .../arch/i386/conf/machine/{{=machine}}.conf   |6 +++---
 .../linux/files/{{=machine}}-standard.scc  |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf 
b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
index 2c109af..2a07889 100644
--- a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
+++ b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
@@ -23,13 +23,13 @@ require conf/machine/include/ia32-base.inc
 
 {{ input type:"boolean" name:"xserver" prio:"50" msg:"Do you need support for 
X? (y/n)" default:"y" }}
 
-{{ if xserver == "y" and kernel_choice == "linux-yocto_3.2": }}
+{{ if xserver == "y" and kernel_choice == "linux-yocto_3.4": }}
 {{ input type:"choicelist" name:"xserver_choice" prio:"50" msg:"Please select 
an xserver for this machine:" default:"xserver_i915" }}
 {{ input type:"choice" val:"xserver_vesa" msg:"VESA xserver support" }}
 {{ input type:"choice" val:"xserver_emgd" msg:"EMGD xserver support 
(proprietary)" }}
 {{ input type:"choice" val:"xserver_i915" msg:"i915 xserver support" }}
 
-{{ if xserver == "y" and kernel_choice != "linux-yocto_3.2": xserver_choice = 
"xserver_i915" }}
+{{ if xserver == "y" and kernel_choice != "linux-yocto_3.4": xserver_choice = 
"xserver_i915" }}
 
 {{ if xserver == "y": }}
 XSERVER ?= "${XSERVER_IA32_BASE} \
@@ -46,7 +46,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
 {{ if xserver == "y" and xserver_choice == "xserver_emgd": }}
 PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
 PREFERRED_VERSION_mesa-dri ?= "7.11"
-PREFERRED_VERSION_emgd-driver-bin ?= "1.10"
+PREFERRED_VERSION_emgd-driver-bin ?= "1.14"
 
 {{ if xserver == "y" and xserver_choice == "xserver_vesa" or xserver_choice == 
"xserver_emgd": }}
 APPEND += "video=vesafb vga=0x318"
diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 024af30..c6f42db 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -7,8 +7,8 @@ include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)
 branch {{=machine}}
 
 {{ if xserver == "y" and xserver_choice == "xserver_emgd": }}
-include features/emgd/emgd-1.10.scc
-git merge emgd-1.10
+include features/emgd/emgd-1.14.scc
+git merge emgd-1.14
 
 include {{=machine}}.scc
 
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 07/19] yocto-bsp: use standard branch mapping in bsp templates

[tom . zanussi]

From: Tom Zanussi 

Signed-off-by: Tom Zanussi 
---
 .../linux/files/{{=machine}}-standard.scc  |2 +-
 .../linux/files/{{=machine}}-standard.scc  |4 ++--
 .../linux/files/{{=machine}}-standard.scc  |2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 28c353b..c7ba1fb 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -2,7 +2,7 @@ define KMACHINE {{=machine}}
 define KTYPE standard
 define KARCH i386
 
-include ktypes/standard
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)}}
 branch {{=machine}}
 
 include {{=machine}}.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 9ed66c3..4def04a 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -12,10 +12,10 @@ define KARCH powerpc
 define KARCH mips
 
 {{ if qemuarch == "i386": }}
-include bsp/common-pc/common-pc-standard
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)}}
 branch {{=machine}}
 {{ if qemuarch == "x86_64": }}
-include bsp/common-pc-64/common-pc-64-standard
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)}}
 branch {{=machine}}
 {{ if qemuarch == "arm": }}
 include bsp/arm-versatile-926ejs/arm-versatile-926ejs-standard
diff --git 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 2a32fea..4a034fa 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -2,7 +2,7 @@ define KMACHINE {{=machine}}
 define KTYPE standard
 define KARCH x86_64
 
-include bsp/common-pc-64/common-pc-64-standard
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)}}
 branch {{=machine}}
 
 include {{=machine}}.scc
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 08/19] yocto-bsp: use rstrip() for assignment lines

[tom . zanussi]

From: Tom Zanussi 

strip() isn't necessary and causes unintended formatting changes in
the output; rstrip() remove the trailing newlines as intended while
leaving indenting whitespace intact.

Signed-off-by: Tom Zanussi 
---
 scripts/lib/bsp/engine.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 756b882..af90e91 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -668,7 +668,7 @@ class SubstrateBase(object):
 """
 Expand all tags in a line.
 """
-expanded_line = AssignmentLine(line.strip())
+expanded_line = AssignmentLine(line.rstrip())
 
 while start != -1:
 end = line.find(CLOSE_TAG, start)
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 15/19] yocto-bsp: update standard branch mapping

[tom . zanussi]

From: Tom Zanussi 

Remove mapping for 3.0 and add mapping for 3.4.

Signed-off-by: Tom Zanussi 
---
 scripts/lib/bsp/engine.py |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 9d16b19..ac5058c 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1508,7 +1508,7 @@ def yocto_bsp_list(args, scripts_path, properties_file):
 def map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch):
 """
 Return the linux-yocto bsp branch to use with the specified
-kbranch.  This handles the -standard variants for 3.0 and 3.2; the
+kbranch.  This handles the -standard variants for 3.2 and 3.4; the
 other variants don't need mappings.
 """
 if need_new_kbranch == "y":
@@ -1517,10 +1517,10 @@ def map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch):
 kbranch = existing_kbranch
 
 if (kbranch.startswith("standard/default/common-pc-64") or
-kbranch.startswith("yocto/standard/common-pc-64")):
+kbranch.startswith("standard/common-pc-64")):
 return "bsp/common-pc-64/common-pc-64-standard"
 if (kbranch.startswith("standard/default/common-pc") or
-kbranch.startswith("yocto/standard/common-pc")):
+kbranch.startswith("standard/common-pc")):
 return "bsp/common-pc/common-pc-standard"
 else:
 return "ktypes/standard"
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 12/19] yocto-bsp: use emgd 1.10 for i386 template

[tom . zanussi]

From: Tom Zanussi 

Make i386 template use emgd 1.10 for denzil, along with associated
changes.

Signed-off-by: Tom Zanussi 
---
 .../arch/i386/conf/machine/{{=machine}}.conf   |7 ---
 .../linux/files/{{=machine}}-standard.scc  |4 
 .../recipes-kernel/linux/files/{{=machine}}.scc|2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf 
b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
index 100c68c..2c109af 100644
--- a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
+++ b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
@@ -23,13 +23,14 @@ require conf/machine/include/ia32-base.inc
 
 {{ input type:"boolean" name:"xserver" prio:"50" msg:"Do you need support for 
X? (y/n)" default:"y" }}
 
-{{ if xserver == "y": }}
+{{ if xserver == "y" and kernel_choice == "linux-yocto_3.2": }}
 {{ input type:"choicelist" name:"xserver_choice" prio:"50" msg:"Please select 
an xserver for this machine:" default:"xserver_i915" }}
-
 {{ input type:"choice" val:"xserver_vesa" msg:"VESA xserver support" }}
 {{ input type:"choice" val:"xserver_emgd" msg:"EMGD xserver support 
(proprietary)" }}
 {{ input type:"choice" val:"xserver_i915" msg:"i915 xserver support" }}
 
+{{ if xserver == "y" and kernel_choice != "linux-yocto_3.2": xserver_choice = 
"xserver_i915" }}
+
 {{ if xserver == "y": }}
 XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
@@ -45,7 +46,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
 {{ if xserver == "y" and xserver_choice == "xserver_emgd": }}
 PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
 PREFERRED_VERSION_mesa-dri ?= "7.11"
-PREFERRED_VERSION_emgd-driver-bin ?= "1.8"
+PREFERRED_VERSION_emgd-driver-bin ?= "1.10"
 
 {{ if xserver == "y" and xserver_choice == "xserver_vesa" or xserver_choice == 
"xserver_emgd": }}
 APPEND += "video=vesafb vga=0x318"
diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 2c16efa..024af30 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -6,6 +6,10 @@ include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)
 {{ if need_new_kbranch == "y": }}
 branch {{=machine}}
 
+{{ if xserver == "y" and xserver_choice == "xserver_emgd": }}
+include features/emgd/emgd-1.10.scc
+git merge emgd-1.10
+
 include {{=machine}}.scc
 
 # default policy for standard kernels
diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}.scc
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}.scc
index 309f25d..15bda3c 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}.scc
@@ -15,7 +15,7 @@ include features/hpet/hpet.scc
 include features/ericsson-3g/f5521gw.scc
 
 {{ if xserver == "y" and xserver_choice == "xserver_vesa" or xserver_choice == 
"xserver_emgd": }}
-include features/framebuffer/vesafb.scc
+include cfg/vesafb.scc
 
 include cfg/usb-mass-storage.scc
 include cfg/boot-live.scc
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 11/19] yocto-bsp: add i586 option for i386

[tom . zanussi]

From: Tom Zanussi 

Signed-off-by: Tom Zanussi 
---
 .../arch/i386/conf/machine/{{=machine}}.conf   |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf 
b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
index ab491b2..100c68c 100644
--- a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
+++ b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
@@ -9,12 +9,15 @@ PREFERRED_PROVIDER_virtual/kernel ?= "{{=preferred_kernel}}"
 PREFERRED_VERSION_{{=preferred_kernel}} ?= "{{=preferred_kernel_version}}%"
 
 {{ input type:"choicelist" name:"tunefile" prio:"40" msg:"Which machine tuning 
would you like to use?" default:"tune_core2" }}
+{{ input type:"choice" val:"tune_i586" msg:"i586 tuning optimizations" }}
 {{ input type:"choice" val:"tune_atom" msg:"Atom tuning optimizations" }}
 {{ input type:"choice" val:"tune_core2" msg:"Core2 tuning optimizations" }}
+{{ if tunefile == "tune_i586": }}
+require conf/machine/include/tune-i586.inc
 {{ if tunefile == "tune_atom": }}
-include conf/machine/include/tune-atom.inc
+require conf/machine/include/tune-atom.inc
 {{ if tunefile == "tune_core2": }}
-include conf/machine/include/tune-core2.inc
+require conf/machine/include/tune-core2.inc
 
 require conf/machine/include/ia32-base.inc
 
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 10/19] yocto-bsp: add some standard policy

[tom . zanussi]

From: Tom Zanussi 

Add some useful default options to to the i386 and x86_64 templates.

Signed-off-by: Tom Zanussi 
---
 .../linux/files/{{=machine}}-preempt-rt.scc|7 +++
 .../linux/files/{{=machine}}-standard.scc  |7 +++
 .../linux/files/{{=machine}}-preempt-rt.scc|7 +++
 .../linux/files/{{=machine}}-standard.scc  |7 +++
 4 files changed, 28 insertions(+)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
index 9fb8002..6ee1c93 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
@@ -6,3 +6,10 @@ define KARCH i386
 include ktypes/preempt-rt
 
 include {{=machine}}.scc
+
+# default policy for preempt-rt kernels
+include cfg/usb-mass-storage.scc
+include cfg/boot-live.scc
+include features/logbuf/size-normal.scc
+include features/latencytop/latencytop.scc
+include features/profiling/profiling.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
index a241b29..2c16efa 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -7,3 +7,10 @@ include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)
 branch {{=machine}}
 
 include {{=machine}}.scc
+
+# default policy for standard kernels
+include cfg/usb-mass-storage.scc
+include cfg/boot-live.scc
+include features/logbuf/size-normal.scc
+include features/latencytop/latencytop.scc
+include features/profiling/profiling.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
index ecb0f01..5819dce 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
@@ -6,3 +6,10 @@ define KARCH x86_64
 include ktypes/preempt-rt
 
 include {{=machine}}.scc
+
+# default policy for preempt-rt kernels
+include cfg/usb-mass-storage.scc
+include cfg/boot-live.scc
+include features/logbuf/size-normal.scc
+include features/latencytop/latencytop.scc
+include features/profiling/profiling.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 3253133..9e5cf13 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -7,3 +7,10 @@ include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)
 branch {{=machine}}
 
 include {{=machine}}.scc
+
+# default policy for standard kernels
+include cfg/usb-mass-storage.scc
+include cfg/boot-live.scc
+include features/logbuf/size-normal.scc
+include features/latencytop/latencytop.scc
+include features/profiling/profiling.scc
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 09/19] yocto-bsp: remove 'branch' statements in .scc if reusing branch

[tom . zanussi]

From: Tom Zanussi 

If reusing a branch (need_new_branch == 'n') we don't need to branch
in the .scc, so make it conditional on need_new_branch.

Signed-off-by: Tom Zanussi 
---
 .../linux/files/{{=machine}}-standard.scc  |1 +
 .../linux/files/{{=machine}}-standard.scc  |1 +
 .../linux/files/{{=machine}}-standard.scc  |1 +
 .../linux/files/{{=machine}}-standard.scc  |1 +
 .../linux/files/{{=machine}}-preempt-rt.scc|5 +
 .../linux/files/{{=machine}}-standard.scc  |5 +
 .../linux/files/{{=machine}}-standard.scc  |1 +
 7 files changed, 7 insertions(+), 8 deletions(-)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/{{=machine}}-standard.scc
index cd8fa9c..d131678 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -3,6 +3,7 @@ define KTYPE standard
 define KARCH arm
 
 include ktypes/standard
+{{ if need_new_kbranch == "y": }}
 branch {{=machine}}
 
 include {{=machine}}.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
index c7ba1fb..a241b29 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -3,6 +3,7 @@ define KTYPE standard
 define KARCH i386
 
 include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)}}
+{{ if need_new_kbranch == "y": }}
 branch {{=machine}}
 
 include {{=machine}}.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/{{=machine}}-standard.scc
index c6139f0..3b916b4 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -3,6 +3,7 @@ define KTYPE standard
 define KARCH mips
 
 include ktypes/standard
+{{ if need_new_kbranch == "y": }}
 branch {{=machine}}
 
 include {{=machine}}.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 1213e61..a521874 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -3,6 +3,7 @@ define KTYPE standard
 define KARCH powerpc
 
 include ktypes/standard
+{{ if need_new_kbranch == "y": }}
 branch {{=machine}}
 
 include {{=machine}}.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
index 6399a4b..0f5a582 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-preempt-rt.scc
@@ -13,18 +13,15 @@ define KARCH mips
 
 {{ if qemuarch == "i386": }}
 include bsp/common-pc/common-pc-preempt-rt
-branch {{=machine}}
 {{ if qemuarch == "x86_64": }}
 include bsp/common-pc-64/common-pc-64-preempt-rt
-branch {{=machine}}
 {{ if qemuarch == "arm": }}
 include bsp/arm-versatile-926ejs/arm-versatile-926ejs-preempt-rt
-branch {{=machine}}
 {{ if qemuarch == "powerpc": }}
 include bsp/qemu-ppc32/qemu-ppc32-rt
-branch {{=machine}}
 {{ if qemuarch == "mips": }}
 include bsp/mti-malta32/mti-malta32-be-preempt-rt
+{{ if need_new_kbranch == "y": }}
 branch {{=machine}}
 
 include {{=machine}}.scc
diff --git 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
index 4def04a..04a3620 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
+++ 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/{{=machine}}-standard.scc
@@ -13,18 +13,15 @@ define KARCH mips
 
 {{ if qemuarch == "i386": }}
 include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)}}
-branch {{=machine}}
 {{ if qemuarch == "x86_64": }}
 include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, 
existing_kbranch)}}
-bran

[yocto] [PATCH 06/19] yocto-bsp: add standard branch mapping

[tom . zanussi]

From: Tom Zanussi 

Add a mechanism to distinguish common-pc variants of standard
branches.

Signed-off-by: Tom Zanussi 
---
 scripts/lib/bsp/engine.py |   21 +
 1 file changed, 21 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8b05809..756b882 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1503,3 +1503,24 @@ def yocto_bsp_list(args, scripts_path, properties_file):
 return False
 
 return True
+
+
+def map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch):
+"""
+Return the linux-yocto bsp branch to use with the specified
+kbranch.  This handles the -standard variants for 3.0 and 3.2; the
+other variants don't need mappings.
+"""
+if need_new_kbranch == "y":
+kbranch = new_kbranch
+else:
+kbranch = existing_kbranch
+
+if (kbranch.startswith("standard/default/common-pc-64") or
+kbranch.startswith("yocto/standard/common-pc-64")):
+return "bsp/common-pc-64/common-pc-64-standard"
+if (kbranch.startswith("standard/default/common-pc") or
+kbranch.startswith("yocto/standard/common-pc")):
+return "bsp/common-pc/common-pc-standard"
+else:
+return "ktypes/standard"
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 04/19] yocto-bsp: allow branch display filtering

[tom . zanussi]

From: Tom Zanussi 

Add a "branches_base" property that can be used to allow only matching
branches to be returned from all_branches().

Signed-off-by: Tom Zanussi 
---
 scripts/lib/bsp/engine.py |7 +++
 scripts/lib/bsp/kernel.py |   19 +++
 2 files changed, 26 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index cda1d14..8b05809 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -473,6 +473,11 @@ def gen_choices_defer(input_line, context, checklist = 
False):
 except KeyError:
 nameappend = ""
 
+try:
+branches_base = input_line.props["branches_base"]
+except KeyError:
+branches_base = ""
+
 filename = input_line.props["filename"]
 
 closetag_start = filename.find(CLOSE_TAG)
@@ -488,6 +493,8 @@ def gen_choices_defer(input_line, context, checklist = 
False):
 captured_context["filename"] = filename
 context["nameappend"] = nameappend
 captured_context["nameappend"] = nameappend
+context["branches_base"] = branches_base
+captured_context["branches_base"] = branches_base
 
 deferred_choice = (input_line, captured_context, checklist)
 key = name + "_" + filename + "_" + nameappend
diff --git a/scripts/lib/bsp/kernel.py b/scripts/lib/bsp/kernel.py
index 7c6da4e..d4bdc4c 100644
--- a/scripts/lib/bsp/kernel.py
+++ b/scripts/lib/bsp/kernel.py
@@ -713,6 +713,17 @@ def all_branches(context):
 
 branches = []
 
+base_prefixes = None
+
+try:
+branches_base = context["branches_base"]
+if branches_base:
+base_prefixes = branches_base.split(":")
+except KeyError:
+pass
+
+arch = context["arch"]
+
 if tmp:
 tmpline = tmp.split("\n")
 for line in tmpline:
@@ -720,6 +731,14 @@ def all_branches(context):
 break;
 idx = line.find("refs/heads/")
 kbranch = line[idx + len("refs/heads/"):]
+kbranch_prefix = kbranch.rsplit("/", 1)[0]
+
+if base_prefixes:
+for base_prefix in base_prefixes:
+if kbranch_prefix == base_prefix:
+branches.append(kbranch)
+continue
+
 if (kbranch.find("/") != -1 and
 (kbranch.find("standard") != -1 or kbranch.find("base") != -1) 
or
 kbranch == "base"):
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 03/19] yocto-bsp: update default branch names

[tom . zanussi]

From: Tom Zanussi 

Make sure the default branch names match branch names found in the
kernel branch listing.

Fixes [YOCTO #2587].

Signed-off-by: Tom Zanussi 
---
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |2 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |2 +-
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |2 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |2 +-
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |2 +-
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |2 +-
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |2 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |2 +-
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |2 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |2 +-
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |   10 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |   10 +-
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |   10 +-
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |   10 +-
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |2 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |2 +-
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |2 +-
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |2 +-
 24 files changed, 46 insertions(+), 46 deletions(-)

diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend"
index a55e6c7..059426f 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend"
+++ "b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend"
@@ -7,7 +7,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
 {{ input type:"boolean" name:"need_new_kbranch" prio:"20" msg:"Do you need a 
new machine branch for this BSP (the alternative is to re-use an existing 
branch)? [y/n]" default:"y" }}
 
 {{ if need_new_kbranch == "y": }}
-{{ input type:"choicelist" name:"new_kbranch" gen:"bsp.kernel.all_branches" 
prio:"20" msg:"Please choose a machine branch to base this BSP on:" 
default:"yocto/standard/preempt-rt" }}
+{{ input type:"choicelist" name:"new_kbranch" gen:"bsp.kernel.all_branches" 
prio:"20" msg:"Please choose a machine branch to base this BSP on:" 
default:"yocto/standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "n": }}
 {{ input type:"choicelist" name:"existing_kbranch" 
gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine branch to 
base this BSP on:" default:"yocto/standard/preempt-rt/base" }}
diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
index d60b7ce..5a8cc7a 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
+++ "b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
@@ -7,7 +7,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
 {{ input type:"boolean" name:"need_new_kbranch" prio:"20" msg:"Do you need a 
new machine branch for this BSP (the alternative is to re-use an existing 
branch)? [y/n]" default:"y" }}
 
 {{ if need_new_kbranch == "y": }}
-{{ input type:"choicelist" name:"new_kbranch" gen:"bsp.kernel.all_branches" 
prio:"20" msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt" }}
+{{ input type:"choicelist" name:"new_kbranch" gen:"bsp.kernel.all_branches" 
prio:"20" msg:"Please choose a machine branch to base this BSP on:" 
default:"standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "n": }}
 {{ input type:"choicelist" name:"existing_kbranch" 
gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine branch to 
base this BSP on:" default:"standard/preempt-rt/base" }}
diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" 
"b/scripts/lib/bsp/substrate/target/

[yocto] [PATCH 02/19] yocto-bsp: strip '/base' from kernel branches in templates

[tom . zanussi]

From: Tom Zanussi 

For new branches, users can specify /base branches, but we don't want
the '/base' in the resultant branch name, so remove it.

Fixes [YOCTO #2693].

Signed-off-by: Tom Zanussi 
---
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |4 ++--
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |4 ++--
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |4 ++--
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |4 ++--
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |4 ++--
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |4 ++--
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |4 ++--
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |4 ++--
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |4 ++--
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |4 ++--
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |4 ++--
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |4 ++--
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |4 ++--
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |4 ++--
 24 files changed, 48 insertions(+), 48 deletions(-)

diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend"
index 144acd3..a55e6c7 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend"
+++ "b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend"
@@ -13,12 +13,12 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
 {{ input type:"choicelist" name:"existing_kbranch" 
gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine branch to 
base this BSP on:" default:"yocto/standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "y": }}
-KBRANCH_{{=machine}}  = "{{=new_kbranch}}/{{=machine}}"
+KBRANCH_{{=machine}}  = "{{=strip_base(new_kbranch)}}/{{=machine}}"
 {{ if need_new_kbranch == "n": }}
 KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
 
 {{ if need_new_kbranch == "y": }}
-YOCTO_KERNEL_EXTERNAL_BRANCH_{{=machine}}  = "{{=new_kbranch}}/{{=machine}}"
+YOCTO_KERNEL_EXTERNAL_BRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
 
 KMACHINE_{{=machine}}  = "{{=machine}}"
 
diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
index 7fc48a5..d60b7ce 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
+++ "b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend"
@@ -13,12 +13,12 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
 {{ input type:"choicelist" name:"existing_kbranch" 
gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine branch to 
base this BSP on:" default:"standard/preempt-rt/base" }}
 
 {{ if need_new_kbranch == "y": }}
-KBRANCH_{{=machine}}  = "{{=new_kbranch}}/{{=machine}}"
+KBRANCH_{{=machine}}  = "{{=strip_base(new_kbranch)}}/{{=machine}}"
 {{ if need_new_kbranch == "n": }}
 KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
 
 {{ if need_new_kbranch == "y": }}
-YOCTO_KERNEL_EXTERNAL_BRANCH_{{=machine}}  = "{{=new_kbranch}}/{{=machine}}"
+YOCTO_KERNEL_EXTERNAL_BRANCH_{{=machine}}  = 
"{{=strip_base(new_kbranch)}}/{{=machine}}"
 
 KMACHINE_{{=machine}}  = "{{=machine}}"
 
diff --git "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ 
if kernel_choice == \"linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" 
"b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.0\": }} linux-yocto_3.0.bbappend"
index 12de75e..87741b6 100644
--- "a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kerne

[yocto] [PATCH 01/19] yocto-bsp: add new strip_base() function

[tom . zanussi]

From: Tom Zanussi 

Add a strip_base() function to remove '/base' from the branch names
presented to the user.

Signed-off-by: Tom Zanussi 
---
 scripts/lib/bsp/engine.py |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8e53f00..cda1d14 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -449,6 +449,16 @@ def boolean(input_str, name):
 return name
 
 
+def strip_base(input_str):
+"""
+strip '/base' off the end of input_str, so we can use 'base' in
+the branch names we present to the user.
+"""
+if input_str and input_str.endswith("/base"):
+return input_str[:-len("/base")]
+return input_str.strip()
+
+
 deferred_choices = {}
 
 def gen_choices_defer(input_line, context, checklist = False):
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 00/19] yocto-bsp updates for master, v2

[tom . zanussi]

From: Tom Zanussi 

This patchset fixes yocto bugs [YOCTO #2693] and [YOCTO #2587], and
fixes some other minor usability problems reported by users.

Please pull into poky/master.

v2: This is the same patchset as the previous one, but an additional
couple of patches fixing problems found in testing has been tacked on.

v3: This removes all instances of YOCTO_KERNEL_EXTERNAL_BRANCH usage
 - some were missed the last time around.

The following changes since commit 2dec760b79bb7e2e79c33c5127fa64685bd86a18:

  foomatic: fix perl path for target (2012-08-08 10:06:00 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib.git 
tzanussi/yocto-bsp-master-update.v3
  
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/yocto-bsp-master-update.v3

Tom Zanussi (19):
  yocto-bsp: add new strip_base() function
  yocto-bsp: strip '/base' from kernel branches in templates
  yocto-bsp: update default branch names
  yocto-bsp: allow branch display filtering
  yocto-bsp: use branches_base
  yocto-bsp: add standard branch mapping
  yocto-bsp: use standard branch mapping in bsp templates
  yocto-bsp: use rstrip() for assignment lines
  yocto-bsp: remove 'branch' statements in .scc if reusing branch
  yocto-bsp: add some standard policy
  yocto-bsp: add i586 option for i386
  yocto-bsp: use emgd 1.10 for i386 template
  yocto-bsp: generate default properties even if json specified
  yocto-bsp: add 3.4/remove 3.0 kernel from templates
  yocto-bsp: update standard branch mapping
  yocto-bsp: use emgd 1.14 for i386 template
  yocto-bsp: remove YOCTO_KERNEL_EXTERNAL_BRANCH usage
  yocto-bsp: use base branches for qemu 'newbranch' case
  yocto-bsp: add missing xserver-xf86-config .bbappend for qemu

 scripts/lib/bsp/engine.py  |   44 ++--
 scripts/lib/bsp/kernel.py  |   19 +
 .../linux/files/{{=machine}}-standard.scc  |1 +
 .../arm/recipes-kernel/linux/kernel-list.noinstall |4 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |   13 +++---
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |   13 +++---
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
 .../arch/i386/conf/machine/{{=machine}}.conf   |   14 ---
 .../linux/files/{{=machine}}-preempt-rt.scc|7 
 .../linux/files/{{=machine}}-standard.scc  |   14 ++-
 .../recipes-kernel/linux/files/{{=machine}}.scc|2 +-
 .../recipes-kernel/linux/kernel-list.noinstall |4 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
 .../linux/files/{{=machine}}-standard.scc  |1 +
 .../recipes-kernel/linux/kernel-list.noinstall |4 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
 .../linux/files/{{=machine}}-standard.scc  |1 +
 .../recipes-kernel/linux/files/{{=machine}}.scc|3 --
 .../recipes-kernel/linux/kernel-list.noinstall |4 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
 .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |2 +
 .../linux/files/{{=machine}}-preempt-rt.scc|5 +--
 .../linux/files/{{=machine}}-standard.scc  |9 ++--
 .../recipes-kernel/linux/kernel-list.noinstall |4 +-
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |   25 +--
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   29 ++---
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |   25 +--
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   29 ++---
 .../linux/files/{{=machine}}-preempt-rt.scc|7 
 .../linux/files/{{=machine}}-standard.scc  |   10 -
 .../recipes-kernel/linux/kernel-list.noinstall |4 +-
 ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |   39 -
 ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
 ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   36 
 ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" |   41 --
 ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
 ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   36 
 47 files changed, 321 insertions(+), 312 deletions(-)
 rename "scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux

[yocto] [PATCH 3/3] [meta-intel] meta-romley: Add Matrox MGA variable to romley.conf

[kishore . k . bodke]

From: Kishore Bodke 

Since Matrox MGA recipe is moved to common, include
the Matrox MGA varialbe to romley.conf.

Signed-off-by: Kishore Bodke 
---
 meta-romley/conf/machine/romley.conf |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-romley/conf/machine/romley.conf 
b/meta-romley/conf/machine/romley.conf
index e6a755b..f7cfa18 100644
--- a/meta-romley/conf/machine/romley.conf
+++ b/meta-romley/conf/machine/romley.conf
@@ -12,6 +12,5 @@ require conf/machine/include/ia32-base.inc
 
 XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
-   xserver-xorg-module-xaa \
-  xf86-video-mga \
+  ${XSERVER_IA32_MATROX_MGA} \
"
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/3] [meta-intel] meta-intel:Add a MATROX MGA variable to ia32-base.inc

[kishore . k . bodke]

From: Kishore Bodke 

Add XSERVER_IA32_MATROX_MGA variable for including
Matrox MGA graphics recipe.

Signed-off-by: Kishore Bodke 
---
 conf/machine/include/ia32-base.inc |4 
 1 file changed, 4 insertions(+)

diff --git a/conf/machine/include/ia32-base.inc 
b/conf/machine/include/ia32-base.inc
index 99ac352..8dd6743 100644
--- a/conf/machine/include/ia32-base.inc
+++ b/conf/machine/include/ia32-base.inc
@@ -60,3 +60,7 @@ XSERVER_IA32_EMGD = "emgd-driver-bin \
"
 
 XSERVER_IA32_VESA = "xf86-video-vesa"
+
+XSERVER_IA32_MATROX_MGA = "xserver-xorg-module-xaa \
+   xf86-video-mga \
+   "
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/3] [meta-intel] meta-romley: Move Matrox MGA Xorg driver to meta-intel/common

[kishore . k . bodke]

From: Kishore Bodke 

Matrox MGA Xorg driver is being used by other meta-intel
BSPs.  So move this to meta-intel/common/recipes-graphics.

Signed-off-by: Kishore Bodke 
---
 .../xorg-driver/xf86-video-mga_1.4.13.bb   |0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename {meta-romley => 
common}/recipes-graphics/xorg-driver/xf86-video-mga_1.4.13.bb (100%)

diff --git a/meta-romley/recipes-graphics/xorg-driver/xf86-video-mga_1.4.13.bb 
b/common/recipes-graphics/xorg-driver/xf86-video-mga_1.4.13.bb
similarity index 100%
rename from meta-romley/recipes-graphics/xorg-driver/xf86-video-mga_1.4.13.bb
rename to common/recipes-graphics/xorg-driver/xf86-video-mga_1.4.13.bb
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/3] [meta-intel] Move Matrox MGA Xorg driver to common

[kishore . k . bodke]

From: Kishore Bodke 

Hi,

These patches are for moving the Matrox MGA Xorg driver from
meta-romley to meta-intel/common and adding a variable to 
include the mga recipe in the respective BSPs which uses them.

Romley BSP has been successfully booted with sato desktop.

Please pull into meta-intel/master.

Thanks
Kishore.

The following changes since commit ff7fdafba88a5b7676f601b3d16a97ce7d48c4a9:

  crownbay: make v3.4 the default kernel (2012-07-31 23:08:05 -0500)

are available in the git repository at:

  git://git.pokylinux.org/meta-intel-contrib kishore/matrox-mga
  http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=kishore/matrox-mga

Kishore Bodke (3):
  meta-romley: Move Matrox MGA Xorg driver to meta-intel/common
  meta-intel:Add a MATROX MGA variable to ia32-base.inc
  meta-romley: Add Matrox MGA variable to romley.conf

 .../xorg-driver/xf86-video-mga_1.4.13.bb   |0
 conf/machine/include/ia32-base.inc |4 
 meta-romley/conf/machine/romley.conf   |3 +--
 3 files changed, 5 insertions(+), 2 deletions(-)
 rename {meta-romley => 
common}/recipes-graphics/xorg-driver/xf86-video-mga_1.4.13.bb (100%)

-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem with BSP supporting different machines

[Markus Hubig]

On Fri, Aug 10, 2012 at 12:50:00PM -0400, Bruce Ashfield wrote:
> On Fri, Aug 10, 2012 at 11:01 AM, Markus Hubig  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 wrote:
> >
> > 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 ...

| [INFO] Sanitizing meta/cfgportuxg20
^
  Something get's crippled here!

> that wasn't, or didn't get migrated to the source tree. I can
> reproduce this with the layer that you provided before ?

Yes, but please pull bevor. I have two branches now 1.3_M3 and denzil.
I got this error with 1.3_M3 (both poky and my bsp) and linux 3.2 & 3.4.

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

Nice, Thanks!

Cheers, Markus
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] external-sourcery-toolchain: do_compile failed for sqlite3-3.7.13

[Elvis Dowson]

Hi,
  I get a build failure for sqlite3-3.7.13 with external-sourcery-toolchain 
mentor-2012.03-71-powerpc-mentor-linux-gnu.bin:


ERROR: Function failed: do_compile (see 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/sqlite3-3.7.13-r0/temp/log.do_compile.48315
 for further information)
ERROR: Logfile of failure stored in: 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/sqlite3-3.7.13-r0/temp/log.do_compile.48315
Log data follows:
| DEBUG: SITE files ['endian-big', 'bit-32', 'powerpc-common', 'common-linux', 
'common-glibc', 'powerpc32-linux', 'powerpc-linux', 'common']
| DEBUG: Executing shell function do_compile
| NOTE: make -j 6
| ./powerpc-poky-linux-libtool --tag=CC   --mode=compile 
powerpc-mentor-linux-gnu-gcc  -m32  -msoft-float -mcpu=440 -msoft-float 
--sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -DPACKAGE_NAME=\"sqlite\" 
-DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.7.13\" 
-DPACKAGE_STRING=\"sqlite\ 3.7.13\" 
-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; -DPACKAGE_URL=\"\" 
-DPACKAGE=\"sqlite\" -DVERSION=\"3.7.13\" -D_FILE_OFFSET_BITS=64 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 
-DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_READLINE=1 
-DHAVE_POSIX_FALLOCATE=1 -I.-D_REENTRANT=1 -DSQLITE_THREADSAFE=1  
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -O2 -pipe -g 
-feliminate-unused-debug-types -c -o sqlite3.lo sqlite3.c
| powerpc-mentor-linux-gnu-gcc  -m32  -msoft-float -mcpu=440 -msoft-float 
--sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -DPACKAGE_NAME=\"sqlite\" 
-DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.7.13\" 
-DPACKAGE_STRING=\"sqlite\ 3.7.13\" 
-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; -DPACKAGE_URL=\"\" 
-DPACKAGE=\"sqlite\" -DVERSION=\"3.7.13\" -D_FILE_OFFSET_BITS=64 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 
-DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_READLINE=1 
-DHAVE_POSIX_FALLOCATE=1 -I.-D_REENTRANT=1 -DSQLITE_THREADSAFE=1  
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -O2 -pipe -g 
-feliminate-unused-debug-types -c shell.c
| powerpc-poky-linux-libtool: compile:  powerpc-mentor-linux-gnu-gcc -m32 
-msoft-float -mcpu=440 -msoft-float 
--sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -DPACKAGE_NAME=\"sqlite\" 
-DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.7.13\" 
"-DPACKAGE_STRING=\"sqlite 3.7.13\"" 
-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; -DPACKAGE_URL=\"\" 
-DPACKAGE=\"sqlite\" -DVERSION=\"3.7.13\" -D_FILE_OFFSET_BITS=64 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 
-DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_READLINE=1 
-DHAVE_POSIX_FALLOCATE=1 -I. -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -O2 -pipe -g 
-feliminate-unused-debug-types -c sqlite3.c  -fPIC -DPIC -o .libs/sqlite3.o
| powerpc-poky-linux-libtool: compile:  powerpc-mentor-linux-gnu-gcc -m32 
-msoft-float -mcpu=440 -msoft-float 
--sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -DPACKAGE_NAME=\"sqlite\" 
-DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.7.13\" 
"-DPACKAGE_STRING=\"sqlite 3.7.13\"" 
-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; -DPACKAGE_URL=\"\" 
-DPACKAGE=\"sqlite\" -DVERSION=\"3.7.13\" -D_FILE_OFFSET_BITS=64 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 
-DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_READLINE=1 
-DHAVE_POSIX_FALLOCATE=1 -I. -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -O2 -pipe -g 
-feliminate-unused-debug-types -c sqlite3.c -o sqlite3.o >/dev/null 2>&1
| ./powerpc-poky-linux-libtool --tag=CC   --mode=link 
powerpc-mentor-linux-gnu-gcc  -m32  -msoft-float -mcpu=440 -msoft-float 
--sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -D_REENTRANT=1 
-DSQLITE_THREADSAFE=1  -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -O2 -pipe -g 
-feliminate-unused-debug-types -no-undefined -version-info 8:6:8 -Wl,-O1 
-Wl,--hash-style=gnu -o libsqlite3.la -rpath /usr/lib sqlite3.lo  -ldl -lpthread
| powerpc-poky

Re: [yocto] external-sourcery-toolchain: cp: cannot stat `/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': No such file or directory

[Elvis Dowson]

Hi,

On Aug 10, 2012, at 9:07 PM, Elvis Dowson wrote:

> When using the mentor external-sourcery-toolchain, I get the following error:
> 
> NOTE: package gdbm-1.10-r3: task do_configure: Started
> ERROR: Function failed: do_configure (see 
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409
>  for further information)
> ERROR: Logfile of failure stored in: 
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409
> Log data follows:
> | DEBUG: Executing python function sysroot_cleansstate
> | DEBUG: Python function sysroot_cleansstate finished
> | DEBUG: SITE files ['endian-big', 'bit-32', 'powerpc-common', 
> 'common-linux', 'common-glibc', 'powerpc32-linux', 'powerpc-linux', 'common']
> | DEBUG: Executing shell function do_configure
> | automake (GNU automake) 1.12.1
> | Copyright (C) 2012 Free Software Foundation, Inc.
> | License GPLv2+: GNU GPL version 2 or later 
> 
> | This is free software: you are free to change and redistribute it.
> | There is NO WARRANTY, to the extent permitted by law.
> | 
> | Written by Tom Tromey 
> |and Alexandre Duret-Lutz .
> | AUTOV is 1.12
> | cp: cannot stat 
> `/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': 
> No such file or directory
> | ERROR: Function failed: do_configure (see 
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409
>  for further information)
> NOTE: package gdbm-1.10-r3: task do_configure: Failed
> ERROR: Task 541 (/tool/yocto/poky/meta/recipes-support/gdbm/gdbm_1.10.bb, 
> do_configure) failed with exit code '1'
> 

I solved the problem, I ignored a warning saying that there were multiple 
providers for virtual/gettext. 

When I looked at the target folder, gettext was missing. 

I added the following entry to my local.conf file, and the build is now 
progressing :

PREFERRED_PROVIDER_virtual/gettext = "gettext"

Elvis Dowson


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] external-sourcery-toolchain: cp: cannot stat `/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': No such file or directory

[Elvis Dowson]

Hi,
   When using the mentor external-sourcery-toolchain, I get the following 
error:

NOTE: package gdbm-1.10-r3: task do_configure: Started
ERROR: Function failed: do_configure (see 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409
 for further information)
ERROR: Logfile of failure stored in: 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: SITE files ['endian-big', 'bit-32', 'powerpc-common', 'common-linux', 
'common-glibc', 'powerpc32-linux', 'powerpc-linux', 'common']
| DEBUG: Executing shell function do_configure
| automake (GNU automake) 1.12.1
| Copyright (C) 2012 Free Software Foundation, Inc.
| License GPLv2+: GNU GPL version 2 or later 

| This is free software: you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
| 
| Written by Tom Tromey 
|and Alexandre Duret-Lutz .
| AUTOV is 1.12
| cp: cannot stat 
`/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': 
No such file or directory
| ERROR: Function failed: do_configure (see 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409
 for further information)
NOTE: package gdbm-1.10-r3: task do_configure: Failed
ERROR: Task 541 (/tool/yocto/poky/meta/recipes-support/gdbm/gdbm_1.10.bb, 
do_configure) failed with exit code '1'


Best regards,

Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] external-sourcery-toolchain: ERROR: QA Issue: No GNU_HASH in the elf binary

[Elvis Dowson]

Hi,

On Aug 10, 2012, at 8:41 PM, Chris Larson wrote:

> On Fri, Aug 10, 2012 at 9:37 AM, Elvis Dowson  wrote:
>>  I'm building with the mentor external-sourcery-toolchain.
>> 
>> I get the following error:
>> 
>> ERROR: QA Issue: No GNU_HASH in the elf binary:
>> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipcloak'
>> ERROR: QA Issue: No GNU_HASH in the elf binary:
>> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zip'
>> ERROR: QA Issue: No GNU_HASH in the elf binary:
>> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipsplit'
>> ERROR: QA Issue: No GNU_HASH in the elf binary:
>> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipnote'
>> ERROR: QA run found fatal errors. Please consider fixing them.
>> ERROR: Function failed: do_package_qa
>> ERROR: Logfile of failure stored in:
>> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/temp/log.do_package.47453
>> 
>> Adding the following statement to zip.bb doesn't fix the problem, like it
>> used to when using the gcc-4.x compilers:
>> 
>> TARGET_CC_ARCH += "${LDFLAGS}"
> 
> I have bits that work around this by making the ldflags/gnu_hash check
> nonfatal when using this toolchain, but they haven't gone into oe-core
> yet. See 
> https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L87-94
> for details. You should be able to try a build using this layer, or
> just grab those bits and put them into your oe-core
> tcmode-external-sourcery.inc.
> 
> I haven't had time to pursue this meta-sourcery wrt upstream yet, but
> I think in the long term it's the best approach for supporting the
> sourcery g++ toolchain. I think all we should keep in oe-core is
> either a sample/example config, a link to that layer, or a
> configuration for a toolchain that doesn't require as much tweaking
> (e.g. tuning arguments), such as crosstool-ng. That isn't related to
> your issue, but is why I haven't been quite as proactive about pushing
> fixes to the tcmode in oe-core recently.

Copy pasting the tcmode-external-sourcery.inc file from your meta-sourcery 
repo, to oe-core fixes the issue.

Thanks for the timely assist!!  :-)

Best regards,

Elvis Dowson

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem with BSP supporting different machines

[Bruce Ashfield]

On Fri, Aug 10, 2012 at 11:01 AM, Markus Hubig  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 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-po

Re: [yocto] external-sourcery-toolchain: ERROR: QA Issue: No GNU_HASH in the elf binary

[Chris Larson]

On Fri, Aug 10, 2012 at 9:37 AM, Elvis Dowson  wrote:
>   I'm building with the mentor external-sourcery-toolchain.
>
> I get the following error:
>
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipcloak'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zip'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipsplit'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipnote'
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/temp/log.do_package.47453
>
> Adding the following statement to zip.bb doesn't fix the problem, like it
> used to when using the gcc-4.x compilers:
>
> TARGET_CC_ARCH += "${LDFLAGS}"

I have bits that work around this by making the ldflags/gnu_hash check
nonfatal when using this toolchain, but they haven't gone into oe-core
yet. See 
https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L87-94
for details. You should be able to try a build using this layer, or
just grab those bits and put them into your oe-core
tcmode-external-sourcery.inc.

I haven't had time to pursue this meta-sourcery wrt upstream yet, but
I think in the long term it's the best approach for supporting the
sourcery g++ toolchain. I think all we should keep in oe-core is
either a sample/example config, a link to that layer, or a
configuration for a toolchain that doesn't require as much tweaking
(e.g. tuning arguments), such as crosstool-ng. That isn't related to
your issue, but is why I haven't been quite as proactive about pushing
fixes to the tcmode in oe-core recently.
-- 
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] external-sourcery-toolchain: ERROR: QA Issue: No GNU_HASH in the elf binary

[Elvis Dowson]

Hi,
  I'm building with the mentor external-sourcery-toolchain. 

I get the following error:

ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipcloak'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zip'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipsplit'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipnote'
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in: 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/temp/log.do_package.47453

Adding the following statement to zip.bb doesn't fix the problem, like it used 
to when using the gcc-4.x compilers:

TARGET_CC_ARCH += "${LDFLAGS}"

Best regards,

Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] external-sourcery-toolchain: ERROR: Function failed: do_install

[Chris Larson]

On Fri, Aug 10, 2012 at 8:59 AM, Elvis Dowson  wrote:
> I found the solution. I had to specify NO32LIBS = "0", since I'm building on
> an Ubuntu 12.04 64-bit machine.
>
> # Set the toolchain.
> TCMODE = "external-csl"
> EXTERNAL_TOOLCHAIN = "/tool/mentor/csl-2012.03.71"
> NO32LIBS = "0"
> CSL_TARGET_SYS_powerpc = "powerpc-mentor-linux-gnu"

Yeah, we should probably make the tcmode set that — things get unhappy
due to the LD_PRELOAD when it tries to run the 32 bit toolchain
binaries without a 32 bit libpseudo around.
-- 
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] external-sourcery-toolchain: ERROR: Function failed: do_install

[Elvis Dowson]

Hi,

On Aug 10, 2012, at 7:37 PM, Elvis Dowson wrote:

> I cloned the meta-sourcery repo, added it to my bblayers.conf
> 
> $ cd /tool/yocto
> $ git clone git://github.com/MentorEmbedded/meta-sourcery.git
> 
> I specified the following variables in my local.conf:
> 
> # Set the toolchain.
> TCMODE = "external-csl"
> EXTERNAL_TOOLCHAIN = "/tool/mentor/csl-2011.03-39"
> CSL_TARGET_SYS_powerpc = "powerpc-eabi"
> 
> I get the following error, when I try to run bitbake core-image-minimal:
> 
> ERROR: Function failed: do_install (see 
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
>  for further information)
> ERROR: Logfile of failure stored in: 
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
> Log data follows:
> | DEBUG: Executing shell function do_install
> | cp: target 
> `/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/image/lib'
>  is not a directory
> | ERROR: Function failed: do_install (see 
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
>  for further information)
> NOTE: package external-sourcery-toolchain-2011.03-39-r12: task do_install: 
> Failed
> ERROR: Task 41 
> (/tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, 
> do_install) failed with exit code '1'
> Waiting for 3 running tasks to finish:
> 0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
> 1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
> 2: zlib-native-1.2.7-r0 do_compile (pid 31632)
> NOTE: package attr-native-2.4.46-r4: task do_fetch: Started
> Waiting for 4 running tasks to finish:
> 0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
> 1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
> 2: zlib-native-1.2.7-r0 do_compile (pid 31632)
> 3: attr-native-2.4.46-r4 do_fetch (pid 31843)
> NOTE: package attr-native-2.4.46-r4: task do_fetch: Succeeded
> Waiting for 3 running tasks to finish:
> 0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
> 1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
> 2: zlib-native-1.2.7-r0 do_compile (pid 31632)
> NOTE: package openssl-native-1.0.0j-r15.3: task do_unpack: Succeeded
> Waiting for 2 running tasks to finish:
> 0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
> 1: zlib-native-1.2.7-r0 do_compile (pid 31632)
> NOTE: package zlib-native-1.2.7-r0: task do_compile: Succeeded
> Waiting for 1 running tasks to finish:
> 0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
> NOTE: package ncurses-native-5.9-r10.1: task do_configure: Succeeded
> NOTE: Tasks Summary: Attempted 97 tasks of which 63 didn't need to be rerun 
> and 1 failed.
> 
> Summary: 1 task failed:
>   /tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, 
> do_install
> Summary: There were 5 ERROR messages shown, returning a non-zero exit code.
> 
> How can I resolve this error?
> 

I found the solution. I had to specify NO32LIBS = "0", since I'm building on an 
Ubuntu 12.04 64-bit machine.

# Set the toolchain.
TCMODE = "external-csl"
EXTERNAL_TOOLCHAIN = "/tool/mentor/csl-2012.03.71"
NO32LIBS = "0"
CSL_TARGET_SYS_powerpc = "powerpc-mentor-linux-gnu"

PREFERRED_PROVIDER_linux-libc-headers = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial = 
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate = 
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = 
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc = 
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs = 
"external-sourcery-toolchain"
PREFERRED_PROVIDER_libgcc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_eglibc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libintl = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libiconv = "external-sourcery-toolchain"
PREFERRED_PROVIDER_gdbserver = "external-sourcery-toolchain"

The build is progressing along now.

Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] external-sourcery-toolchain: ERROR: Function failed: do_install

[Elvis Dowson]

Hi,
   I cloned the meta-sourcery repo, added it to my bblayers.conf

$ cd /tool/yocto
$ git clone git://github.com/MentorEmbedded/meta-sourcery.git

I specified the following variables in my local.conf:

# Set the toolchain.
TCMODE = "external-csl"
EXTERNAL_TOOLCHAIN = "/tool/mentor/csl-2011.03-39"
CSL_TARGET_SYS_powerpc = "powerpc-eabi"

I get the following error, when I try to run bitbake core-image-minimal:

ERROR: Function failed: do_install (see 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
 for further information)
ERROR: Logfile of failure stored in: 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
Log data follows:
| DEBUG: Executing shell function do_install
| cp: target 
`/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/image/lib'
 is not a directory
| ERROR: Function failed: do_install (see 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
 for further information)
NOTE: package external-sourcery-toolchain-2011.03-39-r12: task do_install: 
Failed
ERROR: Task 41 
(/tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, 
do_install) failed with exit code '1'
Waiting for 3 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
2: zlib-native-1.2.7-r0 do_compile (pid 31632)
NOTE: package attr-native-2.4.46-r4: task do_fetch: Started
Waiting for 4 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
2: zlib-native-1.2.7-r0 do_compile (pid 31632)
3: attr-native-2.4.46-r4 do_fetch (pid 31843)
NOTE: package attr-native-2.4.46-r4: task do_fetch: Succeeded
Waiting for 3 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
2: zlib-native-1.2.7-r0 do_compile (pid 31632)
NOTE: package openssl-native-1.0.0j-r15.3: task do_unpack: Succeeded
Waiting for 2 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: zlib-native-1.2.7-r0 do_compile (pid 31632)
NOTE: package zlib-native-1.2.7-r0: task do_compile: Succeeded
Waiting for 1 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
NOTE: package ncurses-native-5.9-r10.1: task do_configure: Succeeded
NOTE: Tasks Summary: Attempted 97 tasks of which 63 didn't need to be rerun and 
1 failed.

Summary: 1 task failed:
  /tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, 
do_install
Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

How can I resolve this error?

Best regards,

Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem with BSP supporting different machines

[Markus Hubig]

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

|  

Re: [yocto] Questions about 'bitbake core-image-minimal'

[Trevor Woerner]

On Thu, Aug 9, 2012 at 5:38 AM, ☆星空☆  wrote:
> 1)I find some package like "automake, autoconf" existing on my host ,can I
> use "automake" which is already installed on my host rather than to do tasks
> to install (do_fetch,do_compile) and How  .

The job of automake/automake is just to create the Makefiles which the
"make" utility can use to compile software; this is but one small
component in the overall task of cross-compiling software for an
embedded target. So your question would be similar to someone asking
"Why does Yocto have to build the software? Can't I just use wget and
download the sources myself?" Which you can, but once you're done you
still don't have anything you can use on your embedded device.

> 2)Why first do_fetch quilt-native ,where the dependency on native devtools
> things are from.

One of the many things making embedded cross-development complicated
is that everyone is free to use whatever version of whatever Linux
distribution they want on their host systems. As it turns out, the
small differences between distributions and (more importantly) the
different versions of the various tools used to do embedded
development on each of these system often leads to not being able to
successfully complete various tasks (of which there are many).
Therefore tools like OE or Yocto are smart in that they start off by
checking your host system and setting up a known-to-work set of native
tools which it then will use to perform the remainder of its tasks.

Where these dependencies are specifically being pulled in from I'm not
100% sure, but it's probably not too hard to find, and you wouldn't
want to disable them anyway.

One concrete example of this sort of issue is: recently it wasn't
possible to compile certain version of the Linux kernel using the
"make" utility version 3.82.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SPAM] - Re: [SPAM] - Re: image recipe gives error: has no buildable providers - Email found in subject - Email found in subject

[Tim Verstraete]

In fact the email has put the strange spaces and so on in between the text 
apparently ... I have redone the yocto-bsp create and now it seems to work. 

Thanks for the feedback,

Kind regards,

Tim


-Original Message-
From: Tom Zanussi [mailto:tom.zanu...@intel.com] 
Sent: woensdag 8 augustus 2012 18:19
To: Tim Verstraete
Cc: Robert P. J. Day; McClintock Matthew-B29882; yocto@yoctoproject.org
Subject: [SPAM] - Re: [yocto] [SPAM] - Re: image recipe gives error: has no 
buildable providers - Email found in subject - Email found in subject

On Wed, 2012-08-08 at 15:50 +, Tim Verstraete wrote:
> Yes, this was automatically generate yocto-bsp create test-test1 arm
> 

Nah, yocto-bsp doesn't output things like what you have in your version e.g. 
priority 25, missing spaces after the PATTERN variable, and yes, the extra 
spaces in the middle of variables.  Somehow those things got into your version, 
randomly or otherwise.  Here's what I get using the
above:

$ yocto-bsp create test-test1 arm

# We have a conf and classes directory, add to BBPATH   
 
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a recipes directory, add to BBFILES   
 
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \   
 
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "test-test1"
BBFILE_PATTERN_test-test1 := "^${LAYERDIR}/"
BBFILE_PRIORITY_test-test1 = "6"

> -Original Message-
> From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
> Sent: woensdag 8 augustus 2012 17:17
> To: Tim Verstraete
> Cc: McClintock Matthew-B29882; yocto@yoctoproject.org
> Subject: [SPAM] - Re: [yocto] image recipe gives error: has no 
> buildable providers - Email found in subject
> 
> On Wed, 8 Aug 2012, Tim Verstraete wrote:
> 
> > Hi,
> >
> > What i see is that when i do bitbake-layers show_layers that it shows the 
> > correct layers and the correct priority of the layers.
> >
> > The layers.conf is the following
> >
> > # We have a conf and classes directory, add to BBPATH BBPATH := 
> > "${BBPATH}:${LAYERDIR}"
> >
> > # We have a recipes directory, add to BBFILES BBFILES := "${BBFILES} 
> > ${LAYERDIR}/recipes-*/*/*.bb \
> > ${LAYERDIR}/recipes-*/*/*.bbappend"
> >
> >  BBFILE_COLLECTIONS += "test-test1"
> >  BBFILE_PATTERN_ test-test1:= "^${LAYERDIR}/"
> >  BBFILE_PRIORITY_ test-test1 = "25"
>^ space?
> 
>   did you seriously copy and paste the above?  because it's just wrong.
> 
> rday
> 


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto