Date   

Re: New platforms

Tom Zanussi <tom.zanussi@...>
 

On Thu, 2010-11-18 at 02:36 -0800, Chris Tapp wrote:
Hi,

I've been evaluating OpenEmbedded and saw the announcement of 'Yocto'
on the mailing list. Yocto looks like it may be better for my needs as
it is more refined.

As there isn't currently support for the ALIX 3D3 (a Geode LX based
system), I am interested in creating and maintaining a BSP for it.
This should also work with other LX systems (e.g. SUMO ST166, other
ALIX variants), some with no changes, some with minor ones.

Could you give me an idea how much work would be involved in doing
this and what it involve?
I can give you a bit of an idea from a practical standpoint, since I've
also started working on a BSP for a new board just recently (i.e. I'm
actually still on the learning curve myself, hopefully anyone who knows
better will correct any of errors or misconceptions...)

As mentioned by Bruce, things have changed lately as far as
bootstrapping a board - it should be easier now, but something like the
below should work to get you started.

As also mentioned by Bruce, you need a machine.conf that describes your
machine - there are a bunch of examples to start from, in a couple of
places, a bunch in in meta/conf/machine and another example that's part
of its own layer, in meta-emenlow/conf/machine.

The most recently up-to-date machines that are probably more similar to
yours and that you might want to look at are
meta/conf/machine/atom-pc.conf and
meta-emenlow/conf/machine/emenlow.conf. Both of these were either just
added or upgraded to use the yocto kernel
(http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/). The main
difference between them is that the emenlow is in its own layer, because
it needs some extra machine-specific packages such as its own video
driver and supporting packages, etc. The atom-pc is simpler and doesn't
need any special packages - everything it needs can be specified in
the .conf file. Note also that this one machine (atom-pc) supports all
of Asus eee901, Acer Aspire One, Toshiba NB305, and Intel BlackSand with
no changes. If you wanted to make minor changes to support a slightly
different machine, you could create a new .conf for it and add it
alongside the others (maybe keeping the common stuff separate and
including it). Similarly, you can also use multiple .confs for
different machines even if you do it as a separate layer like
meta-emenlow.

So anyway, for my new layer, meta-crownbay, I basically made a copy of
meta-emenlow and fixed it up/removed anything I didn't need - in
meta-crownbay/recipes, the only thing left was the kernel dir with a
linux-yocto_git.bbappend file in it (linux-yocto is the kernel listed in
meta-crownbay/conf/machine/crownbay.conf). I added a new entry to
build/conf/bblayers.conf so the new layer can be found by bitbake.

So to get things working, the main thing to start out with is to get an
image with a working kernel built. For the kernel to compile
successfully, you need to create a branch in the git repo specifically
named for your machine. So first create a bare clone of the windriver
git repository, and then create a local clone of that:

$ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git linux-2.6-windriver.git
$ git clone linux-2.6-windriver.git linux-2.6-windriver

Now create a branch in the local clone and push it to the bare clone:

$ git checkout -b crownbay-standard origin/standard
$ git push origin crownbay-standard:crownbay-standard

At this point, your git tree should be set up well enough to compile,
now you just need to point the build at the new kernel git tree, by
commenting out the SRC_URI in
meta/recipes-kernel/linux/linux-yocto_git.bb and using a SRC_URI that
points to your new bare git tree (you should also be able to add this in
the do this in the linux-yocto_git.bbappend in the layer):

# To use a staged, on-disk bare clone of a Wind River Kernel, use a
# variant of the below
# SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1"
SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"

After doing that, and selecting the machine in build/conf/local.conf
e.g.

MACHINE ?= "crownbay"

you should be able to build and boot an image with the new kernel (e.g.
bitbake poky-image-sato-live).

Of course, that will give you a kernel with the default config, which is
probably not what you want. If you just want to set some kernel config
options, you can do that by putting them in a files, say some.cfg
containing:

CONFIG_NETDEV_1000=y
CONFIG_E1000E=y

and some other.cfg containing

CONFIG_LOG_BUF_SHIFT=18

http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/

SRC_URI_append_crownbay = " file://some.cfg \
file://other.cfg \
"

You could also add these directly to the git repo's wrs_meta branch as
well, but this is probably easier.

If you're also adding patches to the kernel, you can do the same thing,
and put your patches in the SRC_URI as well (plus .cfg for their kernel
config options if needed).

Practically speaking, to generate the patches, you'd go to the source in
the build tree, for example,

build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux

and modify the code there, using quilt to save the changes, and
recompile (bitbake -c compile -f) until it works. Once you have the
final patch from quilt, copy it to the SRC_URI location, and it should
be applied the next time you do a clean build. Of course, since you
have a branch for the BSP in git, it would be better to put it there
instead e.g. in my case, commit the patch to the crownbay-standard
branch, and next build it will be applied from there.

I know some of the above is the old way of doing things, and I'm sure
other could offer a more efficient development cycle, but that's what
I'm currently using and it works for me for now.

This is only some basic practical stuff to help get started - you really
want to look at the Poky Reference Manual for much more useful info on
actually what things in the recipes actually mean, etc.:

http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html

One section of that is a 'BSP guide' which is available separately here:

http://www.yoctoproject.org/sites/default/files/bsp-guide_2.pdf

We'd really like to expand that with whatever additional info might be
useful to BSP developers, so please let us know if you have suggestions.

Thanks,

Tom

Chris Tapp

opensource@keylevel.com
www.keylevel.com



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


Re: New platforms

Tian, Kevin <kevin.tian@...>
 

From: Bruce Ashfield
Sent: Tuesday, November 23, 2010 1:09 AM

On 10-11-18 05:36 AM, Chris Tapp wrote:
Hi,

I've been evaluating OpenEmbedded and saw the announcement of 'Yocto'
on the mailing list. Yocto looks like it may be better for my needs as
it is more refined.

As there isn't currently support for the ALIX 3D3 (a Geode LX based
system), I am interested in creating and maintaining a BSP for it.
This should also work with other LX systems (e.g. SUMO ST166, other
ALIX variants), some with no changes, some with minor ones.

Could you give me an idea how much work would be involved in doing
this and what it involve?
Kernel is the biggest part you'd work out which thanks to Bruce you should
have rich information below. Besides, you may also have some board specific
firmware, 3rd party components, xserver, etc.

Generally speaking, you need create a new layer which bundles all board
specific bits together which are then added on top of poky core layer.

You can read http://www.yoctoproject.org/sites/default/files/bsp-guide_4.pdf
which has a detail description how a new BSP is created.

You can also refer to existing layers such as meta-emenlow for reference.

On the other hand, if all the variances you care about is just in kernel side,
basically what Bruce describes is enough to create a new MACHINE. For
example, you may refer to routerstationpro:

commit 149f2262135ca87608783a8801c9c2d978d8c8ef
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date: Sun Oct 10 14:11:07 2010 -0400

routerstationpro: create machine conf and compatibility

BUGID: 422

Add the machine configuration and kernel infrastructure for building
the routerstation pro BSP.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

Hope above helps.

Thanks,
Kevin


I can answer from the kernel point of view.

The supported yocto kernel(s) (currently 2.6.34 and
shortly 2.6.37-rcX) are the place where I can assist
in getting you up and running with a new board/platform
fairly easily.

The kernel documentation is being updated (since I've
made changes recently to streamline just what you
are talking about here), but I can give some more
hands on help while those docs are still outstanding.

For the kernel, you'd need to create a machine.conf
with your optimization, features, etc, and give the
machine a name. There are obviously plenty of examples
on how to do this in the tree.

At that point, you can bootstrap the the BSP process
by doing a: bitbake -c configure linux-yocto.

You then have the kernel git repository staged and
branch for kernel changes to be added. Working with
the kernel in git is key, since you can have a
common branch, and have board specific branches for
configuration or features that are not generally
applicable to all boards.

You can iteratively configure and build the board
from this point.

When you are happy with the changes you can export
the patches, or keep the branches in a local git
tree (better), and if there is assistance in maintaining
the BSP(s) we can contribute them to the maintained
kernel repository (best). This then enables collaboration
and best practices development.

The amount of work depends on the type of kernel
patches you need to add for the board(s) and the
desired feature mix. Userspace difficulty should
be manageable if the known working ARM baseline
builds are used as starting point.

I've gone light on the details here, but if there is
interest, I can provide more information.

And again, this is speaking from the kernel point of
view only.

Cheers,

Bruce


Chris Tapp

opensource@keylevel.com
www.keylevel.com



_______________________________________________
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: When is it ok to link to host libraries?

David Stewart
 

From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Scott Garman
Sent: Monday, November 22, 2010 11:02 AM

Hello,

I'd like to get some better clarity about what constitutes host
contamination when it comes to building packages. Could someone with
deeper knowledge of these issues clarify or comment on the following?

My understanding is that when building non -native recipes, there
should
be absolutely no linking to the libraries on the host system - meaning
that autotols configure scripts and so on should not be determining
which features are available based on what packages are installed on
the
host OS. The only exceptions to this are the use of some core system
utilities (cp, mv, etc).

However, when it comes to -native recipes, is it acceptable to link to
the host libraries? Since the package is intended to run on the same
host, I would think this would be acceptable, but I'm not certain.

The problem I'm working on which prompted this inquiry is a segfault
that is occurring with QEMU in certain circumstances. The latest Ubuntu
(10.10, Maverick) with the proprietary NVIDIA Xorg driver also installs
its own version of libGL, which is linked by qemu-native. If I
uninstall
the proprietary NVIDIA driver and rebuild qemu-native from scratch, the
segfault does not occur.
Would you ever have a situation where you build the SDK on one distro version but install and use it on another one? If so, does this affect your decisions?

Thanks,

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: When is it ok to link to host libraries?

Mark Hatle <mark.hatle@...>
 

On 11/22/10 1:01 PM, Scott Garman wrote:
Hello,

I'd like to get some better clarity about what constitutes host
contamination when it comes to building packages. Could someone with
deeper knowledge of these issues clarify or comment on the following?

My understanding is that when building non -native recipes, there should
be absolutely no linking to the libraries on the host system - meaning
that autotols configure scripts and so on should not be determining
which features are available based on what packages are installed on the
host OS. The only exceptions to this are the use of some core system
utilities (cp, mv, etc).
In general this is true.... however there are cases where a helper application
needs to be built, i.e. to generate a structure list... to compile some
specialized code, etc.. This can use the host system's compiler and libraries..
but needs to be closely monitored to make sure it won't introduce other
host-system contamination. (Usually BUILD_CC or HOST_CC is used instead of the
regular CC).

However, when it comes to -native recipes, is it acceptable to link to
the host libraries? Since the package is intended to run on the same
host, I would think this would be acceptable, but I'm not certain.
Depends, if the item being linked to is part of the Poky -native recipes it
should be just fine.

If it's part of the host system itself, we need to decide if it's a "common
enough", or a Poky host system requirement. If so, then we can generally link
to it.. if it doesn't fall into either of those categories, then we need to
evaluate if the item should have a -native added for it, should it be added to
the poky requirements, or is it "an exception" for some other reason.

The problem I'm working on which prompted this inquiry is a segfault
that is occurring with QEMU in certain circumstances. The latest Ubuntu
(10.10, Maverick) with the proprietary NVIDIA Xorg driver also installs
its own version of libGL, which is linked by qemu-native. If I uninstall
the proprietary NVIDIA driver and rebuild qemu-native from scratch, the
segfault does not occur.
Thats not surprising. Generally applications will link to the mesa libGL/libGLU
drivers. Then an optimized version will replace it and assume it's API and
functionality. My guess is there is a difference in the way the item is linked
-- or the symbols are resolved between the NVIDIA and the non-NVIDIA version.
(likely a compatibility defect in the proprietary version...) Something like
weak or aliased symbol resolution might be the cause...

Either way, I'd recommend we document these, and if it's truly a host system
issue we add a list of know problems.

(In this particular case, I'd consider the mesa GL interface to be a "required
host component", if we have graphics enabled in QEMU. Since the host's version
is broken.. a documented way to identify the failure and how to work around it
is likely a very good idea... perhaps even adding something to the Poky host
checking classes might be reasonable in this case -- or alternatively to the
QEMU-native build.. have it verify it won't be building a broken version.)

--Mark

Thanks,

Scott


When is it ok to link to host libraries?

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

Hello,

I'd like to get some better clarity about what constitutes host contamination when it comes to building packages. Could someone with deeper knowledge of these issues clarify or comment on the following?

My understanding is that when building non -native recipes, there should be absolutely no linking to the libraries on the host system - meaning that autotols configure scripts and so on should not be determining which features are available based on what packages are installed on the host OS. The only exceptions to this are the use of some core system utilities (cp, mv, etc).

However, when it comes to -native recipes, is it acceptable to link to the host libraries? Since the package is intended to run on the same host, I would think this would be acceptable, but I'm not certain.

The problem I'm working on which prompted this inquiry is a segfault that is occurring with QEMU in certain circumstances. The latest Ubuntu (10.10, Maverick) with the proprietary NVIDIA Xorg driver also installs its own version of libGL, which is linked by qemu-native. If I uninstall the proprietary NVIDIA driver and rebuild qemu-native from scratch, the segfault does not occur.

Thanks,

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


Re: Eclipse plugin

Zhang, Jessica
 

Hi Gary,

I just setup my machine for ppc and create a new auto tools based c project
and everything seems working fine for me, so if you go
"Window->Preferecencs->Yocto SDK" in that setup window, do you see "Sysroot"
field? If yo, somehow you're using the 1.0 plugin, but that's fine, just put
"/home/gary/mytarget_poky/tmp/sysroots/ppc603e-poky-linux" there. And try
to reconfigure your project which should trigger autoconfig and the compiler
should be able to use the correct sysroot setup...

Let me know whether that help or not.

Thanks,
Jessica

Gary Thomas wrote:

On 11/22/2010 08:24 AM, Gary Thomas wrote:
On 11/22/2010 06:55 AM, Lu, Lianhao wrote:

Gary Thomas wrote on 2010-11-22:
Thanks, I installed Helios directly from the Eclipse site and
that's working better now. I also installed the components you
mention above.

When I try to configure Yocto, I'm trying to use the Poky tree
method but it doesn't like my tree :-( I pointed it to my build
directory (the one which contains tmp/, sstate-cache/ and conf/)

What else am I missing?
You need to "bitbake meta-ide-support" before you can use the poky
tree mode.
I did that and now I can move a bit farther. I managed to select my
SDK type (ppc603e-poky-linux) and started with the autotools
example. However, I
get this error when trying to run autogen.sh:


Generating Makefile in build directory:
/home/gthomas/workspace/yocto_test3

sh /home/gthomas/workspace/yocto_test3/configure
--host=powerpc-poky-linux --build=i686-linux
--target=powerpc-poky-linux checking for a BSD-compatible install...
/usr/bin/install -c
checking whether build environment is sane... yes
checking for powerpc-poky-linux-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... powerpc-poky-linux-gnu
checking for style of include used by make... GNU
checking for powerpc-poky-linux-gcc... powerpc-poky-linux-gcc
checking whether the C compiler works... no
configure: error: in `/home/gthomas/workspace/yocto_test3':
configure: error: C compiler cannot create executables
See `config.log' for more details.

Configuration failed with error

It looks like there is a confusion over the SDK type and the
compiler setup?
BTW, this was on my console (hidden by the eclipse window), in
case it helps:

get env key CC value powerpc-poky-linux-gcc
get env key CXX value powerpc-poky-linux-g++
get env key GDB value powerpc-poky-linux-gdb
get env key TARGET_PREFIX value powerpc-poky-linux-
get env key CONFIGURE_FLAGS value --target=powerpc-poky-linux
--host=powerpc-poky-linux --build=i686-linux get env key CFLAGS value
-mcpu=603e -mhard-float
get env key CXXFLAGS value -mcpu=603e -mhard-float
get env key POKY_NATIVE_SYSROOT value
/home/gary/mytarget_poky/tmp/sysroots/i686-linux
get env key POKY_TARGET_SYSROOT value
/home/gary/mytarget_poky/tmp/sysroots/ppc603e-poky-linux


Re: New platforms

Bruce Ashfield <bruce.ashfield@...>
 

On 10-11-18 05:36 AM, Chris Tapp wrote:
Hi,

I've been evaluating OpenEmbedded and saw the announcement of 'Yocto'
on the mailing list. Yocto looks like it may be better for my needs as
it is more refined.

As there isn't currently support for the ALIX 3D3 (a Geode LX based
system), I am interested in creating and maintaining a BSP for it.
This should also work with other LX systems (e.g. SUMO ST166, other
ALIX variants), some with no changes, some with minor ones.

Could you give me an idea how much work would be involved in doing
this and what it involve?
I can answer from the kernel point of view.

The supported yocto kernel(s) (currently 2.6.34 and
shortly 2.6.37-rcX) are the place where I can assist
in getting you up and running with a new board/platform
fairly easily.

The kernel documentation is being updated (since I've
made changes recently to streamline just what you
are talking about here), but I can give some more
hands on help while those docs are still outstanding.

For the kernel, you'd need to create a machine.conf
with your optimization, features, etc, and give the
machine a name. There are obviously plenty of examples
on how to do this in the tree.

At that point, you can bootstrap the the BSP process
by doing a: bitbake -c configure linux-yocto.

You then have the kernel git repository staged and
branch for kernel changes to be added. Working with
the kernel in git is key, since you can have a
common branch, and have board specific branches for
configuration or features that are not generally
applicable to all boards.

You can iteratively configure and build the board
from this point.

When you are happy with the changes you can export
the patches, or keep the branches in a local git
tree (better), and if there is assistance in maintaining
the BSP(s) we can contribute them to the maintained
kernel repository (best). This then enables collaboration
and best practices development.

The amount of work depends on the type of kernel
patches you need to add for the board(s) and the
desired feature mix. Userspace difficulty should
be manageable if the known working ARM baseline
builds are used as starting point.

I've gone light on the details here, but if there is
interest, I can provide more information.

And again, this is speaking from the kernel point of
view only.

Cheers,

Bruce


Chris Tapp

opensource@keylevel.com
www.keylevel.com



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


Re: Eclipse plugin

Gary Thomas
 

On 11/22/2010 08:24 AM, Gary Thomas wrote:
On 11/22/2010 06:55 AM, Lu, Lianhao wrote:

Gary Thomas wrote on 2010-11-22:
Thanks, I installed Helios directly from the Eclipse site and that's
working better now. I also installed the components you mention above.

When I try to configure Yocto, I'm trying to use the Poky tree method
but it doesn't like my tree :-( I pointed it to my build directory
(the one which contains tmp/, sstate-cache/ and conf/)

What else am I missing?
You need to "bitbake meta-ide-support" before you can use the poky tree mode.
I did that and now I can move a bit farther. I managed to select my SDK type
(ppc603e-poky-linux) and started with the autotools example. However, I
get this error when trying to run autogen.sh:


Generating Makefile in build directory: /home/gthomas/workspace/yocto_test3

sh /home/gthomas/workspace/yocto_test3/configure --host=powerpc-poky-linux --build=i686-linux --target=powerpc-poky-linux
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for powerpc-poky-linux-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... powerpc-poky-linux-gnu
checking for style of include used by make... GNU
checking for powerpc-poky-linux-gcc... powerpc-poky-linux-gcc
checking whether the C compiler works... no
configure: error: in `/home/gthomas/workspace/yocto_test3':
configure: error: C compiler cannot create executables
See `config.log' for more details.

Configuration failed with error

It looks like there is a confusion over the SDK type and the
compiler setup?
BTW, this was on my console (hidden by the eclipse window), in
case it helps:

get env key CC value powerpc-poky-linux-gcc
get env key CXX value powerpc-poky-linux-g++
get env key GDB value powerpc-poky-linux-gdb
get env key TARGET_PREFIX value powerpc-poky-linux-
get env key CONFIGURE_FLAGS value --target=powerpc-poky-linux --host=powerpc-poky-linux --build=i686-linux
get env key CFLAGS value -mcpu=603e -mhard-float
get env key CXXFLAGS value -mcpu=603e -mhard-float
get env key POKY_NATIVE_SYSROOT value /home/gary/mytarget_poky/tmp/sysroots/i686-linux
get env key POKY_TARGET_SYSROOT value /home/gary/mytarget_poky/tmp/sysroots/ppc603e-poky-linux

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: Eclipse plugin

Gary Thomas
 

On 11/22/2010 06:55 AM, Lu, Lianhao wrote:

Gary Thomas wrote on 2010-11-22:
Thanks, I installed Helios directly from the Eclipse site and that's
working better now. I also installed the components you mention above.

When I try to configure Yocto, I'm trying to use the Poky tree method
but it doesn't like my tree :-( I pointed it to my build directory
(the one which contains tmp/, sstate-cache/ and conf/)

What else am I missing?
You need to "bitbake meta-ide-support" before you can use the poky tree mode.
I did that and now I can move a bit farther. I managed to select my SDK type
(ppc603e-poky-linux) and started with the autotools example. However, I
get this error when trying to run autogen.sh:


Generating Makefile in build directory: /home/gthomas/workspace/yocto_test3

sh /home/gthomas/workspace/yocto_test3/configure --host=powerpc-poky-linux --build=i686-linux --target=powerpc-poky-linux
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for powerpc-poky-linux-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... powerpc-poky-linux-gnu
checking for style of include used by make... GNU
checking for powerpc-poky-linux-gcc... powerpc-poky-linux-gcc
checking whether the C compiler works... no
configure: error: in `/home/gthomas/workspace/yocto_test3':
configure: error: C compiler cannot create executables
See `config.log' for more details.

Configuration failed with error

It looks like there is a confusion over the SDK type and the
compiler setup?

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: Eclipse plugin

Lu, Lianhao <lianhao.lu@...>
 

Gary Thomas wrote on 2010-11-22:
Thanks, I installed Helios directly from the Eclipse site and that's
working better now. I also installed the components you mention above.

When I try to configure Yocto, I'm trying to use the Poky tree method
but it doesn't like my tree :-( I pointed it to my build directory
(the one which contains tmp/, sstate-cache/ and conf/)

What else am I missing?
You need to "bitbake meta-ide-support" before you can use the poky tree mode.

Best Regards,
Lianhao


Re: RFC: Rapid iterative development

Joshua Lock <josh@...>
 

On Fri, 2010-11-19 at 15:14 -0800, Darren Hart wrote:
While working on a single package, I need to be able to tweak a variable
in the new recipe, change the MACHINE in local.conf, etc. I'd like to be
able to rapidly test my changes, but some of these changes trigger a
long list of dependencies for various commands. While working on a new
linux kernel recipe, I found it rebuilding a number of things that were
either -native (can I force it to use the system version rather than
building one) or seemed unrelated to the process at hand.
You can use ASSUME_PROVIDED to use system versions of native tools,
though it's generally not recommended. git grep for the term to find
some examples.

As to building things which seem unrelated, this is possibly because you
have BB_NUMBER_THREADS set high and bitbake is just using the
opportunity to finish some uncompleted tasks - oft a desirable
behaviour.

You could always try BB_NUMBER_THREADS=1 bitbake whatever-package and
see if that behaves more like you expect?



Are there some best practices for iterative recipe development that
speed things along?

Thanks,
--
Joshua Lock
Intel Open Source Technology Centre


Re: Eclipse plugin

Gary Thomas
 

On 11/22/2010 05:50 AM, Lu, Lianhao wrote:
Gary Thomas wrote on 2010-11-22:
On 11/22/2010 02:13 AM, Gary Thomas wrote:
I'm interested in trying the Yocto Eclipse plugin with my Poky based builds.
That said, I'm a true Eclipse novice :-(

Does anyone have some guidance on what packages I might need to
install to get a usable Eclipse framework on Fedora (13)? For
example, the Yocto page mentions the "standard TCF" agent to contact
the target
- how do I make sure this is available and enabled?

n.b. the [web] documentation on this plugin is pretty thin. Perhaps
once I get this going, I can contribute some meat to put on these
bones :-)

Thanks
I tried to follow the documentation in the Poky manual (still
thin...), but it seems I'm now stuck. I get this error:
Cannot complete the install because one or more required items could
not be found. Software being installed: Yocto Plugin for Eclipse
1.0.0.201010202121 (org.yocto.sdk.feature.group 1.0.0.201010202121)
Missing requirement: Yocto Plugin Remote Tools 1.0.0.201010202121
(org.yocto.sdk.remotetools 1.0.0.201010202121) requires 'bundle
org.eclipse.rse.terminals.ui 1.0.100' but it could not be found
Cannot satisfy dependency:
From: Yocto Plugin for Eclipse 1.0.0.201010202121
(org.yocto.sdk.feature.group 1.0.0.201010202121)

As far as I can tell, the eclise-rse package on Fedora 13 is version
1.0.1 :-( Also, Fedora is still on Galileo 3.5.2, not Helios 3.6.

I guess I'll try the raw install of Helios since Fedora+YUM has failed me.
Gary,

Sorry for the thin documentation about eclipse plug-in installation.

The Yocto eclipse plugin has some dependencies on other eclipse plugins:
- C/C++ Development Tools (CDT) (http://download.eclipse.org/tools/cdt/releases/helios if using Eclipse 3.6Helios, or http://download.eclipse.org/tools/cdt/releases/galileo if using Eclipse 3.5Galileo)
- Autotools support for CDT (Incubation) (http://download.eclipse.org/technology/linuxtools/update)
- Target Management (RSE) (http://download.eclipse.org/dsdp/tm/updates/3.2)

To install one of the above eclipse plugins in the IDE,
1. Go to Help> Install New Software... to open the Install dialog.
2. Click the Add... button; this will display the Add Site dialog.
3. Enter the corresponding URL in the Location: field and click "OK". This will add the corresponding update site to the list of available sites.
4. The corresponding update site should now be selected in the "Work with:" selection box. If not, you can select it from the list by clicking the down arrow and locating its entry. You can simply collapse the entry for this site to view content available for installation.
5. Check the corresponding box and click Next button, following the wizard to install the plug-in.
Thanks, I installed Helios directly from the Eclipse site and that's
working better now. I also installed the components you mention above.

When I try to configure Yocto, I'm trying to use the Poky tree method
but it doesn't like my tree :-( I pointed it to my build directory
(the one which contains tmp/, sstate-cache/ and conf/)

What else am I missing?


--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: Eclipse plugin

Lu, Lianhao <lianhao.lu@...>
 

Gary Thomas wrote on 2010-11-22:
On 11/22/2010 02:13 AM, Gary Thomas wrote:
I'm interested in trying the Yocto Eclipse plugin with my Poky based builds.
That said, I'm a true Eclipse novice :-(

Does anyone have some guidance on what packages I might need to
install to get a usable Eclipse framework on Fedora (13)? For
example, the Yocto page mentions the "standard TCF" agent to contact
the target
- how do I make sure this is available and enabled?

n.b. the [web] documentation on this plugin is pretty thin. Perhaps
once I get this going, I can contribute some meat to put on these
bones :-)

Thanks
I tried to follow the documentation in the Poky manual (still
thin...), but it seems I'm now stuck. I get this error:
Cannot complete the install because one or more required items could
not be found. Software being installed: Yocto Plugin for Eclipse
1.0.0.201010202121 (org.yocto.sdk.feature.group 1.0.0.201010202121)
Missing requirement: Yocto Plugin Remote Tools 1.0.0.201010202121
(org.yocto.sdk.remotetools 1.0.0.201010202121) requires 'bundle
org.eclipse.rse.terminals.ui 1.0.100' but it could not be found
Cannot satisfy dependency:
From: Yocto Plugin for Eclipse 1.0.0.201010202121
(org.yocto.sdk.feature.group 1.0.0.201010202121)

As far as I can tell, the eclise-rse package on Fedora 13 is version
1.0.1 :-( Also, Fedora is still on Galileo 3.5.2, not Helios 3.6.

I guess I'll try the raw install of Helios since Fedora+YUM has failed me.
Gary,

Sorry for the thin documentation about eclipse plug-in installation.

The Yocto eclipse plugin has some dependencies on other eclipse plugins:
- C/C++ Development Tools (CDT) (http://download.eclipse.org/tools/cdt/releases/helios if using Eclipse 3.6Helios, or http://download.eclipse.org/tools/cdt/releases/galileo if using Eclipse 3.5Galileo)
- Autotools support for CDT (Incubation) (http://download.eclipse.org/technology/linuxtools/update)
- Target Management (RSE) (http://download.eclipse.org/dsdp/tm/updates/3.2)

To install one of the above eclipse plugins in the IDE,
1. Go to Help > Install New Software... to open the Install dialog.
2. Click the Add... button; this will display the Add Site dialog.
3. Enter the corresponding URL in the Location: field and click "OK". This will add the corresponding update site to the list of available sites.
4. The corresponding update site should now be selected in the "Work with:" selection box. If not, you can select it from the list by clicking the down arrow and locating its entry. You can simply collapse the entry for this site to view content available for installation.
5. Check the corresponding box and click Next button, following the wizard to install the plug-in.

Best Regards,
Lianhao


Re: Eclipse plugin

Gary Thomas
 

On 11/22/2010 02:13 AM, Gary Thomas wrote:
I'm interested in trying the Yocto Eclipse plugin with my Poky based builds.
That said, I'm a true Eclipse novice :-(

Does anyone have some guidance on what packages I might need to install to
get a usable Eclipse framework on Fedora (13)? For example, the Yocto page
mentions the "standard TCF" agent to contact the target - how do I make sure
this is available and enabled?

n.b. the [web] documentation on this plugin is pretty thin. Perhaps once I
get this going, I can contribute some meat to put on these bones :-)

Thanks
I tried to follow the documentation in the Poky manual (still thin...), but
it seems I'm now stuck. I get this error:
Cannot complete the install because one or more required items could not be found.
Software being installed: Yocto Plugin for Eclipse 1.0.0.201010202121 (org.yocto.sdk.feature.group 1.0.0.201010202121)
Missing requirement: Yocto Plugin Remote Tools 1.0.0.201010202121 (org.yocto.sdk.remotetools 1.0.0.201010202121) requires 'bundle org.eclipse.rse.terminals.ui 1.0.100' but it could not be found
Cannot satisfy dependency:
From: Yocto Plugin for Eclipse 1.0.0.201010202121 (org.yocto.sdk.feature.group 1.0.0.201010202121)

As far as I can tell, the eclise-rse package on Fedora 13 is version 1.0.1 :-(
Also, Fedora is still on Galileo 3.5.2, not Helios 3.6.

I guess I'll try the raw install of Helios since Fedora+YUM has failed me.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Yocto weekly bug trend charts -- WW47

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

Hi all,

This is latest Yocto bug trend chart. The open bug number rises a little to 152(last week was 148). With bug triage, most of undecided bugs are set to Medium priority.

We have fixed the wrong bug data (Richard helped to point it out last week) in WW45.

Bug status and priority definations can be referred from https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking

Thanks,
Yongkang


Eclipse plugin

Gary Thomas
 

I'm interested in trying the Yocto Eclipse plugin with my Poky based builds.
That said, I'm a true Eclipse novice :-(

Does anyone have some guidance on what packages I might need to install to
get a usable Eclipse framework on Fedora (13)? For example, the Yocto page
mentions the "standard TCF" agent to contact the target - how do I make sure
this is available and enabled?

n.b. the [web] documentation on this plugin is pretty thin. Perhaps once I
get this going, I can contribute some meat to put on these bones :-)

Thanks

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Using a layer's kernel instead of a machine's stated preferred virtual/kernel provider

Darren Hart <dvhart@...>
 

I've created a new layer which provides a linux kernel. This layer applies to boards (ie beagleboard) that are defined in meta/conf/machines which specify linux-wrs as their preferred kernel.

Is there a standard way of overriding this when building images / packages from a new layer? Something like a machine.append file maybe? I could just copy the machine config and rename it something else - beagleboard-mylayer and set MACHINE=beagleboard-mylayer, but that seems like a hack.

Thanks,

--
Darren Hart
Yocto Linux Kernel


Re: RFC: Rapid iterative development

Darren Hart <dvhart@...>
 

On 11/19/2010 03:42 PM, Tian, Kevin wrote:
From: Darren Hart
Sent: Saturday, November 20, 2010 7:14 AM

While working on a single package, I need to be able to tweak a variable
in the new recipe, change the MACHINE in local.conf, etc. I'd like to be
able to rapidly test my changes, but some of these changes trigger a
long list of dependencies for various commands. While working on a new
linux kernel recipe, I found it rebuilding a number of things that were
either -native (can I force it to use the system version rather than
building one) or seemed unrelated to the process at hand.
That's interesting. Did you build from scratch or incrementally? Ideally only
recipes being changed will be rebuilt in incremental way.
By changing machine type (and therefor architecture) I probably trigger at least all the non -native builds. These were clean builds. I'd just like to eliminate as much of that as possible when testing things like:

$ bitbake linux-linaro -c fetch

and

$ bitbake linux-linaro -c configure



Are there some best practices for iterative recipe development that
speed things along?
"bitbake -k" is one method if you're sure the dependency doesn't change.
But if you change MACHINE, I think a whole rebuild except -native will
be required as it's the fundamental bit for target recipes.
OK, time to get this off the laptop and onto something with some serious storage then I guess.

--
Darren Hart
Yocto Linux Kernel


Re: RFC: Rapid iterative development

Tian, Kevin <kevin.tian@...>
 

From: Darren Hart
Sent: Saturday, November 20, 2010 7:14 AM

While working on a single package, I need to be able to tweak a variable
in the new recipe, change the MACHINE in local.conf, etc. I'd like to be
able to rapidly test my changes, but some of these changes trigger a
long list of dependencies for various commands. While working on a new
linux kernel recipe, I found it rebuilding a number of things that were
either -native (can I force it to use the system version rather than
building one) or seemed unrelated to the process at hand.
That's interesting. Did you build from scratch or incrementally? Ideally only
recipes being changed will be rebuilt in incremental way.


Are there some best practices for iterative recipe development that
speed things along?
"bitbake -k" is one method if you're sure the dependency doesn't change.
But if you change MACHINE, I think a whole rebuild except -native will
be required as it's the fundamental bit for target recipes.

Thanks
Kevin


RFC: Rapid iterative development

Darren Hart <dvhart@...>
 

While working on a single package, I need to be able to tweak a variable in the new recipe, change the MACHINE in local.conf, etc. I'd like to be able to rapidly test my changes, but some of these changes trigger a long list of dependencies for various commands. While working on a new linux kernel recipe, I found it rebuilding a number of things that were either -native (can I force it to use the system version rather than building one) or seemed unrelated to the process at hand.

Are there some best practices for iterative recipe development that speed things along?

Thanks,

--
Darren Hart
Yocto Linux Kernel