[linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A
Hi Bruce,
  I am seeing some unexpected behavior of the v3.8 kernel bits. Here is what I 
am trying to do.

I am seeing this build error:

ERROR: Function failed: do_validate_branches (see 
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-poky-linux/linux-yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf24_b170394a475b96ecc9
2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for further 
information)
ERROR: Logfile of failure stored in: 
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-poky-linux/linux-yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf24_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5


This is with the master branches of poky & oecore + v3.8 bbappends in the 
meta-intel layer.

* poky.git :  master: commit 93ec7b4d1550e07caec86e2998d0f94a01c7e785

* meta-intel.git :  master: commit 4ffe40409f8cd0f354a7488113ef888b42867033

And this is my v3.8 bbappend in the meta-intel
meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :


FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

COMPATIBLE_MACHINE_emenlow = "emenlow"
KMACHINE_emenlow = "emenlow"
KBRANCH_emenlow = "standard/emenlow"
KERNEL_FEATURES_emenlow_append = " features/drm-emgd/drm-emgd-1.16 cfg/vesafb"

COMPATIBLE_MACHINE_emenlow-noemgd = "emenlow-noemgd"
KMACHINE_emenlow-noemgd = "emenlow"
KBRANCH_emenlow-noemgd = "standard/emenlow"
KERNEL_FEATURES_emenlow-noemgd_append = " features/drm-gma500/drm-gma600"

SRCREV_meta_emenlow = "c2ed0f16fdec628242a682897d5d86df4547cf24"
SRCREV_machine_emenlow = "b170394a475b96ecc92cbc9e4b002bed0a9f69c5"
SRCREV_emgd_emenlow = "caea08c988e0f41103bbe18eafca20348f95da02"

SRCREV_meta_emenlow-noemgd = "c2ed0f16fdec628242a682897d5d86df4547cf24"
SRCREV_machine_emenlow-noemgd = "b170394a475b96ecc92cbc9e4b002bed0a9f69c5"

SRC_URI_emenlow = 
"git://git.yoctoproject.org/linux-yocto-dev.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},emgd-1.16;name=machine,meta,emgd"


All the commit IDs are valid on the v3.8 kernel repository. So I don't see any 
reason for the
build error as seen above. I notice this issue is happening only for the BSPs 
which has emgd
branch in the SRC_URI. The same commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5 
giving
error is also used by the rest of the non emgd BSPs, and they don't see the 
error.

So I think the kernel tools are probably making some mistake when emgd branch 
is specified in the SRC_URI.

Let me know how you can help me out here.

Thanks,
Nitin

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


Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield

On 13-03-05 11:33 AM, Kamble, Nitin A wrote:

Hi Bruce,

   I am seeing some unexpected behavior of the v3.8 kernel bits. Here is
what I am trying to do.



Something is up with your linux-yocto clone:

> git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
Author: Tom Zanussi 
Date:   Fri Oct 5 11:35:26 2012 -0500

perf annotate: replace 'expand' with equivalent sed expression

We don't have 'expand' in our userspace so we need to accomplish the
same thing using 'sed', which we do have.

Signed-off-by: Tom Zanussi 

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 07aaeea..ff162ae 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -826,7 +826,7 @@ fallback:
snprintf(command, sizeof(command),
 "%s %s%s --start-address=0x%016" PRIx64
 " --stop-address=0x%016" PRIx64
-" -d %s %s -C %s|grep -v %s|expand",
+" -d %s %s -C %s|grep -v %s|sed 's/\t//g'",
 objdump_path ? objdump_path : "objdump",
 disassembler_style ? "-M " : "",
 disassembler_style ? disassembler_style : "",

> git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
  standard/arm-versatile-926ejs
  standard/base
  standard/beagleboard
  standard/ck
  standard/common-pc-64/base
  standard/common-pc-64/chiefriver
  standard/common-pc-64/crystalforest
  standard/common-pc-64/jasperforest
  standard/common-pc-64/rangeley
  standard/common-pc-64/romley
  standard/common-pc-64/sugarbay
  standard/common-pc/atom-pc
  standard/common-pc/base
  standard/crownbay
  standard/edf
  standard/emenlow
  standard/fri2
  standard/fsl-mpc8315e-rdb
  standard/mti-malta32
  standard/mti-malta64
  standard/preempt-rt/base
  standard/preempt-rt/fri2
  standard/preempt-rt/qemuppc
  standard/preempt-rt/routerstationpro
  standard/qemuppc
  standard/routerstationpro
  standard/sys940x
  standard/tiny/base
  standard/tiny/common-pc
  standard/tiny/fri2

Whereas the tree you have locally doesn't have the commit at all.

Bruce



I am seeing this build error:

ERROR: Function failed: do_validate_branches (see
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-poky-linux/linux-yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf24_b170394a475b96ecc9

2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
further information)

ERROR: Logfile of failure stored in:
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-poky-linux/linux-yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf24_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414

Log data follows:

| DEBUG: Executing shell function do_validate_branches

| error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5

This is with the master branches of poky & oecore + v3.8 bbappends in
the meta-intel layer.

* poky.git :  master: commit 93ec7b4d1550e07caec86e2998d0f94a01c7e785

* meta-intel.git :  master: commit 4ffe40409f8cd0f354a7488113ef888b42867033

And this is my v3.8 bbappend in the meta-intel

meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

COMPATIBLE_MACHINE_emenlow = "emenlow"

KMACHINE_emenlow = "emenlow"

KBRANCH_emenlow = "standard/emenlow"

KERNEL_FEATURES_emenlow_append = " features/drm-emgd/drm-emgd-1.16
cfg/vesafb"

COMPATIBLE_MACHINE_emenlow-noemgd = "emenlow-noemgd"

KMACHINE_emenlow-noemgd = "emenlow"

KBRANCH_emenlow-noemgd = "standard/emenlow"

KERNEL_FEATURES_emenlow-noemgd_append = " features/drm-gma500/drm-gma600"

SRCREV_meta_emenlow = "c2ed0f16fdec628242a682897d5d86df4547cf24"

SRCREV_machine_emenlow = "b170394a475b96ecc92cbc9e4b002bed0a9f69c5"

SRCREV_emgd_emenlow = "caea08c988e0f41103bbe18eafca20348f95da02"

SRCREV_meta_emenlow-noemgd = "c2ed0f16fdec628242a682897d5d86df4547cf24"

SRCREV_machine_emenlow-noemgd = "b170394a475b96ecc92cbc9e4b002bed0a9f69c5"

SRC_URI_emenlow =
"git://git.yoctoproject.org/linux-yocto-dev.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},emgd-1.16;name=machine,meta,emgd"

All the commit IDs are valid on the v3.8 kernel repository. So I don’t
see any reason for the

build error as seen above. I notice this issue is happening only for the
BSPs which has emgd

branch in the SRC_URI. The same commit
b170394a475b96ecc92cbc9e4b002bed0a9f69c5 giving

error is also used by the rest of the non emgd BSPs, and they don’t see
the error.

So I think the kernel tools are probably making some mistake when emgd
branch is specified in the SRC_URI.

Let me know how you can help me out here.

Thanks,

Nitin



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


Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield

On 13-03-05 11:39 AM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:37 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 11:33 AM, Kamble, Nitin A wrote:

Hi Bruce,

I am seeing some unexpected behavior of the v3.8 kernel bits. Here
is what I am trying to do.



Something is up with your linux-yocto clone:



Hi  Bruce,
This is not with the local repo. As you can see the SRC_URI it is pointing 
to the
Upstream repo.


By local, I meant the repository the fetcher creates. That
commit ID is valid in the upstream repository, so there's nothing
I can say about why it isn't in the clone that is presented for
building.

Bruce



Nitin




  > git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
Author: Tom Zanussi 
Date:   Fri Oct 5 11:35:26 2012 -0500

  perf annotate: replace 'expand' with equivalent sed expression

  We don't have 'expand' in our userspace so we need to accomplish the
  same thing using 'sed', which we do have.

  Signed-off-by: Tom Zanussi 

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index
07aaeea..ff162ae 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -826,7 +826,7 @@ fallback:
  snprintf(command, sizeof(command),
   "%s %s%s --start-address=0x%016" PRIx64
   " --stop-address=0x%016" PRIx64
-" -d %s %s -C %s|grep -v %s|expand",
+" -d %s %s -C %s|grep -v %s|sed 's/\t//g'",
   objdump_path ? objdump_path : "objdump",
   disassembler_style ? "-M " : "",
   disassembler_style ? disassembler_style : "",

  > git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
standard/arm-versatile-926ejs
standard/base
standard/beagleboard
standard/ck
standard/common-pc-64/base
standard/common-pc-64/chiefriver
standard/common-pc-64/crystalforest
standard/common-pc-64/jasperforest
standard/common-pc-64/rangeley
standard/common-pc-64/romley
standard/common-pc-64/sugarbay
standard/common-pc/atom-pc
standard/common-pc/base
standard/crownbay
standard/edf
standard/emenlow
standard/fri2
standard/fsl-mpc8315e-rdb
standard/mti-malta32
standard/mti-malta64
standard/preempt-rt/base
standard/preempt-rt/fri2
standard/preempt-rt/qemuppc
standard/preempt-rt/routerstationpro
standard/qemuppc
standard/routerstationpro
standard/sys940x
standard/tiny/base
standard/tiny/common-pc
standard/tiny/fri2

Whereas the tree you have locally doesn't have the commit at all.

Bruce



I am seeing this build error:

ERROR: Function failed: do_validate_branches (see
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-

poky-li

nux/linux-

yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2

4_b170394a475b96ecc9

2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
further information)

ERROR: Logfile of failure stored in:
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-

poky-li

nux/linux-

yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2

4_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-

r4.0/temp/log.do_validate_b

ranches.3414

Log data follows:

| DEBUG: Executing shell function do_validate_branches

| error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5

This is with the master branches of poky & oecore + v3.8 bbappends in
the meta-intel layer.

* poky.git :  master: commit 93ec7b4d1550e07caec86e2998d0f94a01c7e785

* meta-intel.git :  master: commit
4ffe40409f8cd0f354a7488113ef888b42867033

And this is my v3.8 bbappend in the meta-intel

meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

COMPATIBLE_MACHINE_emenlow = "emenlow"

KMACHINE_emenlow = "emenlow"

KBRANCH_emenlow = "standard/emenlow"

KERNEL_FEATURES_emenlow_append = " features/drm-emgd/drm-emgd-

1.16

cfg/vesafb"

COMPATIBLE_MACHINE_emenlow-noemgd = "emenlow-noemgd"

KMACHINE_emenlow-noemgd = "emenlow"

KBRANCH_emenlow-noemgd = "standard/emenlow"

KERNEL_FEATURES_emenlow-noemgd_append = " features/drm-

gma500/drm-gma600"


SRCREV_meta_emenlow = "c2ed0f16fdec628242a682897d5d86df4547cf24"

SRCREV_machine_emenlow =

"b170394a475b96ecc92cbc9e4b002bed0a9f69c5"


SRCREV_emgd_emenlow =

"caea08c988e0f41103bbe18eafca20348f95da02"


SRCREV_meta_emenlow-noemgd =

"c2ed0f16fdec628242a682897d5d86df4547cf24"


SRCREV_machine_emenlow-noemgd =

"b170394a475b96ecc92cbc9e4b002bed0a9f69c5"


SRC_URI_emenlow =
"git://git.yoctoproject.org/linux-yocto-

dev.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},emgd-
1.16;name=machine,meta,emgd"


All the commit IDs are valid on the v3.8 kernel repository. So I don't
see any reason f

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A


> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, March 05, 2013 8:37 AM
> To: Kamble, Nitin A
> Cc: linux-yocto@yoctoproject.org
> Subject: Re: v3.8 kernel recipes in meta-intel
> 
> On 13-03-05 11:33 AM, Kamble, Nitin A wrote:
> > Hi Bruce,
> >
> >I am seeing some unexpected behavior of the v3.8 kernel bits. Here
> > is what I am trying to do.
> >
> 
> Something is up with your linux-yocto clone:  


Hi  Bruce,
   This is not with the local repo. As you can see the SRC_URI it is pointing 
to the
Upstream repo.

Nitin


> 
>  > git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
> commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
> Author: Tom Zanussi 
> Date:   Fri Oct 5 11:35:26 2012 -0500
> 
>  perf annotate: replace 'expand' with equivalent sed expression
> 
>  We don't have 'expand' in our userspace so we need to accomplish the
>  same thing using 'sed', which we do have.
> 
>  Signed-off-by: Tom Zanussi 
> 
> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index
> 07aaeea..ff162ae 100644
> --- a/tools/perf/util/annotate.c
> +++ b/tools/perf/util/annotate.c
> @@ -826,7 +826,7 @@ fallback:
>  snprintf(command, sizeof(command),
>   "%s %s%s --start-address=0x%016" PRIx64
>   " --stop-address=0x%016" PRIx64
> -" -d %s %s -C %s|grep -v %s|expand",
> +" -d %s %s -C %s|grep -v %s|sed 's/\t//g'",
>   objdump_path ? objdump_path : "objdump",
>   disassembler_style ? "-M " : "",
>   disassembler_style ? disassembler_style : "",
> 
>  > git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
>standard/arm-versatile-926ejs
>standard/base
>standard/beagleboard
>standard/ck
>standard/common-pc-64/base
>standard/common-pc-64/chiefriver
>standard/common-pc-64/crystalforest
>standard/common-pc-64/jasperforest
>standard/common-pc-64/rangeley
>standard/common-pc-64/romley
>standard/common-pc-64/sugarbay
>standard/common-pc/atom-pc
>standard/common-pc/base
>standard/crownbay
>standard/edf
>standard/emenlow
>standard/fri2
>standard/fsl-mpc8315e-rdb
>standard/mti-malta32
>standard/mti-malta64
>standard/preempt-rt/base
>standard/preempt-rt/fri2
>standard/preempt-rt/qemuppc
>standard/preempt-rt/routerstationpro
>standard/qemuppc
>standard/routerstationpro
>standard/sys940x
>standard/tiny/base
>standard/tiny/common-pc
>standard/tiny/fri2
> 
> Whereas the tree you have locally doesn't have the commit at all.
> 
> Bruce
> 
> 
> > I am seeing this build error:
> >
> > ERROR: Function failed: do_validate_branches (see
> > /srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
> poky-li
> > nux/linux-
> yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
> > 4_b170394a475b96ecc9
> >
> > 2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
> > further information)
> >
> > ERROR: Logfile of failure stored in:
> > /srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
> poky-li
> > nux/linux-
> yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
> > 4_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-
> r4.0/temp/log.do_validate_b
> > ranches.3414
> >
> > Log data follows:
> >
> > | DEBUG: Executing shell function do_validate_branches
> >
> > | error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
> >
> > This is with the master branches of poky & oecore + v3.8 bbappends in
> > the meta-intel layer.
> >
> > * poky.git :  master: commit 93ec7b4d1550e07caec86e2998d0f94a01c7e785
> >
> > * meta-intel.git :  master: commit
> > 4ffe40409f8cd0f354a7488113ef888b42867033
> >
> > And this is my v3.8 bbappend in the meta-intel
> >
> > meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >
> > COMPATIBLE_MACHINE_emenlow = "emenlow"
> >
> > KMACHINE_emenlow = "emenlow"
> >
> > KBRANCH_emenlow = "standard/emenlow"
> >
> > KERNEL_FEATURES_emenlow_append = " features/drm-emgd/drm-emgd-
> 1.16
> > cfg/vesafb"
> >
> > COMPATIBLE_MACHINE_emenlow-noemgd = "emenlow-noemgd"
> >
> > KMACHINE_emenlow-noemgd = "emenlow"
> >
> > KBRANCH_emenlow-noemgd = "standard/emenlow"
> >
> > KERNEL_FEATURES_emenlow-noemgd_append = " features/drm-
> gma500/drm-gma600"
> >
> > SRCREV_meta_emenlow = "c2ed0f16fdec628242a682897d5d86df4547cf24"
> >
> > SRCREV_machine_emenlow =
> "b170394a475b96ecc92cbc9e4b002bed0a9f69c5"
> >
> > SRCREV_emgd_emenlow =
> "caea08c988e0f41103bbe18eafca20348f95da02"
> >
> > SRCREV_meta_emenlow-noemgd =
> "c2ed0f16fdec628242a682897d5d86df4547cf24"
> >
> > SRCREV_machine_emenlow-noemgd =
> "b170394a475b96ecc92cbc9e4b002bed0a9f69c5"
> >
> > SRC_URI_emenlow =
> > "git://git.yoctoproject.org/linux-yocto-
> dev.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},emgd-
> 1.16;name=machine,me

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield

On 13-03-05 12:00 PM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:41 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 11:39 AM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:37 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 11:33 AM, Kamble, Nitin A wrote:

Hi Bruce,

 I am seeing some unexpected behavior of the v3.8 kernel bits.
Here is what I am trying to do.



Something is up with your linux-yocto clone:



Hi  Bruce,
 This is not with the local repo. As you can see the SRC_URI it is
pointing to the Upstream repo.


By local, I meant the repository the fetcher creates. That commit ID is valid in
the upstream repository, so there's nothing I can say about why it isn't in the
clone that is presented for building.

Bruce


Bruce,
   I tried doing "bitbake cleanall " for the linux-yocto recipe. And it removed 
my local copy,
  and in the next build, it did take lot of time to clone it. But still the 
same build error.

I wonder why the same commit & topic branch is working for emenlow-noemgd BSP
and does not working for emenlow? The only relevant difference I see here is  
SRCURI.


What do you see if you head into the linux source build dir and
run the same commands that I tried below ?

Bruce



Nitin





Nitin




   > git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
Author: Tom Zanussi 
Date:   Fri Oct 5 11:35:26 2012 -0500

   perf annotate: replace 'expand' with equivalent sed expression

   We don't have 'expand' in our userspace so we need to accomplish the
   same thing using 'sed', which we do have.

   Signed-off-by: Tom Zanussi 

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 07aaeea..ff162ae 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -826,7 +826,7 @@ fallback:
   snprintf(command, sizeof(command),
"%s %s%s --start-address=0x%016" PRIx64
" --stop-address=0x%016" PRIx64
-" -d %s %s -C %s|grep -v %s|expand",
+" -d %s %s -C %s|grep -v %s|sed 's/\t//g'",
objdump_path ? objdump_path : "objdump",
disassembler_style ? "-M " : "",
disassembler_style ? disassembler_style : "",

   > git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
 standard/arm-versatile-926ejs
 standard/base
 standard/beagleboard
 standard/ck
 standard/common-pc-64/base
 standard/common-pc-64/chiefriver
 standard/common-pc-64/crystalforest
 standard/common-pc-64/jasperforest
 standard/common-pc-64/rangeley
 standard/common-pc-64/romley
 standard/common-pc-64/sugarbay
 standard/common-pc/atom-pc
 standard/common-pc/base
 standard/crownbay
 standard/edf
 standard/emenlow
 standard/fri2
 standard/fsl-mpc8315e-rdb
 standard/mti-malta32
 standard/mti-malta64
 standard/preempt-rt/base
 standard/preempt-rt/fri2
 standard/preempt-rt/qemuppc
 standard/preempt-rt/routerstationpro
 standard/qemuppc
 standard/routerstationpro
 standard/sys940x
 standard/tiny/base
 standard/tiny/common-pc
 standard/tiny/fri2

Whereas the tree you have locally doesn't have the commit at all.

Bruce



I am seeing this build error:

ERROR: Function failed: do_validate_branches (see
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-

poky-li

nux/linux-

yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2

4_b170394a475b96ecc9

2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
further information)

ERROR: Logfile of failure stored in:
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-

poky-li

nux/linux-

yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2

4_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-

r4.0/temp/log.do_validate_b

ranches.3414

Log data follows:

| DEBUG: Executing shell function do_validate_branches

| error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5

This is with the master branches of poky & oecore + v3.8 bbappends
in the meta-intel layer.

* poky.git :  master: commit
93ec7b4d1550e07caec86e2998d0f94a01c7e785

* meta-intel.git :  master: commit
4ffe40409f8cd0f354a7488113ef888b42867033

And this is my v3.8 bbappend in the meta-intel

meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

COMPATIBLE_MACHINE_emenlow = "emenlow"

KMACHINE_emenlow = "emenlow"

KBRANCH_emenlow = "standard/emenlow"

KERNEL_FEATURES_emenlow_append = " features/drm-emgd/drm-

emgd-

1.16

cfg/vesafb"

COMPA

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A


> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, March 05, 2013 8:41 AM
> To: Kamble, Nitin A
> Cc: linux-yocto@yoctoproject.org
> Subject: Re: v3.8 kernel recipes in meta-intel
> 
> On 13-03-05 11:39 AM, Kamble, Nitin A wrote:
> >
> >
> >> -Original Message-
> >> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> >> Sent: Tuesday, March 05, 2013 8:37 AM
> >> To: Kamble, Nitin A
> >> Cc: linux-yocto@yoctoproject.org
> >> Subject: Re: v3.8 kernel recipes in meta-intel
> >>
> >> On 13-03-05 11:33 AM, Kamble, Nitin A wrote:
> >>> Hi Bruce,
> >>>
> >>> I am seeing some unexpected behavior of the v3.8 kernel bits.
> >>> Here is what I am trying to do.
> >>>
> >>
> >> Something is up with your linux-yocto clone:
> >
> >
> > Hi  Bruce,
> > This is not with the local repo. As you can see the SRC_URI it is
> > pointing to the Upstream repo.
> 
> By local, I meant the repository the fetcher creates. That commit ID is valid 
> in
> the upstream repository, so there's nothing I can say about why it isn't in 
> the
> clone that is presented for building.
> 
> Bruce

Bruce,
  I tried doing "bitbake cleanall " for the linux-yocto recipe. And it removed 
my local copy,
 and in the next build, it did take lot of time to clone it. But still the same 
build error.

I wonder why the same commit & topic branch is working for emenlow-noemgd BSP 
and does not working for emenlow? The only relevant difference I see here is  
SRCURI.

Nitin

> 
> >
> > Nitin
> >
> >
> >>
> >>   > git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
> >> commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
> >> Author: Tom Zanussi 
> >> Date:   Fri Oct 5 11:35:26 2012 -0500
> >>
> >>   perf annotate: replace 'expand' with equivalent sed expression
> >>
> >>   We don't have 'expand' in our userspace so we need to accomplish the
> >>   same thing using 'sed', which we do have.
> >>
> >>   Signed-off-by: Tom Zanussi 
> >>
> >> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> >> index 07aaeea..ff162ae 100644
> >> --- a/tools/perf/util/annotate.c
> >> +++ b/tools/perf/util/annotate.c
> >> @@ -826,7 +826,7 @@ fallback:
> >>   snprintf(command, sizeof(command),
> >>"%s %s%s --start-address=0x%016" PRIx64
> >>" --stop-address=0x%016" PRIx64
> >> -" -d %s %s -C %s|grep -v %s|expand",
> >> +" -d %s %s -C %s|grep -v %s|sed 's/\t//g'",
> >>objdump_path ? objdump_path : "objdump",
> >>disassembler_style ? "-M " : "",
> >>disassembler_style ? disassembler_style : "",
> >>
> >>   > git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
> >> standard/arm-versatile-926ejs
> >> standard/base
> >> standard/beagleboard
> >> standard/ck
> >> standard/common-pc-64/base
> >> standard/common-pc-64/chiefriver
> >> standard/common-pc-64/crystalforest
> >> standard/common-pc-64/jasperforest
> >> standard/common-pc-64/rangeley
> >> standard/common-pc-64/romley
> >> standard/common-pc-64/sugarbay
> >> standard/common-pc/atom-pc
> >> standard/common-pc/base
> >> standard/crownbay
> >> standard/edf
> >> standard/emenlow
> >> standard/fri2
> >> standard/fsl-mpc8315e-rdb
> >> standard/mti-malta32
> >> standard/mti-malta64
> >> standard/preempt-rt/base
> >> standard/preempt-rt/fri2
> >> standard/preempt-rt/qemuppc
> >> standard/preempt-rt/routerstationpro
> >> standard/qemuppc
> >> standard/routerstationpro
> >> standard/sys940x
> >> standard/tiny/base
> >> standard/tiny/common-pc
> >> standard/tiny/fri2
> >>
> >> Whereas the tree you have locally doesn't have the commit at all.
> >>
> >> Bruce
> >>
> >>
> >>> I am seeing this build error:
> >>>
> >>> ERROR: Function failed: do_validate_branches (see
> >>> /srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
> >> poky-li
> >>> nux/linux-
> >> yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
> >>> 4_b170394a475b96ecc9
> >>>
> >>> 2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
> >>> further information)
> >>>
> >>> ERROR: Logfile of failure stored in:
> >>> /srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
> >> poky-li
> >>> nux/linux-
> >> yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
> >>> 4_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-
> >> r4.0/temp/log.do_validate_b
> >>> ranches.3414
> >>>
> >>> Log data follows:
> >>>
> >>> | DEBUG: Executing shell function do_validate_branches
> >>>
> >>> | error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
> >>>
> >>> This is with the master branches of poky & oecore + v3.8 bbappends
> >>> in the meta-intel layer.
> >>>
> >>> * poky.git :  master: commit
> >>> 93ec7b4d1550e07caec86e2998d0f94a01c7e785
> >>>
> >>> * meta-intel.git

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield

On 13-03-05 12:13 PM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 9:05 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 12:00 PM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:41 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 11:39 AM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:37 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 11:33 AM, Kamble, Nitin A wrote:

Hi Bruce,

  I am seeing some unexpected behavior of the v3.8 kernel bits.
Here is what I am trying to do.



Something is up with your linux-yocto clone:



Hi  Bruce,
  This is not with the local repo. As you can see the SRC_URI it
is pointing to the Upstream repo.


By local, I meant the repository the fetcher creates. That commit ID
is valid in the upstream repository, so there's nothing I can say
about why it isn't in the clone that is presented for building.

Bruce


Bruce,
I tried doing "bitbake cleanall " for the linux-yocto recipe. And it removed

my local copy,

   and in the next build, it did take lot of time to clone it. But still the 
same

build error.


I wonder why the same commit & topic branch is working for
emenlow-noemgd BSP and does not working for emenlow? The only

relevant difference I see here is  SRCURI.

What do you see if you head into the linux source build dir and run the same
commands that I tried below ?

Bruce


$ git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
fatal: bad object b170394a475b96ecc92cbc9e4b002bed0a9f69c5

$ git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5

# currently checkout out branch is standard/emenlow

$ git log | grep "perf annotate: replace 'expand' with equivalent sed 
expression" -C 4 -n
30028-commit 2dbb9df035d1ebfb435cb200b262aa7570382877
30029-Author: Tom Zanussi 
30030-Date:   Fri Oct 5 11:35:26 2012 -0500
30031-
30032:perf annotate: replace 'expand' with equivalent sed expression
30033-
30034-We don't have 'expand' in our userspace so we need to accomplish the
30035-same thing using 'sed', which we do have.
30036-


So the topic branch commit is present much deeper in the branch with different 
commit-id.
May be merging of the emgd branch resulted it. Is it issue with the emgd branch 
rebased
to an undesired point?


It shouldn't be. That commit shouldn't be present in the repository
at all (it isn't in mine). The emgd branches are off master, same
repo and can't bring in something like this.

So something is getting tied in a knot when the repository is fetched
into the source dir.

For your builds that work, do you have that commit present ?

Bruce



Nitin






Nitin





Nitin




> git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
Author: Tom Zanussi 
Date:   Fri Oct 5 11:35:26 2012 -0500

perf annotate: replace 'expand' with equivalent sed
expression

We don't have 'expand' in our userspace so we need to accomplish

the

same thing using 'sed', which we do have.

Signed-off-by: Tom Zanussi 

diff --git a/tools/perf/util/annotate.c
b/tools/perf/util/annotate.c index 07aaeea..ff162ae 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -826,7 +826,7 @@ fallback:
snprintf(command, sizeof(command),
 "%s %s%s --start-address=0x%016" PRIx64
 " --stop-address=0x%016" PRIx64
-" -d %s %s -C %s|grep -v %s|expand",
+" -d %s %s -C %s|grep -v %s|sed 's/\t//g'",
 objdump_path ? objdump_path : "objdump",
 disassembler_style ? "-M " : "",
 disassembler_style ? disassembler_style : "",

> git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
  standard/arm-versatile-926ejs
  standard/base
  standard/beagleboard
  standard/ck
  standard/common-pc-64/base
  standard/common-pc-64/chiefriver
  standard/common-pc-64/crystalforest
  standard/common-pc-64/jasperforest
  standard/common-pc-64/rangeley
  standard/common-pc-64/romley
  standard/common-pc-64/sugarbay
  standard/common-pc/atom-pc
  standard/common-pc/base
  standard/crownbay
  standard/edf
  standard/emenlow
  standard/fri2
  standard/fsl-mpc8315e-rdb
  standard/mti-malta32
  standard/mti-malta64
  standard/preempt-rt/base
  standard/preempt-rt/fri2
  standard/preempt-rt/qemuppc
  sta

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A


> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, March 05, 2013 9:05 AM
> To: Kamble, Nitin A
> Cc: linux-yocto@yoctoproject.org
> Subject: Re: v3.8 kernel recipes in meta-intel
> 
> On 13-03-05 12:00 PM, Kamble, Nitin A wrote:
> >
> >
> >> -Original Message-
> >> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> >> Sent: Tuesday, March 05, 2013 8:41 AM
> >> To: Kamble, Nitin A
> >> Cc: linux-yocto@yoctoproject.org
> >> Subject: Re: v3.8 kernel recipes in meta-intel
> >>
> >> On 13-03-05 11:39 AM, Kamble, Nitin A wrote:
> >>>
> >>>
>  -Original Message-
>  From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>  Sent: Tuesday, March 05, 2013 8:37 AM
>  To: Kamble, Nitin A
>  Cc: linux-yocto@yoctoproject.org
>  Subject: Re: v3.8 kernel recipes in meta-intel
> 
>  On 13-03-05 11:33 AM, Kamble, Nitin A wrote:
> > Hi Bruce,
> >
> >  I am seeing some unexpected behavior of the v3.8 kernel bits.
> > Here is what I am trying to do.
> >
> 
>  Something is up with your linux-yocto clone:
> >>>
> >>>
> >>> Hi  Bruce,
> >>>  This is not with the local repo. As you can see the SRC_URI it
> >>> is pointing to the Upstream repo.
> >>
> >> By local, I meant the repository the fetcher creates. That commit ID
> >> is valid in the upstream repository, so there's nothing I can say
> >> about why it isn't in the clone that is presented for building.
> >>
> >> Bruce
> >
> > Bruce,
> >I tried doing "bitbake cleanall " for the linux-yocto recipe. And it 
> > removed
> my local copy,
> >   and in the next build, it did take lot of time to clone it. But still the 
> > same
> build error.
> >
> > I wonder why the same commit & topic branch is working for
> > emenlow-noemgd BSP and does not working for emenlow? The only
> relevant difference I see here is  SRCURI.
> 
> What do you see if you head into the linux source build dir and run the same
> commands that I tried below ?
> 
> Bruce

$ git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
fatal: bad object b170394a475b96ecc92cbc9e4b002bed0a9f69c5

$ git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5

# currently checkout out branch is standard/emenlow

$ git log | grep "perf annotate: replace 'expand' with equivalent sed 
expression" -C 4 -n
30028-commit 2dbb9df035d1ebfb435cb200b262aa7570382877
30029-Author: Tom Zanussi 
30030-Date:   Fri Oct 5 11:35:26 2012 -0500
30031-
30032:perf annotate: replace 'expand' with equivalent sed expression
30033-
30034-We don't have 'expand' in our userspace so we need to accomplish the
30035-same thing using 'sed', which we do have.
30036-


So the topic branch commit is present much deeper in the branch with different 
commit-id.
May be merging of the emgd branch resulted it. Is it issue with the emgd branch 
rebased
to an undesired point?

Nitin


> 
> >
> > Nitin
> >
> >>
> >>>
> >>> Nitin
> >>>
> >>>
> 
> > git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
>  commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
>  Author: Tom Zanussi 
>  Date:   Fri Oct 5 11:35:26 2012 -0500
> 
> perf annotate: replace 'expand' with equivalent sed
>  expression
> 
> We don't have 'expand' in our userspace so we need to accomplish
> the
> same thing using 'sed', which we do have.
> 
> Signed-off-by: Tom Zanussi 
> 
>  diff --git a/tools/perf/util/annotate.c
>  b/tools/perf/util/annotate.c index 07aaeea..ff162ae 100644
>  --- a/tools/perf/util/annotate.c
>  +++ b/tools/perf/util/annotate.c
>  @@ -826,7 +826,7 @@ fallback:
> snprintf(command, sizeof(command),
>  "%s %s%s --start-address=0x%016" PRIx64
>  " --stop-address=0x%016" PRIx64
>  -" -d %s %s -C %s|grep -v %s|expand",
>  +" -d %s %s -C %s|grep -v %s|sed 's/\t//g'",
>  objdump_path ? objdump_path : "objdump",
>  disassembler_style ? "-M " : "",
>  disassembler_style ? disassembler_style : "",
> 
> > git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
>   standard/arm-versatile-926ejs
>   standard/base
>   standard/beagleboard
>   standard/ck
>   standard/common-pc-64/base
>   standard/common-pc-64/chiefriver
>   standard/common-pc-64/crystalforest
>   standard/common-pc-64/jasperforest
>   standard/common-pc-64/rangeley
>   standard/common-pc-64/romley
>   standard/common-pc-64/sugarbay
>   standard/common-pc/atom-pc
>   standard/common-pc/base
>   standard/crownbay
>   standard/edf
>   standard/emenlow
>   stand