[yocto] yocto build fails
Hi all, I have been trying to build on Ubuntu 11.0.4. I think I have followed the online documentation correctly. I have also followed the wiki page, which is required for me, to set up the proxy servers. However, the build is still failing for me. This is for Bernard-5.0.1. I get the following message NOTE: Executing RunQueue Tasks NOTE: Running task 697 of 1863 (ID: 484, /home/green/mdgray/yocto/poky-bernard-5.0.1/meta/recipes-kernel/linux/linux-yocto_git.bb, do_fetch) NOTE: package linux-yocto-2.6.37+git1+212cae404e57ff9dc58c808035770d51325c3512_1+c75cbd202d8abb0b5f316f934f5d33c17ff6d3c3-r16: task do_fetch: Started ERROR: Function 'Fetcher failure for URL: 'git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta'. Unable to fetch URL git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta from any source.' failed ERROR: Logfile of failure stored in: /home/green/mdgray/yocto/poky-5.0.1-build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+212cae404e57ff9dc58c808035770d51325c3512_1+c75cbd202d8abb0b5f316f934f5d33c17ff6d3c3-r16/temp/log.do_fetch.8521 Log data follows: | NOTE: fetch http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz | Cloning into bare repository /home/green/mdgray/yocto/poky-5.0.1-build/downloads/git2/git.pokylinux.org.linux-yocto-2.6.37... | nc: read failed (0/3): Broken pipe | fatal: The remote end hung up unexpectedly | ERROR: Function 'Fetcher failure for URL: 'git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta'. Unable to fetch URL git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta from any source.' failed | NOTE: package linux-yocto-2.6.37+git1+212cae404e57ff9dc58c808035770d51325c3512_1+c75cbd202d8abb0b5f316f934f5d33c17ff6d3c3-r16: task do_fetch: Failed ERROR: Task 484 (/home/green/mdgray/yocto/poky-bernard-5.0.1/meta/recipes-kernel/linux/linux-yocto_git.bb, do_fetch) failed with exit code '1' ERROR: '/home/green/mdgray/yocto/poky-bernard-5.0.1/meta/recipes-kernel/linux/linux-yocto_git.bb' failed On closer inspection, the file http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz is unavailable in the repo. I did a search and I could only find http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz.bad Can anyone help me on this? Thanks Mark -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] when checksums collide -- the saga of linux-2.6.37.2.tar.bz2
while the problem has since gone away, something strange happened yesterday i figured i'd share. as a quick test, wanted to build core-image-sato so started with: $ bitbake -c fetchall core-image-sato just to grab everything and i'd start the build later. but, as i reported yesterday, fetch failed for two packages, one of them being that linux tarball, linux-2.6.37.2.tar.bz2. being lazy, back off a bit and just go for a minimal image: $ bitbake -c fetchall core-image-minimal unsurprisingly, the fetch for the linux tarball still failed for the same reason as before -- incorrect checksums. huh. i typically don't expect to see that in a simple fetch. so check KERNELORG_MIRROR (http site), *manually* download that tarball and, sure enough, its md5 and sha256 sums are the (incorrect) ones that bitbake is reporting, which don't match what's expected. how odd. (i verified this two additional times, same result.) just as a test, i edited the bitbake.conf and changed KERNELORG_MIRROR to refer to the kernel ftp site, cleared out the remnants of that fetch, re-ran it and ... success! huh? so the tarball via http is broken, but the one via ftp is good? but it was late, so i just threw up my hands and went to bed. this morning, manually download both tarballs (ftp and http), check their sums and ... they match! reset everything, go back to the original http KERNELORG_MIRROR value and it's all good. what the heck was *that* all about? obviously, the fetch issue is now resolved but i'm baffled as to what happened there. 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] when checksums collide -- the saga of linux-2.6.37.2.tar.bz2
On Friday 15 July 2011 11:47:44 Robert P. J. Day wrote: > unsurprisingly, the fetch for the linux tarball still failed for the > same reason as before -- incorrect checksums. huh. i typically don't > expect to see that in a simple fetch. so check KERNELORG_MIRROR (http > site), *manually* download that tarball and, sure enough, its md5 and > sha256 sums are the (incorrect) ones that bitbake is reporting, which > don't match what's expected. how odd. (i verified this two > additional times, same result.) > > just as a test, i edited the bitbake.conf and changed > KERNELORG_MIRROR to refer to the kernel ftp site, cleared out the > remnants of that fetch, re-ran it and ... success! huh? so the > tarball via http is broken, but the one via ftp is good? but it was > late, so i just threw up my hands and went to bed. > > this morning, manually download both tarballs (ftp and http), check > their sums and ... they match! reset everything, go back to the > original http KERNELORG_MIRROR value and it's all good. what the heck > was *that* all about? Do you still have the tarball with the bad md5sum? Can you diff the contents? Or was it simply a case of the bad tarball being truncated? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] when checksums collide -- the saga of linux-2.6.37.2.tar.bz2
On Fri, 15 Jul 2011, Paul Eggleton wrote: > On Friday 15 July 2011 11:47:44 Robert P. J. Day wrote: > > unsurprisingly, the fetch for the linux tarball still failed for the > > same reason as before -- incorrect checksums. huh. i typically don't > > expect to see that in a simple fetch. so check KERNELORG_MIRROR (http > > site), *manually* download that tarball and, sure enough, its md5 and > > sha256 sums are the (incorrect) ones that bitbake is reporting, which > > don't match what's expected. how odd. (i verified this two > > additional times, same result.) > > > > just as a test, i edited the bitbake.conf and changed > > KERNELORG_MIRROR to refer to the kernel ftp site, cleared out the > > remnants of that fetch, re-ran it and ... success! huh? so the > > tarball via http is broken, but the one via ftp is good? but it was > > late, so i just threw up my hands and went to bed. > > > > this morning, manually download both tarballs (ftp and http), check > > their sums and ... they match! reset everything, go back to the > > original http KERNELORG_MIRROR value and it's all good. what the heck > > was *that* all about? > > Do you still have the tarball with the bad md5sum? Can you diff the > contents? Or was it simply a case of the bad tarball being > truncated? sadly, i tossed the "bad" tarball, but i do recall that when i just tried to check the contents with "tar tvjf", it eventually reported unexpected EOF -- yes, i might have mentioned that earlier. :-P so i'll just chalk it up to cosmic rays or something, but i did try the same thing three times and got the same error result all three times. this morning, though, everything's back to normal. go figure. 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] [PATCH] DOCS: Fix spelling error in link to Fedora sudo page.
Signed-off-by: Robert P. J. Day --- diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 52f7391..c0ba207 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -180,7 +180,7 @@ If you are using a Fedora version prior to version 15 you will need to take some extra steps to enable sudo. -See for details. +See for details. -- 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] [PATCH] DOCS: Correct format of command continuation.
Signed-off-by: Robert P. J. Day --- i *think* this is what the author had in mind. diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 52f7391..d2e85ba 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -213,9 +213,9 @@ - $ sudo zypper install python gcc gcc-c++ libtool - $ subversion git chrpath automake - $ help2man diffstat texinfo mercurial wget + $ sudo zypper install python gcc gcc-c++ libtool \ + subversion git chrpath automake \ + help2man diffstat texinfo mercurial wget -- 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] [PATCH] mpc8315e-rdb: Set TARGET_FPU correct
On Jul 15, 2011, at 12:31 AM, Bruce Ashfield wrote:
> On 11-07-15 12:56 AM, Kumar Gala wrote:
>> The MPC8315E has a e300c3 core in it with 'classic' or normal PPC
>> floating point.
>>
>> 'SPE' floating point is what exists on the e500v2 core.
>
> Acked-by: Bruce Ashfield
>
> Been meaning to change this for a while, the good news, is that
> the setting doesn't make any difference at the moment :)
>
> Cheers,
>
> Bruce
True, I want to use this for configure toolchain properly:
I'm looking at doing the following for when SPE is set:
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc
b/meta/recipes-devtools/gcc/gcc-common.inc
index 7bf036c..409ad01 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -12,6 +12,8 @@ FILESDIR =
"${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
def get_gcc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return "--with-float=soft"
+if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
+return "--enable-e500_double"
return ""
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] mpc8315e-rdb: Set TARGET_FPU correct
On 07/15/11 08:29, Kumar Gala wrote:
On Jul 15, 2011, at 12:31 AM, Bruce Ashfield wrote:
On 11-07-15 12:56 AM, Kumar Gala wrote:
The MPC8315E has a e300c3 core in it with 'classic' or normal PPC
floating point.
'SPE' floating point is what exists on the e500v2 core.
Acked-by: Bruce Ashfield
Been meaning to change this for a while, the good news, is that
the setting doesn't make any difference at the moment :)
Cheers,
Bruce
True, I want to use this for configure toolchain properly:
I'm looking at doing the following for when SPE is set:
Definitely. It was simply good fortune that it hadn't been
used yet. And when something like you are doing arrives, we
want to have it right. Just to have it right, is a good enough
reason!
Cheers,
Bruce
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc
b/meta/recipes-devtools/gcc/gcc-common.inc
index 7bf036c..409ad01 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -12,6 +12,8 @@ FILESDIR =
"${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
def get_gcc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return "--with-float=soft"
+if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
+return "--enable-e500_double"
return ""
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/6] meta-intel: add a couple common .inc files
Hi Tom, On Thu, 2011-07-14 at 19:55 -0500, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > The meta-intel BSPs currently have a number of machine settings common > to all - factor these out into a couple common include files. For reference common include files are usually placed in conf/machine/include/. If that happens they also need non-generic suitably namespaced names, likely including "x86" or "ia32" in this case. The benefit is you can then refer to one of these includes from another layer. It also means you can refer to them as: include conf/machine/includes/xxx in other conf files removing some of the potential path issues. I do like the cleanup this gives though, this is just a detail! :) Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] toolchain queries
On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote: > Where is the best place to ask questions and try and get support for adding > some toolchain variations in? > > I'm wanting to add support in for a few different flavors of PPC that are not > currently supported: > > * e500v2 (gcc needs --enable-e500_double, eglibc > * e5500 (64-bit embedded ppc) > * e5500 - multilib support for 32/64-bit > The other reason I ask is the recipes today don't seem to use (or allow for use of) --with-cpu. Wondering who is the expect on these recipes to discuss such issues with. - k ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/6] meta-intel: add a couple common .inc files
On Fri, 2011-07-15 at 06:23 -0700, Richard Purdie wrote: > Hi Tom, > > On Thu, 2011-07-14 at 19:55 -0500, tom.zanu...@intel.com wrote: > > From: Tom Zanussi > > > > The meta-intel BSPs currently have a number of machine settings common > > to all - factor these out into a couple common include files. > > For reference common include files are usually placed in > conf/machine/include/. If that happens they also need non-generic > suitably namespaced names, likely including "x86" or "ia32" in this > case. > > The benefit is you can then refer to one of these includes from another > layer. > > It also means you can refer to them as: > > include conf/machine/includes/xxx > > in other conf files removing some of the potential path issues. > > I do like the cleanup this gives though, this is just a detail! :) > Yeah, I wasn't sure all that would be welcome in there. ;-) I'll respin it that way and resubmit... Thanks for the input, Tom > Cheers, > > Richard > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] toolchain queries
On Fri, 2011-07-15 at 08:33 -0500, Kumar Gala wrote: > On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote: > > > Where is the best place to ask questions and try and get support for adding > > some toolchain variations in? > > > > I'm wanting to add support in for a few different flavors of PPC that are > > not currently supported: > > > > * e500v2 (gcc needs --enable-e500_double, eglibc > > * e5500 (64-bit embedded ppc) > > * e5500 - multilib support for 32/64-bit > > > > The other reason I ask is the recipes today don't seem to use (or allow for > use of) --with-cpu. > > Wondering who is the expect on these recipes to discuss such issues with. The tune files (conf/machine/include/tune*) usually set the march and mcpu options which are added to CFLAGS. Does that provide the functionality you're looking for? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1][linux-yocto] Fix boot failure with less than 17 MB RAM
On 07/14/11 18:27, Darren Hart wrote: From: Darren Hart The following patch from mainline addresses an issues that prevented my qemu testing from booting in less than 17M of memory. With this page, the kernel can boot to init in 8M of memory. Apply to yocto/standard/base The following changes since commit bb8e31f2c99f5e007660d4540df246fb7ecfa746: USB: ehci: remove structure packing from ehci_def (2011-06-22 14:23:26 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib dvhart/mm http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=dvhart/mm This has been merged and pushed to the kernel repos, the SRCREV updates are pending. Cheers, Bruce Yinghai Lu (1): mm: use alloc_bootmem_node_nopanic() on really needed path include/linux/bootmem.h |2 ++ mm/page_alloc.c |7 --- 2 files changed, 6 insertions(+), 3 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] couple questions about toolchains from QS manual
(look on the bright side -- eventually, after many, many patches, i will have nothing left to whine about.) from quick start manual, i notice that all toolchain tarballs have "sdk" in the filename, whereas the actual downloads have "gmae". a simple textual fix, i'm assuming. (what means "gmae"?) more significantly, QS manual states that toolchains "should" be installed under /opt/poky. "should" is a loaded word -- it implies a recommendation for some benefit but not an actual requirement. and installing it there requires the reader to have root privilege, something to be avoided if at all possible. can someone clarify the "shouldness" or "mustness" of toolchain installation under /opt/poky? 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] couple questions about toolchains from QS manual
On Fri, 2011-07-15 at 10:15 -0400, Robert P. J. Day wrote: > (look on the bright side -- eventually, after many, many patches, i > will have nothing left to whine about.) :) > from quick start manual, i notice that all toolchain tarballs have > "sdk" in the filename, whereas the actual downloads have "gmae". a > simple textual fix, i'm assuming. (what means "gmae"?) GMAE = GNOME Mobile and Embedded think cut down GNOME. > more significantly, QS manual states that toolchains "should" be > installed under /opt/poky. "should" is a loaded word -- it implies a > recommendation for some benefit but not an actual requirement. and > installing it there requires the reader to have root privilege, > something to be avoided if at all possible. > > can someone clarify the "shouldness" or "mustness" of toolchain > installation under /opt/poky? At this point its a requirement, we'd like to relax that but it isn't possible right now. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple questions about toolchains from QS manual
On Fri, 15 Jul 2011, Richard Purdie wrote: > On Fri, 2011-07-15 at 10:15 -0400, Robert P. J. Day wrote: > > (look on the bright side -- eventually, after many, many patches, i > > will have nothing left to whine about.) > > :) > > > from quick start manual, i notice that all toolchain tarballs have > > "sdk" in the filename, whereas the actual downloads have "gmae". a > > simple textual fix, i'm assuming. (what means "gmae"?) > > GMAE = GNOME Mobile and Embedded > > think cut down GNOME. ah, of course. > > more significantly, QS manual states that toolchains "should" be > > installed under /opt/poky. "should" is a loaded word -- it > > implies a recommendation for some benefit but not an actual > > requirement. and installing it there requires the reader to have > > root privilege, something to be avoided if at all possible. > > > > can someone clarify the "shouldness" or "mustness" of toolchain > > installation under /opt/poky? > > At this point its a requirement, we'd like to relax that but it > isn't possible right now. ok, then that sentence should simply be reworded to make it clear that it's not optional and root privilege is required. patch to follow shortly. rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] DOCS: Fix spelling error in link to Fedora sudo page.
Good catch Robert. I have fixed this and pushed. Will notify maintainer. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Friday, July 15, 2011 5:04 AM To: Yocto discussion list Subject: [yocto] [PATCH] DOCS: Fix spelling error in link to Fedora sudo page. Signed-off-by: Robert P. J. Day --- diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 52f7391..c0ba207 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -180,7 +180,7 @@ If you are using a Fedora version prior to version 15 you will need to take some extra steps to enable sudo. -See for details. +See for details. -- 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple questions about toolchains from QS manual
Wording change taken care of. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Richard Purdie Sent: Friday, July 15, 2011 7:25 AM To: Robert P. J. Day Cc: Yocto discussion list Subject: Re: [yocto] couple questions about toolchains from QS manual On Fri, 2011-07-15 at 10:15 -0400, Robert P. J. Day wrote: > (look on the bright side -- eventually, after many, many patches, i > will have nothing left to whine about.) :) > from quick start manual, i notice that all toolchain tarballs have > "sdk" in the filename, whereas the actual downloads have "gmae". a > simple textual fix, i'm assuming. (what means "gmae"?) GMAE = GNOME Mobile and Embedded think cut down GNOME. > more significantly, QS manual states that toolchains "should" be > installed under /opt/poky. "should" is a loaded word -- it implies a > recommendation for some benefit but not an actual requirement. and > installing it there requires the reader to have root privilege, > something to be avoided if at all possible. > > can someone clarify the "shouldness" or "mustness" of toolchain > installation under /opt/poky? At this point its a requirement, we'd like to relax that but it isn't possible right now. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] DOCS: Fix toolchain filenames in QS guide, "sdk" -> "gmae"
Signed-off-by: Robert P. J. Day --- i think i got them all, i didn't see any other references anywhere in the docs directory. does this look right? diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 52f7391..62c95ae 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -425,7 +425,7 @@ - yocto-eglibc- -toolchain-sdk- .tar.bz2 + yocto-eglibc - -toolchain-gmae- .tar.bz2 Where: is a string representing your development system: @@ -443,7 +443,7 @@ - yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2 + yocto-eglibc-x86_64-i686-toolchain-gmae-1.0.tar.bz2 @@ -455,7 +455,7 @@ $ cd / - $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2 + $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-gmae-1.0.tar.bz2 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] couple questions about toolchains from QS manual
On Fri, 15 Jul 2011, Rifenbark, Scott M wrote: > Wording change taken care of. > > Scott ok, i can cross that off my list, thanks. rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] DOCS: Fix toolchain filenames in QS guide, "sdk" -> "gmae"
Robert, You can cross this off your list. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Friday, July 15, 2011 7:47 AM To: Yocto discussion list Subject: [yocto] [PATCH] DOCS: Fix toolchain filenames in QS guide, "sdk" -> "gmae" Signed-off-by: Robert P. J. Day --- i think i got them all, i didn't see any other references anywhere in the docs directory. does this look right? diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 52f7391..62c95ae 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -425,7 +425,7 @@ - yocto-eglibc- -toolchain-sdk- .tar.bz2 + yocto-eglibc - -toolchain-gmae- .tar.bz2 Where: is a string representing your development system: @@ -443,7 +443,7 @@ - yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2 + yocto-eglibc-x86_64-i686-toolchain-gmae-1.0.tar.bz2 @@ -455,7 +455,7 @@ $ cd / - $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2 + $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-gmae-1.0.tar.bz2 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Technical Team (Tuesday, July 12, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))
Attendees: Dave, Paul, Darren, Jeff, Dirk, Richard, Josh, Tom, Koen, Saul, Mark, Denys, Jason, Beth, Song Action item list: * Team: please take a look at the proposed post 1.1 items (yellow in the M3 table, this is a draft, may change) on the wiki page and let Song know if there is any comment or concerns. * Saul: talk to Jianjun, QA should work with developers to make sure we can cover more distro testing (informal) before major release. Joshua and Darren volunteers for some of these testing. * Song: check status with Jianjun on Stabilization tasks he owned. * Darren/Song: define specific deliverables of 'Fast boot time' for M3 and Yocto 1.1. * Saul: circulate the idea of having a Sprint B for M3 via emails. * Saul: check update commits (one release criteria) Minutes: * opens - 5 min - Darren: documentation process for release, making sure we can update the README.hardware after release if needed. (no time for this one this time, will put this on next week's agenda) * Review Yocto 1.1 M2 schedule (Sprint and Stabilize tasks) and Release Criteria - 15 min (Song) See details at: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria - All M2 items are already done. - One M2 stabilization item is done, 3 in progress - QA does not have resource for N+1 distro testing for every milestone release. But will do that for 1.1 release. - Kernel version lock: Linux 3.0 should be released by next week. Yocto 1.1 target is 3.0+, lock in Linux 3.0 now (minimum). Will decide on 3.1 on Aug 15, the beginning of M4. - All M2 high bugs now are committed to make M2. - There are new bugs from the most recent QA test. Saul will follow up with the team. * Review M3 feature list, M3 Sprint B? -20 min (Song) - Sync qemugl with MeeGo - Implementation: was on the drop list, Edwin feels that he may be able to work on this if BSP work progresses well. We should be clear that BSP development work takes higher priority, if this one does not make 1.1, it is fine. Will keep this one on drop list. - 'BSP update/intro': it should be fine without this for Yocto 1.1. Will work on this post 1.1. - Fast boot time: it goes hand in hand with image side reduction. Darren will define the specifics for M3/1.1 deliverables. * Discussion of using Weighted Defect density as one of the release criteria - No time at this meeting for this one, will put it on next week's agenda. * Action Item Review - 5 min (Song) 1. Song: update Google calendar with the new bridge info (done) 2. Darren: open a new bug to track a BBXM related issue (done) 3. Bruce: Split bug 414 into multiple ones to work and track separately (done, bug 1204, also added feature "replace qemuppc' for post 1.1) 4. Song: send Dexuan note about bug 1099.(done, 1099 is fixed) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] toolchain queries
On Jul 15, 2011, at 8:37 AM, Richard Purdie wrote: > On Fri, 2011-07-15 at 08:33 -0500, Kumar Gala wrote: >> On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote: >> >>> Where is the best place to ask questions and try and get support for adding >>> some toolchain variations in? >>> >>> I'm wanting to add support in for a few different flavors of PPC that are >>> not currently supported: >>> >>> * e500v2 (gcc needs --enable-e500_double, eglibc >>> * e5500 (64-bit embedded ppc) >>> * e5500 - multilib support for 32/64-bit >>> >> >> The other reason I ask is the recipes today don't seem to use (or allow for >> use of) --with-cpu. >> >> Wondering who is the expect on these recipes to discuss such issues with. > > The tune files (conf/machine/include/tune*) usually set the march and > mcpu options which are added to CFLAGS. Does that provide the > functionality you're looking for? > No, I'm dealing with different configure issues for gcc, eglibc for these targets: PPC e500v2 PPC e5500 (64-bit, multilib) - k ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple questions about toolchains from QS manual
On 07/15/2011 07:15 AM, Robert P. J. Day wrote: (look on the bright side -- eventually, after many, many patches, i will have nothing left to whine about.) :) I know I can speak for the team in saying we're incredibly grateful for your help in combing through our documentation. This is a great contribution to the project. Thanks! Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] last observations about quick start guide, then moving on
1) "This optional GNOME mobile-based UI, which is intended for devices with resolution but restricted size screens ..." pretty sure there's a word missing before "resolution," no? 2) "OpenSUSE" vs "OpenSuse" ... actually, both of those are wrong, it should be "openSUSE". :-P 3) near bottom, sample command: poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin \ yocto-image-sdk-qemux86-1.0.rootfs.ext3 neither that kernel image nor rootfs are in downloads, should pick args that exist if that matters i'll let scott do with that what he will, and move on to manhandle the poky handbook. :-) 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] last observations about quick start guide, then moving on
Thanks Robert... I will deal with each of these. ScottR -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Friday, July 15, 2011 10:10 AM To: Yocto discussion list Subject: [yocto] last observations about quick start guide, then moving on 1) "This optional GNOME mobile-based UI, which is intended for devices with resolution but restricted size screens ..." pretty sure there's a word missing before "resolution," no? 2) "OpenSUSE" vs "OpenSuse" ... actually, both of those are wrong, it should be "openSUSE". :-P 3) near bottom, sample command: poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin \ yocto-image-sdk-qemux86-1.0.rootfs.ext3 neither that kernel image nor rootfs are in downloads, should pick args that exist if that matters i'll let scott do with that what he will, and move on to manhandle the poky handbook. :-) 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] the proper way to report bitbake fetch errors?
On 07/14/2011 05:01 PM, Robert P. J. Day wrote: > > just so i'm doing this the right way, what is the appropriate way to > report bitbake fetch errors? with a fully-updated git repo, i just > ran: > > $ bitbake -c fetchall -k core-image-sato > > and got fetch errors for both of: > > * sat-solver > * linux-libc-headers > > should i post the more detailed output of the command? the contents > of the log files? etc, etc. I would check the log files and verify it isn't a local network issue. After that, sharing the relevant bits of the log.do_fetch logs for the failed recipes is a good way to report them. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/6] meta-intel: add a couple common .inc files
On 07/14/2011 05:55 PM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > The meta-intel BSPs currently have a number of machine settings common > to all - factor these out into a couple common include files. > > Signed-off-by: Tom Zanussi > --- > common/common-bsp-mach.inc | 13 + > common/common-bsp-x.inc|4 > 2 files changed, 17 insertions(+), 0 deletions(-) > create mode 100644 common/common-bsp-mach.inc > create mode 100644 common/common-bsp-x.inc > > diff --git a/common/common-bsp-mach.inc b/common/common-bsp-mach.inc > new file mode 100644 > index 000..b020a84 > --- /dev/null > +++ b/common/common-bsp-mach.inc > @@ -0,0 +1,13 @@ > +MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ > +acpi serial usbgadget" > + > +KERNEL_IMAGETYPE = "bzImage" > + > +SERIAL_CONSOLE = "115200 ttyS0" > + > +MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts" > + If these are going in common .inc files we need them to be easily overridden, shouldn't all the above be using the ?= operator? -- Darren > +IMAGE_FSTYPES ?= "ext3 cpio.gz" > + > +GLIBC_ADDONS = "nptl" > +GLIBC_EXTRA_OECONF = "--with-tls" > diff --git a/common/common-bsp-x.inc b/common/common-bsp-x.inc > new file mode 100644 > index 000..c012efd > --- /dev/null > +++ b/common/common-bsp-x.inc > @@ -0,0 +1,4 @@ > +PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim" > +PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri" > +PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite" > +PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite" -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Color ghosting on BeagleBoard xM rev C
Jason, Koen, Does anything spring to mind as an obvious fix for this? Perhaps some kernel parameter initialization string for the graphics hardware? -- Darren On 07/15/2011 08:30 AM, Jeff Mitchell wrote: > Darren Hart suggested I send this to the list... > > Attached is a picture of my screen running Terminal. This is on a > BeagleBoard xM rev C connected via its HDMI out to a DVI adapter and > then into a Dell UltraSharp monitor. Angstrom doesn't display these > problems, so the setup should be fine. > > I'm not quite sure what is causing this. The resolution is also fairly > low, and I haven't had any success using boot parameters (either the > older video=omapfb:mode variant or the newer DSS2 omapfb.mode variant). > > Thanks, > Jeff > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple questions about toolchains from QS manual
On 07/15/2011 09:55 AM, Scott Garman wrote: > On 07/15/2011 07:15 AM, Robert P. J. Day wrote: >> >>(look on the bright side -- eventually, after many, many patches, i >> will have nothing left to whine about.) > > :) > > I know I can speak for the team in saying we're incredibly grateful for > your help in combing through our documentation. This is a great > contribution to the project. Agreed - thanks Robert! -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] the proper way to report bitbake fetch errors?
On Fri, 15 Jul 2011, Darren Hart wrote: > On 07/14/2011 05:01 PM, Robert P. J. Day wrote: > > > > just so i'm doing this the right way, what is the appropriate way to > > report bitbake fetch errors? with a fully-updated git repo, i just > > ran: > > > > $ bitbake -c fetchall -k core-image-sato > > > > and got fetch errors for both of: > > > > * sat-solver > > * linux-libc-headers > > > > should i post the more detailed output of the command? the contents > > of the log files? etc, etc. > > I would check the log files and verify it isn't a local network issue. > After that, sharing the relevant bits of the log.do_fetch logs for the > failed recipes is a good way to report them. ok, i'm still getting a fetch error for "sat-solver" when trying to do a fetchall for core-image-sato, and here's the log file: fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git ERROR: Function 'Fetcher failure for URL: 'git://gitorious.org/opensuse/sat-solver.git;protocol=git'. Unable to fetch URL git://gitorious.org/opensuse/sat-solver.git;protocol=git from any source.' failed except that git repo looks fine, no? http://gitorious.org/opensuse/sat-solver 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] Color ghosting on BeagleBoard xM rev C
Op 15 jul 2011, om 20:33 heeft Darren Hart het volgende geschreven: > Jason, Koen, > > Does anything spring to mind as an obvious fix for this? Perhaps some > kernel parameter initialization string for the graphics hardware? I've never seen it in angstrom, so you'd have to see what meta-yocto is doing different. In other news, for beagleboard please use the meta-ti layer for that, it's the offcial upstream for beagle and is known to work. > > -- > Darren > > On 07/15/2011 08:30 AM, Jeff Mitchell wrote: >> Darren Hart suggested I send this to the list... >> >> Attached is a picture of my screen running Terminal. This is on a >> BeagleBoard xM rev C connected via its HDMI out to a DVI adapter and >> then into a Dell UltraSharp monitor. Angstrom doesn't display these >> problems, so the setup should be fine. >> >> I'm not quite sure what is causing this. The resolution is also fairly >> low, and I haven't had any success using boot parameters (either the >> older video=omapfb:mode variant or the newer DSS2 omapfb.mode variant). >> >> Thanks, >> Jeff >> >> >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] toolchain queries
On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala wrote: > Where is the best place to ask questions and try and get support for adding > some toolchain variations in? > > I'm wanting to add support in for a few different flavors of PPC that are not > currently supported: > > * e500v2 (gcc needs --enable-e500_double, eglibc this means ABI change especially due to double formats. This should be doable in machine.conf files or tune files. > * e5500 (64-bit embedded ppc) this is new I guess. Its like adding a new arch to OE. See around http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html is roughly what can be helpful in getting ppc64 going > * e5500 - multilib support for 32/64-bit there is some thought and work RP has been doing on multilib. > > - k > ___ > 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] Color ghosting on BeagleBoard xM rev C
On 07/15/2011 03:12 PM, Koen Kooi wrote: Op 15 jul 2011, om 20:33 heeft Darren Hart het volgende geschreven: Jason, Koen, Does anything spring to mind as an obvious fix for this? Perhaps some kernel parameter initialization string for the graphics hardware? I've never seen it in angstrom, so you'd have to see what meta-yocto is doing different. In other news, for beagleboard please use the meta-ti layer for that, it's the offcial upstream for beagle and is known to work. I'm not using meta-ti because I'm working with Darren to test out support for the rev C board in meta-yocto. We just don't know what difference is causing this :-) --Jeff ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] DOCS: Add missing version number directory level to commands.
A couple commands are missing the version number directory level under the /opt/poky toolchain installation directory. Signed-off-by: Robert P. J. Day --- i'll let scott take this as well, and decide whether it's worth fixing this or just waiting for 1.1. either way works for me. diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 52f7391..a09cb66 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -513,7 +513,7 @@ - $ source /opt/poky/environment-setup--poky-linux- + $ source /opt/poky/1.0/environment-setup- -poky-linux- Where: is a string representing the target architecture: @@ -547,7 +547,7 @@ - $ source /opt/poky/environment-setup-i686-poky-linux + $ source /opt/poky/1.0/environment-setup-i686-poky-linux $ poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin yocto-image-sdk-qemux86-1.0.rootfs.ext3 -- 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] TARGET_OS issues with linux-gnuspe
In my attempts to get an e500v2/gnuspe toolchain working I was able to get core-image-minimal working. However when I try the 'meta-toolchain' I run into the following below. I believe this is because of TARGET_OS being 'linux-gnuspe'. Any ideas ? - k [kumar@right build-p2020]$ bitbake meta-toolchain OE Build Configuration: BB_VERSION= "1.13.2" TARGET_ARCH = "powerpc" TARGET_OS = "linux-gnuspe" MACHINE = "p2020-ds" DISTRO = "poky" DISTRO_VERSION= "1.0+snapshot-20110715" TARGET_FPU= "spe" meta meta-yocto= "master:068839698fe192d8846c0ed4db65861448e8e524" NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc' NOTE: Runtime target 'gcc-cross-canadian-powerpc' is unbuildable, removing... Missing or unbuildable dependency chain was: ['gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc'] NOTE: Runtime target 'task-cross-canadian-powerpc' is unbuildable, removing... Missing or unbuildable dependency chain was: ['task-cross-canadian-powerpc', 'gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc'] ERROR: Required build target 'meta-toolchain' has no buildable providers. Missing or unbuildable dependency chain was: ['meta-toolchain', 'task-cross-canadian-powerpc', 'gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc'] ERROR: Command execution failed: Traceback (most recent call last): File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 200, in buildTargets command.cooker.buildTargets(pkgs_to_build, task) File "/local/home/kumar/git/poky/bitbake/lib/bb/cooker.py", line 996, in buildTargets taskdata.add_unresolved(localdata, self.status) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 534, in add_unresolved self.remove_buildtarget(targetid) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 491, in remove_buildtarget self.fail_fnid(fnid, missing_list) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in fail_fnid self.remove_runtarget(target, missing_list) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in remove_runtarget self.fail_fnid(fnid, missing_list) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in fail_fnid self.remove_runtarget(target, missing_list) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in remove_runtarget self.fail_fnid(fnid, missing_list) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 471, in fail_fnid self.remove_buildtarget(target, missing_list) File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 501, in remove_buildtarget raise bb.providers.NoProvider(target) NoProvider: meta-toolchain ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] toolchain queries
On Jul 15, 2011, at 2:28 PM, Khem Raj wrote: > On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala wrote: >> Where is the best place to ask questions and try and get support for adding >> some toolchain variations in? >> >> I'm wanting to add support in for a few different flavors of PPC that are >> not currently supported: >> >> * e500v2 (gcc needs --enable-e500_double, eglibc > > this means ABI change especially due to double formats. This should be > doable in machine.conf > files or tune files. how so? What can I set in there that would actually get passed into gcc's configure (not really seeing anything). Also what exactly do you mean by a machine.conf >> * e5500 (64-bit embedded ppc) > > this is new I guess. Its like adding a new arch to OE. See around > http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html > is roughly what can be helpful in getting ppc64 going Thanks, will take a look at that. - k ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_OS issues with linux-gnuspe
On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala wrote:
> In my attempts to get an e500v2/gnuspe toolchain working I was able to get
> core-image-minimal working. However when I try the 'meta-toolchain' I run
> into the following below. I believe this is because of TARGET_OS being
> 'linux-gnuspe'.
>
> Any ideas ?
>
> - k
>
> [kumar@right build-p2020]$ bitbake meta-toolchain
>
> OE Build Configuration:
> BB_VERSION = "1.13.2"
> TARGET_ARCH = "powerpc"
> TARGET_OS = "linux-gnuspe"
> MACHINE = "p2020-ds"
> DISTRO = "poky"
> DISTRO_VERSION = "1.0+snapshot-20110715"
> TARGET_FPU = "spe"
> meta
> meta-yocto = "master:068839698fe192d8846c0ed4db65861448e8e524"
>
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'
here is the problem. This should have been called
virtual/powerpc-poky-linux-gnuspe-libc-for-gcc
so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
not being set correctly
and
TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
1) == ('' or 'custom')]}"
so it should be ok if TARGET_OS is set
can you pastebin output of
bitbake -e meta-toolchain
somewhere
> NOTE: Runtime target 'gcc-cross-canadian-powerpc' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['gcc-cross-canadian-powerpc',
> 'virtual/powerpc-poky-linux-libc-for-gcc']
> NOTE: Runtime target 'task-cross-canadian-powerpc' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['task-cross-canadian-powerpc',
> 'gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc']
> ERROR: Required build target 'meta-toolchain' has no buildable providers.
> Missing or unbuildable dependency chain was: ['meta-toolchain',
> 'task-cross-canadian-powerpc', 'gcc-cross-canadian-powerpc',
> 'virtual/powerpc-poky-linux-libc-for-gcc']
> ERROR: Command execution failed: Traceback (most recent call last):
> File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 102, in
> runAsyncCommand
> commandmethod(self.cmds_async, self, options)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 200, in
> buildTargets
> command.cooker.buildTargets(pkgs_to_build, task)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/cooker.py", line 996, in
> buildTargets
> taskdata.add_unresolved(localdata, self.status)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 534, in
> add_unresolved
> self.remove_buildtarget(targetid)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 491, in
> remove_buildtarget
> self.fail_fnid(fnid, missing_list)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in
> fail_fnid
> self.remove_runtarget(target, missing_list)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in
> remove_runtarget
> self.fail_fnid(fnid, missing_list)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in
> fail_fnid
> self.remove_runtarget(target, missing_list)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in
> remove_runtarget
> self.fail_fnid(fnid, missing_list)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 471, in
> fail_fnid
> self.remove_buildtarget(target, missing_list)
> File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 501, in
> remove_buildtarget
> raise bb.providers.NoProvider(target)
> NoProvider: meta-toolchain
>
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] toolchain queries
On Fri, Jul 15, 2011 at 2:13 PM, Kumar Gala wrote: > > On Jul 15, 2011, at 2:28 PM, Khem Raj wrote: > >> On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala >> wrote: >>> Where is the best place to ask questions and try and get support for adding >>> some toolchain variations in? >>> >>> I'm wanting to add support in for a few different flavors of PPC that are >>> not currently supported: >>> >>> * e500v2 (gcc needs --enable-e500_double, eglibc >> >> this means ABI change especially due to double formats. This should be >> doable in machine.conf >> files or tune files. > > how so? What can I set in there that would actually get passed into gcc's > configure (not really seeing anything). Also what exactly do you mean by a > machine.conf Well as I see not so easily which is since we share toolchain for architectures and if we let machines add ABI conflicting options then we will be in trouble think of using I could have suggested using something like GLIBC_EXTRA_OECONF but I would not encourage that So one way to go about this is that we use -gnuspe in target triplet which will differentiate SPE targets from classic ppc and then in gcc recipe include files you can do something like EXTRA_OECONF_append_linux-gnuspe = " --enable-e500_double " > >>> * e5500 (64-bit embedded ppc) >> >> this is new I guess. Its like adding a new arch to OE. See around >> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html >> is roughly what can be helpful in getting ppc64 going > > Thanks, will take a look at that. > > - k ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_OS issues with linux-gnuspe
On Jul 15, 2011, at 4:29 PM, Khem Raj wrote:
> On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala wrote:
>> In my attempts to get an e500v2/gnuspe toolchain working I was able to get
>> core-image-minimal working. However when I try the 'meta-toolchain' I run
>> into the following below. I believe this is because of TARGET_OS being
>> 'linux-gnuspe'.
>>
>> Any ideas ?
>>
>> - k
>>
>> [kumar@right build-p2020]$ bitbake meta-toolchain
>>
>> OE Build Configuration:
>> BB_VERSION= "1.13.2"
>> TARGET_ARCH = "powerpc"
>> TARGET_OS = "linux-gnuspe"
>> MACHINE = "p2020-ds"
>> DISTRO= "poky"
>> DISTRO_VERSION= "1.0+snapshot-20110715"
>> TARGET_FPU= "spe"
>> meta
>> meta-yocto= "master:068839698fe192d8846c0ed4db65861448e8e524"
>>
>> NOTE: Resolving any missing task queue dependencies
>> ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'
>
> here is the problem. This should have been called
> virtual/powerpc-poky-linux-gnuspe-libc-for-gcc
>
> so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
> not being set correctly
>
> and
>
> TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
> bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
> 1) == ('' or 'custom')]}"
>
> so it should be ok if TARGET_OS is set
>
> can you pastebin output of
>
> bitbake -e meta-toolchain
>
> somewhere
Are you sure that is what you want? It looks the same
http://pastebin.com/FuNFCxLQ
- k
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_OS issues with linux-gnuspe
On Fri, Jul 15, 2011 at 2:57 PM, Kumar Gala wrote:
>
> On Jul 15, 2011, at 4:29 PM, Khem Raj wrote:
>
>> On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala
>> wrote:
>>> In my attempts to get an e500v2/gnuspe toolchain working I was able to get
>>> core-image-minimal working. However when I try the 'meta-toolchain' I run
>>> into the following below. I believe this is because of TARGET_OS being
>>> 'linux-gnuspe'.
>>>
>>> Any ideas ?
>>>
>>> - k
>>>
>>> [kumar@right build-p2020]$ bitbake meta-toolchain
>>>
>>> OE Build Configuration:
>>> BB_VERSION = "1.13.2"
>>> TARGET_ARCH = "powerpc"
>>> TARGET_OS = "linux-gnuspe"
>>> MACHINE = "p2020-ds"
>>> DISTRO = "poky"
>>> DISTRO_VERSION = "1.0+snapshot-20110715"
>>> TARGET_FPU = "spe"
>>> meta
>>> meta-yocto = "master:068839698fe192d8846c0ed4db65861448e8e524"
>>>
>>> NOTE: Resolving any missing task queue dependencies
>>> ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'
>>
>> here is the problem. This should have been called
>> virtual/powerpc-poky-linux-gnuspe-libc-for-gcc
>>
>> so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
>> not being set correctly
>>
>> and
>>
>> TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
>> bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
>> 1) == ('' or 'custom')]}"
>>
>> so it should be ok if TARGET_OS is set
>>
>> can you pastebin output of
>>
>> bitbake -e meta-toolchain
>>
>> somewhere
>
> Are you sure that is what you want? It looks the same
>
> http://pastebin.com/FuNFCxLQ
heh thats not enought info in there. But again the problem seems to be
that TARGET_OS is not being set to linux-gnuspe and
virtual/${TARGET_PREFIX}libc-for-gcc
is being expanded to use default value which is 'powerpc-poky-linux-'
in your case
how/where are you setting TARGET_OS
>
> - k
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_OS issues with linux-gnuspe
On Jul 15, 2011, at 5:04 PM, Khem Raj wrote:
> On Fri, Jul 15, 2011 at 2:57 PM, Kumar Gala wrote:
>>
>> On Jul 15, 2011, at 4:29 PM, Khem Raj wrote:
>>
>>> On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala
>>> wrote:
>>>> In my attempts to get an e500v2/gnuspe toolchain working I was able to get
>>>> core-image-minimal working. However when I try the 'meta-toolchain' I run
>>>> into the following below. I believe this is because of TARGET_OS being
>>>> 'linux-gnuspe'.
>>>>
>>>> Any ideas ?
>>>>
>>>> - k
>>>>
>>>> [kumar@right build-p2020]$ bitbake meta-toolchain
>>>>
>>>> OE Build Configuration:
>>>> BB_VERSION= "1.13.2"
>>>> TARGET_ARCH = "powerpc"
>>>> TARGET_OS = "linux-gnuspe"
>>>> MACHINE = "p2020-ds"
>>>> DISTRO= "poky"
>>>> DISTRO_VERSION= "1.0+snapshot-20110715"
>>>> TARGET_FPU= "spe"
>>>> meta
>>>> meta-yocto= "master:068839698fe192d8846c0ed4db65861448e8e524"
>>>>
>>>> NOTE: Resolving any missing task queue dependencies
>>>> ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'
>>>
>>> here is the problem. This should have been called
>>> virtual/powerpc-poky-linux-gnuspe-libc-for-gcc
>>>
>>> so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
>>> not being set correctly
>>>
>>> and
>>>
>>> TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
>>> bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
>>> 1) == ('' or 'custom')]}"
>>>
>>> so it should be ok if TARGET_OS is set
>>>
>>> can you pastebin output of
>>>
>>> bitbake -e meta-toolchain
>>>
>>> somewhere
>>
>> Are you sure that is what you want? It looks the same
>>
>> http://pastebin.com/FuNFCxLQ
>
> heh thats not enought info in there. But again the problem seems to be
> that TARGET_OS is not being set to linux-gnuspe and
> virtual/${TARGET_PREFIX}libc-for-gcc
>
> is being expanded to use default value which is 'powerpc-poky-linux-'
> in your case
>
> how/where are you setting TARGET_OS
Guessing:
meta/conf/distro/include/tclibc-eglibc.inc:TARGET_OS_powerpc =
"linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500',
'ppce500v2']]}"
- k
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] DOCS: Fix typo in command, "-" should be "="
"--host-armv5te..." should be "--host=armv5te..." Signed-off-by: Robert P. J. Day --- there's a fair amount in the ADT manual (and others) that can be cleaned in terms of proper docbook semantic markup and entity usage, but this looks like a fairly obvious error that should be fixed now. diff --git a/documentation/adt-manual/adt-command.xml b/documentation/adt-manual/adt-command.xml index 28501b6..83c61d8 100644 --- a/documentation/adt-manual/adt-command.xml +++ b/documentation/adt-manual/adt-command.xml @@ -37,7 +37,7 @@ environment-setup-armv5te-poky-linux-gnueabi. Thus, the following command works: - $ configure ‐‐host-armv5te-poky-linux-gnueabi ‐‐with-libtool-sysroot=+ $ configure ‐‐host=armv5te-poky-linux-gnueabi ‐‐with-libtool-sysroot= -- 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] [PATCH] DOCS: Correct format of command continuation.
Fixed. Thanks Robert. -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Friday, July 15, 2011 5:21 AM To: Yocto discussion list Subject: [yocto] [PATCH] DOCS: Correct format of command continuation. Signed-off-by: Robert P. J. Day --- i *think* this is what the author had in mind. diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 52f7391..d2e85ba 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -213,9 +213,9 @@ - $ sudo zypper install python gcc gcc-c++ libtool - $ subversion git chrpath automake - $ help2man diffstat texinfo mercurial wget + $ sudo zypper install python gcc gcc-c++ libtool \ + subversion git chrpath automake \ + help2man diffstat texinfo mercurial wget -- 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] last observations about quick start guide, then moving on
Robert, These are handled. Thanks again. ScottR -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Friday, July 15, 2011 10:10 AM To: Yocto discussion list Subject: [yocto] last observations about quick start guide, then moving on 1) "This optional GNOME mobile-based UI, which is intended for devices with resolution but restricted size screens ..." pretty sure there's a word missing before "resolution," no? 2) "OpenSUSE" vs "OpenSuse" ... actually, both of those are wrong, it should be "openSUSE". :-P 3) near bottom, sample command: poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin \ yocto-image-sdk-qemux86-1.0.rootfs.ext3 neither that kernel image nor rootfs are in downloads, should pick args that exist if that matters i'll let scott do with that what he will, and move on to manhandle the poky handbook. :-) 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto build fails
On Fri, 2011-07-15 at 11:44 +0100, Gray, Mark D wrote: > I have been trying to build on Ubuntu 11.0.4. I think I have followed > the online documentation correctly. I have also followed the wiki > page, which is required for me, to set up the proxy servers. However, > the build is still failing for me. This is for Bernard-5.0.1. I get > the following message > | NOTE: fetch > http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz > > | Cloning into bare > repository > /home/green/mdgray/yocto/poky-5.0.1-build/downloads/git2/git.pokylinux.org.linux-yocto-2.6.37... > > | nc: read failed (0/3): Broken pipe This would lead me to make a guess at your proxy settings not being configured correctly for git with nc. > On closer inspection, the file > http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz > is unavailable in the repo. I did a search and I could only find > http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz.bad > Looks like we have a bad mirrored tarball. :-/ Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto build fails
On Fri, Jul 15, 2011 at 5:10 PM, Joshua Lock wrote: > On Fri, 2011-07-15 at 11:44 +0100, Gray, Mark D wrote: > This would lead me to make a guess at your proxy settings not being > configured correctly for git with nc. > > >> On closer inspection, the file >> http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz >> is unavailable in the repo. I did a search and I could only find >> http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz.bad >> > > Looks like we have a bad mirrored tarball. :-/ I had blown the tarball away yesterday working on bug #1207. The rsync should have run by now to pull it back up but for some reason, hasn't. I'll look at this on Monday but in the meantime, i've forced the rsync. -b ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
