Date   

Re: Problem in running poky-qemu

Scott Garman <scott.a.garman@...>
 

On 11/10/2010 06:08 PM, sachin kumar wrote:
Dear All:

I am new to qemu, so please excuse me, i am asking basic question.

Actually i want to run linux image for ppc on qemu.

My host machine is running Fedora13.

For that i have downloaded following from yocto project website.

Disk Image: yocto-image-minimal-qemuppc-0.9.rootfs.ext3
Kernel Image : zImage-2.6.34-qemuppc-0.9.bin
Toolchain: yocto-eglibc-i586-i586-toolchain-sdk-0.9.tar.bz2

Now toolchain was installed properly.

Now when i am running poky-qemu from command line it is giving following
message
=============================================================================================
[root@sachinlinux yocto_tools]# poky-qemu zImage-2.6.34-qemuppc-0.9.bin
yocto-image-minimal-qemuppc-0.9.rootfs.ext3
Set MACHINE to [qemuppc-0] based on kernel [zImage-2.6.34-qemuppc-0.9.bin]
In order for this script to dynamically infer paths
to kernels or filesystem images, you either need
bitbake in your PATH or to source poky-init-build-env
before running this script

=============================================================================================
I am blank about this message, which script they are referring.
Hi Sachin,

When you installed the toolchain tarball (yocto-eglibc-i586-i586-toolchain-sdk-0.9.tar.bz2), it should have created a script /opt/poky/environment-setup-<arch>. That's the one you want to source.

The other issue is that we changed the naming conventions of the kernel and qemu images at the last minute, and the poky-qemu script needs some additional help to figure out which machine architecture you're using and the format of the image. So you need to add "qemuppc" and "ext3" to the list of options to poky-qemu.

$ source /opt/poky/environment-setup-ppc603e-poky-linux
$ poky-qemu qemuppc zImage-2.6.34-qemuppc-0.9.bin yocto-image-minimal-qemuppc-0.9.rootfs.ext3 ext3

should get you going.

This needs to get fixed ASAP and I'm going to submit a patch for it tomorrow in master. Thanks for your patience.

Scott


Re: Problem in running poky-qemu

Zhang, Jessica
 

Hi Sachin,
 
First of all, if you want to run ppc, the toolchain you need to download is yocto-eglibc-i586-powerpc-toolchain-sdk-0.9.tar.bz2.  After you install it under /opt/poky, you should go under /opt/poky and source the environment-setup-ppc* and try start qemu again...
 
Let us know if you still run into issues.
 
Thanks,
Jessica



From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of sachin kumar
Sent: Wednesday, November 10, 2010 6:09 PM
To: yocto@...
Subject: [yocto] Problem in running poky-qemu

Dear All:

I am new to qemu, so please excuse me, i am asking basic question.

Actually i want to run linux image for ppc on qemu.

My host machine is running Fedora13.

For that i have downloaded following from yocto project website.

Disk Image: yocto-image-minimal-qemuppc-0.9.rootfs.ext3
Kernel Image : zImage-2.6.34-qemuppc-0.9.bin
Toolchain: yocto-eglibc-i586-i586-toolchain-sdk-0.9.tar.bz2

Now toolchain was installed properly.

Now when i am running poky-qemu from command line it is giving following message
=============================================================================================
[root@sachinlinux yocto_tools]# poky-qemu zImage-2.6.34-qemuppc-0.9.bin yocto-image-minimal-qemuppc-0.9.rootfs.ext3
Set MACHINE to [qemuppc-0] based on kernel [zImage-2.6.34-qemuppc-0.9.bin]
In order for this script to dynamically infer paths
to kernels or filesystem images, you either need
bitbake in your PATH or to source poky-init-build-env
before running this script

=============================================================================================
I am blank about this message, which script they are referring.
Please help me for the same.
This will be a great help for me as i am at critical phase of one of my project.

Kind Regards
Sachin





Problem in running poky-qemu

sachin
 

Dear All:

I am new to qemu, so please excuse me, i am asking basic question.

Actually i want to run linux image for ppc on qemu.

My host machine is running Fedora13.

For that i have downloaded following from yocto project website.

Disk Image: yocto-image-minimal-qemuppc-0.9.rootfs.ext3
Kernel Image : zImage-2.6.34-qemuppc-0.9.bin
Toolchain: yocto-eglibc-i586-i586-toolchain-sdk-0.9.tar.bz2

Now toolchain was installed properly.

Now when i am running poky-qemu from command line it is giving following message
=============================================================================================
[root@sachinlinux yocto_tools]# poky-qemu zImage-2.6.34-qemuppc-0.9.bin yocto-image-minimal-qemuppc-0.9.rootfs.ext3
Set MACHINE to [qemuppc-0] based on kernel [zImage-2.6.34-qemuppc-0.9.bin]
In order for this script to dynamically infer paths
to kernels or filesystem images, you either need
bitbake in your PATH or to source poky-init-build-env
before running this script

=============================================================================================
I am blank about this message, which script they are referring.
Please help me for the same.
This will be a great help for me as i am at critical phase of one of my project.

Kind Regards
Sachin





Re: [poky][PULL] misc (minor) kernel fixes

Saul Wold <saul.wold@...>
 

On 11/08/2010 01:06 PM, Bruce Ashfield wrote:
In preparation for some larger kernel changes being sent
for review, I'm clearing my queue of a few minor changes
that were done while working on the 0.9 release.

The uImage one is particularly interesting, since it was
a fix for the default beagle board uImage being completely
unbootable.

The force revisions is largely cosmetic, but it is used
by my upcoming kernel dev layer and I think it is more in
the spirit of other variables that are set from local
configurations.

The following changes since commit e417aa98e4b4170f4b4aaf805cc8ea20f8593604:
Bruce Ashfield (1):
wrs_meta: add USB options for wacom tablet support

are available in the git repository at:

ssh://git@git.pokylinux.org/poky-contrib zedd/kernel-fixes

Bruce Ashfield (2):
linux-wrs: rename force_revisions and allow override
kernel: prefer the kernel produced uImage

meta/classes/kernel.bbclass | 4 +++-
meta/recipes-kernel/linux/linux-wrs_git.bb | 6 +++---
2 files changed, 6 insertions(+), 4 deletions(-)

Merged into Master

Thanks
Sau!


Re: problem with fetching?

Scott Garman <scott.a.garman@...>
 

On 11/10/2010 05:31 AM, Kumar Gala wrote:

On Nov 10, 2010, at 7:29 AM, Richard Purdie wrote:

On Wed, 2010-11-10 at 06:32 -0600, Kumar Gala wrote:
ERROR: Task failed: Fetch failed: Unable to fetch URL cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20080123 from any source.
NOTE: package gnu-config-native-0.1+cvs20080123-r1: task do_fetch: Failed
ERROR: Task 211 (virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb, do_fetch) failed with 1
ERROR: 'virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb' failed

Attached is the full log.
Are you behind some kind of proxy/firewall? Its interesting its a cvs
based recipe that is failing so it could be your cvs setup.
Yes, behind a proxy/firewall. cvs is not normally allowed out.
If you're behind a SOCKS proxy, these instructions might be helpful to get CVS checkouts working:

https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


Re: two layers: hardware and distro.

João Henrique Ferreira de Freitas
 

Hi,

I can tell about what applications we will use and contribute with
some questions.

We are focus on Telecom applications and I am setting a BSP to a Media
Gateway and Sigtran Gateway.

Thanks.


--
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br


Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

Bruce Ashfield <bruce.ashfield@...>
 

On 10-11-10 10:03 AM, Kumar Gala wrote:

On Nov 10, 2010, at 8:23 AM, Bruce Ashfield wrote:

On 10-11-10 09:11 AM, Kumar Gala wrote:

On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:

On 10-11-10 08:38 AM, Bruce Ashfield wrote:
On 10-11-10 01:46 AM, Kumar Gala wrote:
Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
SPE. This isn't correct for an MPC8313 SoC.
It isn't used at the moment, so we can safely
ignore this.

It was a hold over from when I initially created
the BSP, and I've since changed it locally, but
haven't sent the updated BSP yet.
To clarify on this point, the kernel configuration
is NOT using SPE for this, and I was attempting to
use the FPU setting to trigger some different gcc
flags during development the base of that test was
an e500 board, so the SPE setting leaked in, but is
unused.

At the moment, it is actually using soft-float, and
I had planned to submit a change to clarify that.

If there's another option, let me know and I'll
rebase my patches and change it again.
We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).
Indeed. I fell back to a safe multilib. I'm willing
to try again and see if the gcc bootstrap phases will
build.

The kernel was fine, and is fine, it was userspace
that caused problems for me .. and that's definitely not
an area where my expertise lies :)

I needed something that worked, and had to excplicitly
chose to ignore the FPU temporarily, but revisiting that
now seems like a good idea.


Any plans to get an e500 based system going before the rev1.0 release?
We've got tonnes of experience and BSPs to draw from
here. The selection of some of these BSPs was (largely)
based on cost and availability. If we can get our
hands on a suitable e500 replacement .. the switch is
trivial.
If we can get a toolchain and basic build I'm happy to help on the HW side and getting kernel, etc worked out.
Agreed. For me, this is the slightly harder part. I'll
start a few builds and see if the errors are still here.


I'd like to get a semi-generic setup going for an e500v2 based system.
Should be doable. I've already got a generic set of configs/
patches/features in place for all powerpc/FSL boards,
(largely due to the lineage of the base kernel we use).
But getting some assistance with further tuning of the
options would be appreciated, since I can use that to springboard
the creation of new BSPs.

Cheers,

Bruce




- k


Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

Kumar Gala <galak@...>
 

On Nov 10, 2010, at 8:23 AM, Bruce Ashfield wrote:

On 10-11-10 09:11 AM, Kumar Gala wrote:

On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:

On 10-11-10 08:38 AM, Bruce Ashfield wrote:
On 10-11-10 01:46 AM, Kumar Gala wrote:
Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
SPE. This isn't correct for an MPC8313 SoC.
It isn't used at the moment, so we can safely
ignore this.

It was a hold over from when I initially created
the BSP, and I've since changed it locally, but
haven't sent the updated BSP yet.
To clarify on this point, the kernel configuration
is NOT using SPE for this, and I was attempting to
use the FPU setting to trigger some different gcc
flags during development the base of that test was
an e500 board, so the SPE setting leaked in, but is
unused.

At the moment, it is actually using soft-float, and
I had planned to submit a change to clarify that.

If there's another option, let me know and I'll
rebase my patches and change it again.
We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).
Indeed. I fell back to a safe multilib. I'm willing
to try again and see if the gcc bootstrap phases will
build.

The kernel was fine, and is fine, it was userspace
that caused problems for me .. and that's definitely not
an area where my expertise lies :)

I needed something that worked, and had to excplicitly
chose to ignore the FPU temporarily, but revisiting that
now seems like a good idea.


Any plans to get an e500 based system going before the rev1.0 release?
We've got tonnes of experience and BSPs to draw from
here. The selection of some of these BSPs was (largely)
based on cost and availability. If we can get our
hands on a suitable e500 replacement .. the switch is
trivial.
If we can get a toolchain and basic build I'm happy to help on the HW side and getting kernel, etc worked out.

I'd like to get a semi-generic setup going for an e500v2 based system.

- k


Re: Bug Fixer and Verifier

You, Yongkang <yongkang.you@...>
 

Ke,

I think that's okay. But if reporter can ask somebody (who is in bug's cc list) to help verify, that will be greater. And it needs to provide master tree's commit info, when mark the bug to "fixed" stage.

BTW, we also defined the bug should not be marked to "fixed", until it has been included in master tree and built into any formal build. Well, this process is not easy to be manually followed. I noticed Bugzilla 4.0 would be released soon. I am hoping we will have automation bug status changing soon (with required bug fixing info added to patch).

Thanks,
Yongkang

On Wednesday, November 10, 2010 9:19 PM, Yu, Ke wrote:
Hi KangKang,

One case of the bug process need your input. In bug #467, Josh
are both reporter and the one who fix this bug. When he fixed
the bug, as a reporter, he also verify the bug according to the
process
(https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_
Bug_Tracking) . I just wonder if it is appropriate that bug fixer and
verifier be the same people?

Regards
Ke


Re: problem with fetching?

Richard Purdie <rpurdie@...>
 

On Wed, 2010-11-10 at 08:22 -0600, Kumar Gala wrote:
On Nov 10, 2010, at 7:50 AM, Richard Purdie wrote:

On Wed, 2010-11-10 at 07:31 -0600, Kumar Gala wrote:
On Nov 10, 2010, at 7:29 AM, Richard Purdie wrote:

On Wed, 2010-11-10 at 06:32 -0600, Kumar Gala wrote:
ERROR: Task failed: Fetch failed: Unable to fetch URL cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20080123 from any source.
NOTE: package gnu-config-native-0.1+cvs20080123-r1: task do_fetch: Failed
ERROR: Task 211 (virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb, do_fetch) failed with 1
ERROR: 'virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb' failed

Attached is the full log.
Are you behind some kind of proxy/firewall? Its interesting its a cvs
based recipe that is failing so it could be your cvs setup.
Yes, behind a proxy/firewall. cvs is not normally allowed out.

You could try placing
http://autobuilder.pokylinux.org/sources/config_cvs.sv.gnu.org__20080123.tar.gz

into the downloads directory manually and touching the
config_cvs.sv.gnu.org__20080123.tar.gz.md5 file there to show the
fetcher the fetch is complete. If that works it would suggest the mirror
fallback code in the fetcher isn't working as intended.
I'm new to this, where would my download dir be?
It defaults to "build/downloads" so in the build directory unless you
changed it in local.conf.
Looks like that makes things work, so appears as if fallback code in the fetcher is having issues.

See the issue again with another pkg:

NOTE: Fetch cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs;module=apps/update-rc.d;tag=r0_7
ERROR: Task failed: Fetch failed: Unable to fetch URL cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs;module=apps/update-rc.d;tag=r0_7 from any source.
ERROR: Task 1217 (virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb, do_fetch) failed with 1
ERROR: 'virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb' failed
I don't have any fix for the fetcher ready straight away but this sounds
like a testcase we can reproduce. We actually have some plans to do a
redesign of the fetcher code to address issues like this amongst other
reasons.

I did have a quick look at my downloads directory and saw these files:

apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
yaffs2_cvs.aleph1.co.uk__20071107.tar.gz
config_cvs.sv.gnu.org__20080123.tar.gz

which I think are the only cvs checkouts we use. You don't need the
yaffs2 one so if you download the other, your build should proceed.

Cheers,

Richard


Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

Bruce Ashfield <bruce.ashfield@...>
 

On 10-11-10 09:11 AM, Kumar Gala wrote:

On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:

On 10-11-10 08:38 AM, Bruce Ashfield wrote:
On 10-11-10 01:46 AM, Kumar Gala wrote:
Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
SPE. This isn't correct for an MPC8313 SoC.
It isn't used at the moment, so we can safely
ignore this.

It was a hold over from when I initially created
the BSP, and I've since changed it locally, but
haven't sent the updated BSP yet.
To clarify on this point, the kernel configuration
is NOT using SPE for this, and I was attempting to
use the FPU setting to trigger some different gcc
flags during development the base of that test was
an e500 board, so the SPE setting leaked in, but is
unused.

At the moment, it is actually using soft-float, and
I had planned to submit a change to clarify that.

If there's another option, let me know and I'll
rebase my patches and change it again.
We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).
Indeed. I fell back to a safe multilib. I'm willing
to try again and see if the gcc bootstrap phases will
build.

The kernel was fine, and is fine, it was userspace
that caused problems for me .. and that's definitely not
an area where my expertise lies :)

I needed something that worked, and had to excplicitly
chose to ignore the FPU temporarily, but revisiting that
now seems like a good idea.


Any plans to get an e500 based system going before the rev1.0 release?
We've got tonnes of experience and BSPs to draw from
here. The selection of some of these BSPs was (largely)
based on cost and availability. If we can get our
hands on a suitable e500 replacement .. the switch is
trivial.

Cheers,

Bruce


- k


Re: problem with fetching?

Kumar Gala <galak@...>
 

On Nov 10, 2010, at 7:50 AM, Richard Purdie wrote:

On Wed, 2010-11-10 at 07:31 -0600, Kumar Gala wrote:
On Nov 10, 2010, at 7:29 AM, Richard Purdie wrote:

On Wed, 2010-11-10 at 06:32 -0600, Kumar Gala wrote:
ERROR: Task failed: Fetch failed: Unable to fetch URL cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20080123 from any source.
NOTE: package gnu-config-native-0.1+cvs20080123-r1: task do_fetch: Failed
ERROR: Task 211 (virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb, do_fetch) failed with 1
ERROR: 'virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb' failed

Attached is the full log.
Are you behind some kind of proxy/firewall? Its interesting its a cvs
based recipe that is failing so it could be your cvs setup.
Yes, behind a proxy/firewall. cvs is not normally allowed out.

You could try placing
http://autobuilder.pokylinux.org/sources/config_cvs.sv.gnu.org__20080123.tar.gz

into the downloads directory manually and touching the
config_cvs.sv.gnu.org__20080123.tar.gz.md5 file there to show the
fetcher the fetch is complete. If that works it would suggest the mirror
fallback code in the fetcher isn't working as intended.
I'm new to this, where would my download dir be?
It defaults to "build/downloads" so in the build directory unless you
changed it in local.conf.
Looks like that makes things work, so appears as if fallback code in the fetcher is having issues.

See the issue again with another pkg:

NOTE: Fetch cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs;module=apps/update-rc.d;tag=r0_7
ERROR: Task failed: Fetch failed: Unable to fetch URL cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs;module=apps/update-rc.d;tag=r0_7 from any source.
ERROR: Task 1217 (virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb, do_fetch) failed with 1
ERROR: 'virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb' failed

- k


Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

Kumar Gala <galak@...>
 

On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:

On 10-11-10 08:38 AM, Bruce Ashfield wrote:
On 10-11-10 01:46 AM, Kumar Gala wrote:
Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
SPE. This isn't correct for an MPC8313 SoC.
It isn't used at the moment, so we can safely
ignore this.

It was a hold over from when I initially created
the BSP, and I've since changed it locally, but
haven't sent the updated BSP yet.
To clarify on this point, the kernel configuration
is NOT using SPE for this, and I was attempting to
use the FPU setting to trigger some different gcc
flags during development the base of that test was
an e500 board, so the SPE setting leaked in, but is
unused.

At the moment, it is actually using soft-float, and
I had planned to submit a change to clarify that.

If there's another option, let me know and I'll
rebase my patches and change it again.
We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).

Any plans to get an e500 based system going before the rev1.0 release?

- k


Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

Bruce Ashfield <bruce.ashfield@...>
 

On 10-11-10 08:38 AM, Bruce Ashfield wrote:
On 10-11-10 01:46 AM, Kumar Gala wrote:
Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
SPE. This isn't correct for an MPC8313 SoC.
It isn't used at the moment, so we can safely
ignore this.

It was a hold over from when I initially created
the BSP, and I've since changed it locally, but
haven't sent the updated BSP yet.
To clarify on this point, the kernel configuration
is NOT using SPE for this, and I was attempting to
use the FPU setting to trigger some different gcc
flags during development the base of that test was
an e500 board, so the SPE setting leaked in, but is
unused.

At the moment, it is actually using soft-float, and
I had planned to submit a change to clarify that.

If there's another option, let me know and I'll
rebase my patches and change it again.

Cheers,

Bruce


Cheers,

Bruce


- k
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Distro 1.0 Planning minutes

Richard Purdie <rpurdie@...>
 

On Wed, 2010-11-10 at 11:52 +0100, Esben Haabendal wrote:
Richard Purdie <rpurdie@linux.intel.com> writes:

On Wed, 2010-11-10 at 10:50 +0100, Esben Haabendal wrote:
"Kamble, Nitin A" <nitin.a.kamble@intel.com> writes:

Dongxiao: sysroot per machine per recipe
Is it possible to elaborate on this topic? What was discussed and what
was the conclusion?
This is what we discussed in person in Cambridge, the idea of making it
possible to have one sysroot per machine or one sysroot per recipe. Our
intention is to make this work in the next few months.

I pointed you at the existing task based sstate code which should make
this kind of thing relatively straight forward.
This definitely sounds interesting.

Will it be possible to have recipe A (build) depend on B, which (build)
depends on C, without having C in the per recipe stage of A?
Yes, that is the plan. I'm hoping this allows us to rigorously check
package dependencies and whilst we might not default to it all the time,
it would allow us to test this periodically.

Will it be possible to have recipe A (build) depend on selected files
from B, f.x. only a subset of libraries built by a recipe?
This currently isn't planned.

Cheers,

Richard


Re: problem with fetching?

Richard Purdie <rpurdie@...>
 

On Wed, 2010-11-10 at 07:31 -0600, Kumar Gala wrote:
On Nov 10, 2010, at 7:29 AM, Richard Purdie wrote:

On Wed, 2010-11-10 at 06:32 -0600, Kumar Gala wrote:
ERROR: Task failed: Fetch failed: Unable to fetch URL cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20080123 from any source.
NOTE: package gnu-config-native-0.1+cvs20080123-r1: task do_fetch: Failed
ERROR: Task 211 (virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb, do_fetch) failed with 1
ERROR: 'virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb' failed

Attached is the full log.
Are you behind some kind of proxy/firewall? Its interesting its a cvs
based recipe that is failing so it could be your cvs setup.
Yes, behind a proxy/firewall. cvs is not normally allowed out.

You could try placing
http://autobuilder.pokylinux.org/sources/config_cvs.sv.gnu.org__20080123.tar.gz

into the downloads directory manually and touching the
config_cvs.sv.gnu.org__20080123.tar.gz.md5 file there to show the
fetcher the fetch is complete. If that works it would suggest the mirror
fallback code in the fetcher isn't working as intended.
I'm new to this, where would my download dir be?
It defaults to "build/downloads" so in the build directory unless you
changed it in local.conf.

Cheers,

Richard


Re: two layers: hardware and distro.

Bruce Ashfield <bruce.ashfield@...>
 

On 10-11-10 06:41 AM, João Henrique Freitas wrote:
Hi,

I am novice yocto user.

My target is create a BSP to my hardware+application. Is Yocto a
suitable project to do it?

I want to create two layers:

bsp-myhardware: linux kernel, firmware, specific hardware configuration
bsp-myapplication: linux distro with all software need. Ex: net-snmp,
lksctp (the target is telecom applications)

Currently yocto does not have many recipes that I need. No problem, I
can get from OE. We use kernel 2.6.22 and I presume that I need a
recipe to it and put inside bsp-myhardware, right?
Any interest in moving to a newer/different kernel ? The
supported kernel for yocto is at 2.6.34 and I'll have a
-dev tree tracking 2.6.37 shortly.

My interest is getting more BSPs using the same kernel
version so we can leverage the common set of issues,
bug fixes, CVEs, etc. It also helps me streamline the
BSP bootstrapping process, which is a primary focus of
mine at the moment.

Bruce



Thanks.


Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

Bruce Ashfield <bruce.ashfield@...>
 

On 10-11-10 01:46 AM, Kumar Gala wrote:
Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as SPE. This isn't correct for an MPC8313 SoC.
It isn't used at the moment, so we can safely
ignore this.

It was a hold over from when I initially created
the BSP, and I've since changed it locally, but
haven't sent the updated BSP yet.

Cheers,

Bruce


- k
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: two layers: hardware and distro.

Richard Purdie <rpurdie@...>
 

Hi,

On Wed, 2010-11-10 at 09:41 -0200, João Henrique Freitas wrote:
I am novice yocto user.

My target is create a BSP to my hardware+application. Is Yocto a
suitable project to do it?

I want to create two layers:

bsp-myhardware: linux kernel, firmware, specific hardware configuration
bsp-myapplication: linux distro with all software need. Ex: net-snmp,
lksctp (the target is telecom applications)

Currently yocto does not have many recipes that I need. No problem, I
can get from OE. We use kernel 2.6.22 and I presume that I need a
recipe to it and put inside bsp-myhardware, right?
Yes, this sounds like a very reasonable approach.

In general (this applies to anyone out there), we're interested to know
what kinds of software people use so please let us know what you're
putting into application layers anyone creates like this. Our focus is
currently on making sure there is a rock solid core for people to build
from but if there are core applications missing we'd like to know about
it.

Also, if anyone establishes a layer with a specific focus, we're happy
to provide a git repository for it on git.yoctoproject.org where you
could maintain and share this code with other people with a similar
goal.

Cheers,

Richard


Re: problem with fetching?

Kumar Gala <galak@...>
 

On Nov 10, 2010, at 7:29 AM, Richard Purdie wrote:

On Wed, 2010-11-10 at 06:32 -0600, Kumar Gala wrote:
ERROR: Task failed: Fetch failed: Unable to fetch URL cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20080123 from any source.
NOTE: package gnu-config-native-0.1+cvs20080123-r1: task do_fetch: Failed
ERROR: Task 211 (virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb, do_fetch) failed with 1
ERROR: 'virtual:native:/local/home/galak/poky-laverne-4.0/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb' failed

Attached is the full log.
Are you behind some kind of proxy/firewall? Its interesting its a cvs
based recipe that is failing so it could be your cvs setup.
Yes, behind a proxy/firewall. cvs is not normally allowed out.

You could try placing
http://autobuilder.pokylinux.org/sources/config_cvs.sv.gnu.org__20080123.tar.gz

into the downloads directory manually and touching the
config_cvs.sv.gnu.org__20080123.tar.gz.md5 file there to show the
fetcher the fetch is complete. If that works it would suggest the mirror
fallback code in the fetcher isn't working as intended.
I'm new to this, where would my download dir be?

- k