Re: [yocto] A question on adding a new program to a new meta layer
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
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] A question on adding a new program to a new meta layer
Bruce,
That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)
The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel
2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts
3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)
#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.
I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.
I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.
Regards,
Insop
* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel
#SRCREV =031d31cfaa1e0c00122bf52639e340353d3b8360
SRCREV =${AUTOREV}
-KBRANCH = sched-dl-V7
-SRC_URI = git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = sched-dl-V7
+#SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+# file://defconfig
+KBRANCH = standard/edf
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
file://defconfig
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
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] A question on adding a new program to a new meta layer
Hi Bruce,
One more question on 3.8 kernel.
Is meta/recipes-kernel/linux/linux-yocto_3.8.bb added soon as well in 1.4?
I am using 1.4_M4.final now.
Thank you.
Insop
On Wed, Mar 6, 2013 at 9:05 PM, Insop Song insop.s...@gmail.com wrote:
Bruce,
That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)
The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel
2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts
3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)
#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.
I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.
I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.
Regards,
Insop
* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel
#SRCREV =031d31cfaa1e0c00122bf52639e340353d3b8360
SRCREV =${AUTOREV}
-KBRANCH = sched-dl-V7
-SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = sched-dl-V7
+#SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+# file://defconfig
+KBRANCH = standard/edf
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
file://defconfig
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] nested meta layers, how can/should it be done?
Hi. I wish to write a custom meta layer that should add on-top of an existing bsp for eg. kernel and u-boot builds. But I want the custom layer to use .bbappend for some standard packages and also add some custom packages. My guess is that it might cause problems for the standard packages (since they are not unique) due to the MACHINE will be pointed out as the base bsp machine config, and the custom bsp will not define a machine on its own. Does this mean that I will have to define this new custom layer as a distro? I am worried that .bbappend stuff will never be executed since nothing will actually point to my custom layer for package recipes unless they are unique. What is the correct way to handle this use-case? Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Samba server?
On Wed, Mar 06, 2013 at 03:31:03PM -0800, Paul D. DeRocco wrote: The poky-danny-8.0 tree doesn't seem to have any Samba stuff in it. However, openembedded does. My untutored, fumbling efforts to include the relevant part of the latter in the former haven't succeeded. Is there an easy way to do this? I just need the server, not the client. Are you talking about openembedded as openembedded-classic or meta-openembedded? Use samba from meta-openembedded. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem editing reference image(s) in Hob
Hello, When trying to edit a reference image in the Hob interface (by e.g., selecting core-image-basic, and then Edit Image) I end up with the error message 'Nothing PROVIDES libgstapp-0.10' each time when trying to build the image). In the Edit Image phase I select the desired packages that I want to include in the image, and then Build Packages. The package build phase completes successfully, and I select the packages again in phas 2/2: Edit Packages. Hob then moves into Building Image phase, but almost immediately fails with the previously mentioned error message. I get the same error message independent of which package(s) I select, and independent of selected reference image. What could be the reason for this? Best regards, Andreas Enbacka ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] nested meta layers, how can/should it be done?
Hi, I am not an expert yet, but here is what I've recently done and I think this will give you some hints to what you want to achieve. I've made a new meta layer so that I can use custom kernel and add new programs on top of existing core-image-* targets. I used qemu targets for now, but I also plan to extend this to other bsp so that I can use on different targets. Here is my meta-dl layer - https://github.com/insop/meta-dl Here is the lab that I've referred, see recipes-kernel and recipes-tools dirs - https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf Regards, Insop = Hi. I wish to write a custom meta layer that should add on-top of an existing bsp for eg. kernel and u-boot builds. But I want the custom layer to use .bbappend for some standard packages and also add some custom packages. My guess is that it might cause problems for the standard packages (since they are not unique) due to the MACHINE will be pointed out as the base bsp machine config, and the custom bsp will not define a machine on its own. Does this mean that I will have to define this new custom layer as a distro? I am worried that .bbappend stuff will never be executed since nothing will actually point to my custom layer for package recipes unless they are unique. What is the correct way to handle this use-case? Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem with applying a patch using default -pnum
Hi. More problems ;)
I have a patch file that needs to be applied to a source tree and the
patch file is copied properly to the ${WORKDIR} directory.
So far so good. But, the problem with this source tree is that it is
not built from the traditional root folder of the repo.
This means I need to change ${S} to point somewhere else. This also
causes the patch system to fail!
I did an override of do_patch() in my .bb and that seems to work, but
I do not like to use overrides unless I really have to.
So basically, is there some way to tell the built-in patch system to
use a different -pnum value?
If there is, I could stick with the do_patch() as provided by default.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with applying a patch using default -pnum
On Thu, Mar 7, 2013 at 1:12 PM, Hans Beckérus hans.becke...@gmail.com wrote:
Hi. More problems ;)
I have a patch file that needs to be applied to a source tree and the
patch file is copied properly to the ${WORKDIR} directory.
So far so good. But, the problem with this source tree is that it is
not built from the traditional root folder of the repo.
This means I need to change ${S} to point somewhere else. This also
causes the patch system to fail!
I did an override of do_patch() in my .bb and that seems to work, but
I do not like to use overrides unless I really have to.
So basically, is there some way to tell the built-in patch system to
use a different -pnum value?
If there is, I could stick with the do_patch() as provided by default.
Hans
Hmm, ok a correction from my side. Forget parts of what I said ;)
The patch system does not seem to use the value of ${S}, it is using
${WORKDIR} as the root for patching, this is also where the patch file
is placed. The problem in my case does not seem to be that is built
from a non-standard path. The reason why it fails seems to be because
the actual source is not in ${WORKDIR}, it is in ${WORKDIR}/git. The
patch file does include git as part of the source path for obvious
reasons. What am I doing wrong? Having actual source code in
${WORKDIR}/git I assume is very common for git based downloads.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A question on adding a new program to a new meta layer
On 13-03-06 11:24 PM, Juri Lelli wrote:
Hi,
On 03/06/2013 08:00 PM, Bruce Ashfield wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Thanks a lot for your support! I'm already in contact with Insop, it
would be great to coordinate among ourselves.
Thanks Juri, I was going to add you to my linux-yocto-3.8 announcement
email and due to some last minute debug activities .. it slipped my
mind. So I'm using this thread to let you, and anyone else that is
interested know that sched_deadline support is available to try out
in linux-yocto-3.8.
As I already told to Insop, I don't have any automated test for the
patchset, but I usually run different scenarios using basically this
two tools (and giving a look at simple cases through kernelshark):
1- schedtool-dl: https://github.com/jlelli/schedtool-dl
the idea here is to let a 'yes' run through SCHED_DEADLINE and
check through kernelshark that the bandwidth enforcement
mechanism works.
2- rt-app: https://github.com/gbagnoli/rt-app
with this I usually let some tasksets run for several hours on
a 48-cores machine we have in our lab, I can provide the tasksets
(json files) and the script to run them.
Please let me know how I can help further.
This is a good start. I have some old references to tests that I'll
dig up as well.
I'm looking to develop some real world examples of the scheduler
class in action, since as we've been saying .. getting those examples
will both help the approach and perhaps help get it merged into the
mainline kernel.
Cheers,
Bruce
Best Regards,
- Juri
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline
scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
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] A question on adding a new program to a new meta layer
On 13-03-07 12:05 AM, Insop Song wrote:
Bruce,
That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)
I have another suggestion to offer here, one I've been wanting to
do for a bit.
I've added Darren Hart to the thread, since I'd like to hear from
him on this as well.
I have a use for the scheduling tools and benchmark cases for some
virtualization usecases (meta-virtualization on git.yoctoproject.org).
We already have recipes-rt in oe-core, and the preempt-rt kernel
available from linux-yocto, and as we've been discussing I've added
support for EDF/sched_dealine in linux-yocto-3.8.
I'm not a fan of having to many layers, but rather than putting these
efforts in github layers, hiding them in meta-virtualiation and they
aren't yet core enough to go in oe-core .. I'd rather see them
conslidated in a meta-realtime (or whatever name we decide on)
layer on git.yoctoproject.org.
There are also ideas around interrupt management, AMP, and alternative
system partitioning that I'd like to drive into such a layer.
A quick scan of the layer index, doesn't show anything that matches
this description. So I'm suggesting that we create a new layer
to consolidate these approaches, and a layer that can be consumed by
some of the other layers that are currently in progress.
Comments ? In particular, point out a layer that already does this that
I've missed.
The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel
2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts
3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)
#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.
I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.
I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.
See above. I'd like to consolidate things even more :)
Cheers,
Bruce
Regards,
Insop
* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel
#SRCREV =031d31cfaa1e0c00122bf52639e340353d3b8360
SRCREV =${AUTOREV}
-KBRANCH = sched-dl-V7
-SRC_URI = git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = sched-dl-V7
+#SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+# file://defconfig
+KBRANCH = standard/edf
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
file://defconfig
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
Re: [yocto] A question on adding a new program to a new meta layer
On 13-03-07 03:26 AM, Insop Song wrote:
Hi Bruce,
One more question on 3.8 kernel.
Is meta/recipes-kernel/linux/linux-yocto_3.8.bb added soon as well in 1.4?
It's in master as of a few days ago. So it's available and
ready for use.
Cheers,
Bruce
I am using 1.4_M4.final now.
Thank you.
Insop
On Wed, Mar 6, 2013 at 9:05 PM, Insop Song insop.s...@gmail.com wrote:
Bruce,
That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)
The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel
2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts
3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)
#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.
I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.
I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.
Regards,
Insop
* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel
#SRCREV =031d31cfaa1e0c00122bf52639e340353d3b8360
SRCREV =${AUTOREV}
-KBRANCH = sched-dl-V7
-SRC_URI = git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = sched-dl-V7
+#SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+# file://defconfig
+KBRANCH = standard/edf
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
file://defconfig
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
yocto mailing list
yocto@yoctoproject.org
Re: [yocto] A question on adding a new program to a new meta layer
On 13-03-07 12:05 AM, Insop Song wrote:
Bruce,
That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)
The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel
2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts
3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)
#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.
I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.
I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.
Regards,
Insop
* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel
#SRCREV =031d31cfaa1e0c00122bf52639e340353d3b8360
SRCREV =${AUTOREV}
-KBRANCH = sched-dl-V7
-SRC_URI = git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = sched-dl-V7
+#SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+# file://defconfig
+KBRANCH = standard/edf
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
file://defconfig
What do you have in your defconfig ? I'm about to push patches that
will make enabling sched_dealine a KERNEL_FEATURE option, which makes
it even easier to use.
But in the meantime, if you want to enable the support on a yocto BSP,
you can change your defconfig to be sched-deadline.cfg and only
put the kernel options required to enable the feature.
Cheers,
Bruce
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
yocto mailing list
[yocto] [eclipse-poky][PATCHv3 0/6] Refactorings in org.yocto.sdk.ide plugin
From: Atanas Gegov atanas.ge...@bmw-carit.de Hi, Currently the org.yocto.sdk.ide plugin has the YoctoSDKEmptyProjectNature and the YoctoSDKProjectNature. The latter is strongly coupled with the Autotools nature since this is by now the only supported build system. It would be nice if it is possible to introduce other Yocto IDE projects,e.g. projects using CMake for building. This patch series does some refactoring in the org.yocto.sdk.ide plugin. This allows a simplified addition of further natures and enables the decoupling between YoctoSDKProjectNature and the Autotools nature. The natures and the utils get their own packages. Some methods and members were also moved to suitable classes. Cheers, Atanas Atanas Gegov (6): Moved YoctoSDK natures to their own package Moved functionality that does not belong to YoctoSDKProjectNature Moved utils to their own package Moved nature-related utils in own class Export the new subpackages of org.yocto.sdk.ide Performed a whitespaces cleanup plugins/org.yocto.sdk.ide/META-INF/MANIFEST.MF |2 + plugins/org.yocto.sdk.ide/plugin.xml |4 +- .../src/org/yocto/sdk/ide/YoctoSDKChecker.java | 12 +- .../yocto/sdk/ide/YoctoSDKEmptyProjectNature.java | 38 - .../org/yocto/sdk/ide/YoctoSDKProjectNature.java | 267 --- .../src/org/yocto/sdk/ide/YoctoSDKUtils.java | 607 .../ide/natures/YoctoSDKEmptyProjectNature.java| 39 + .../yocto/sdk/ide/natures/YoctoSDKNatureUtils.java | 39 + .../sdk/ide/natures/YoctoSDKProjectNature.java | 111 +++ .../ide/preferences/YoctoSDKPreferencePage.java|4 +- .../preferences/YoctoSDKProjectPropertyPage.java |2 +- .../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 743 .../sdk/ide/utils/YoctoSDKUtilsConstants.java | 18 + .../sdk/ide/wizard/NewYoctoCProjectTemplate.java |6 +- 14 files changed, 969 insertions(+), 923 deletions(-) delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKEmptyProjectNature.java delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKProjectNature.java delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKUtils.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKEmptyProjectNature.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKNatureUtils.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtilsConstants.java -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCHv3 1/6] Moved YoctoSDK natures to their own package
From: Atanas Gegov atanas.ge...@bmw-carit.de
If further natures are added, they will fit into
this package and not overpopulate the org.yocto.sdk.ide package.
---
plugins/org.yocto.sdk.ide/plugin.xml |4 +-
.../src/org/yocto/sdk/ide/YoctoSDKChecker.java |2 +
.../yocto/sdk/ide/YoctoSDKEmptyProjectNature.java | 38 ---
.../org/yocto/sdk/ide/YoctoSDKProjectNature.java | 267 ---
.../src/org/yocto/sdk/ide/YoctoSDKUtils.java |1 +
.../ide/natures/YoctoSDKEmptyProjectNature.java| 40 +++
.../sdk/ide/natures/YoctoSDKProjectNature.java | 275
.../ide/preferences/YoctoSDKPreferencePage.java|2 +-
.../sdk/ide/wizard/NewYoctoCProjectTemplate.java |4 +-
9 files changed, 323 insertions(+), 310 deletions(-)
delete mode 100644
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKEmptyProjectNature.java
delete mode 100644
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKProjectNature.java
create mode 100644
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKEmptyProjectNature.java
create mode 100644
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
diff --git a/plugins/org.yocto.sdk.ide/plugin.xml
b/plugins/org.yocto.sdk.ide/plugin.xml
index 6548ae2..ea1a8ab 100644
--- a/plugins/org.yocto.sdk.ide/plugin.xml
+++ b/plugins/org.yocto.sdk.ide/plugin.xml
@@ -24,7 +24,7 @@
/requires-nature
runtime
run
- class=org.yocto.sdk.ide.YoctoSDKProjectNature
+ class=org.yocto.sdk.ide.natures.YoctoSDKProjectNature
/run
/runtime
builder
@@ -36,7 +36,7 @@
point=org.eclipse.core.resources.natures
runtime
run
- class=org.yocto.sdk.ide.YoctoSDKEmptyProjectNature
+ class=org.yocto.sdk.ide.natures.YoctoSDKEmptyProjectNature
/run
/runtime
/extension
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
index 5f790ee..3047641 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
@@ -19,6 +19,8 @@ import java.io.FileReader;
import java.io.FilenameFilter;
import java.io.IOException;
+import org.yocto.sdk.ide.natures.YoctoSDKProjectNature;
+
public class YoctoSDKChecker {
private static final String[] saInvalidVer = {1.0, 0.9, 0.9+};
private static final String SYSROOTS_DIR = sysroots;
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKEmptyProjectNature.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKEmptyProjectNature.java
deleted file mode 100644
index 8df9e86..000
---
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKEmptyProjectNature.java
+++ /dev/null
@@ -1,38 +0,0 @@
-package org.yocto.sdk.ide;
-
-import org.eclipse.core.resources.IProject;
-import org.eclipse.core.resources.IProjectNature;
-import org.eclipse.core.runtime.CoreException;
-import org.eclipse.core.runtime.IProgressMonitor;
-
-public class YoctoSDKEmptyProjectNature implements IProjectNature {
-
- public static final String YoctoSDK_EMPTY_NATURE_ID =
YoctoSDKPlugin.getUniqueIdentifier() + .YoctoSDKEmptyNature;
-
- private IProject proj;
-
- public void configure() throws CoreException {
- // TODO Auto-generated method stub
-
- }
-
- public void deconfigure() throws CoreException {
- // TODO Auto-generated method stub
-
- }
-
- public IProject getProject() {
- // TODO Auto-generated method stub
- return proj;
- }
-
- public void setProject(IProject project) {
- // TODO Auto-generated method stub
- this.proj = project;
- }
-
- public static void addYoctoSDKEmptyNature(IProject project,
IProgressMonitor monitor) throws CoreException {
- YoctoSDKUtils.addNature(project, YoctoSDK_EMPTY_NATURE_ID,
monitor);
- }
-
-}
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKProjectNature.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKProjectNature.java
deleted file mode 100644
index 69b1e2a..000
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKProjectNature.java
+++ /dev/null
@@ -1,267 +0,0 @@
-/***
- * Copyright (c) 2010 Intel Corporation.
- * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
- * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html
- *
- * Contributors:
- * Intel - initial API and implementation
-
[yocto] [PATCHv3 2/6] Moved functionality that does not belong to YoctoSDKProjectNature
From: Atanas Gegov atanas.ge...@bmw-carit.de
This functionality is not directly connected to the
YoctoSDKProjectNature itself. Moreover, it might also be used
by other natures. Made a lot of constants private as they are
used only locally. Globally used constants are moved in an own class.
---
.../src/org/yocto/sdk/ide/YoctoSDKChecker.java |8 +-
.../src/org/yocto/sdk/ide/YoctoSDKUtils.java | 154 +-
.../org/yocto/sdk/ide/YoctoSDKUtilsConstants.java | 18 +++
.../sdk/ide/natures/YoctoSDKProjectNature.java | 166 +---
4 files changed, 176 insertions(+), 170 deletions(-)
create mode 100644
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKUtilsConstants.java
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
index 3047641..bab6ade 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKChecker.java
@@ -24,6 +24,7 @@ import org.yocto.sdk.ide.natures.YoctoSDKProjectNature;
public class YoctoSDKChecker {
private static final String[] saInvalidVer = {1.0, 0.9, 0.9+};
private static final String SYSROOTS_DIR = sysroots;
+ private static final String SDK_VERSION = OECORE_SDK_VERSION;
public static enum SDKCheckResults {
SDK_PASS(, false),
@@ -148,10 +149,11 @@ public class YoctoSDKChecker {
String sFileName;
if (elem.getEnumPokyMode() ==
YoctoUIElement.PokyMode.POKY_SDK_MODE) {
- sFileName = elem.getStrToolChainRoot()+/ +
YoctoSDKProjectNature.DEFAULT_ENV_FILE_PREFIX+elem.getStrTarget();
+ sFileName = elem.getStrToolChainRoot()+/ +
YoctoSDKUtilsConstants.DEFAULT_ENV_FILE_PREFIX + elem.getStrTarget();
} else {
//POKY TREE Mode
- sFileName = elem.getStrToolChainRoot() +
YoctoSDKProjectNature.DEFAULT_TMP_PREFIX +
YoctoSDKProjectNature.DEFAULT_ENV_FILE_PREFIX + elem.getStrTarget();
+ sFileName = elem.getStrToolChainRoot() +
YoctoSDKUtilsConstants.DEFAULT_TMP_PREFIX +
+
YoctoSDKUtilsConstants.DEFAULT_ENV_FILE_PREFIX + elem.getStrTarget();
}
try {
@@ -165,7 +167,7 @@ public class YoctoSDKChecker {
String line = null;
while ((line =
input.readLine()) != null) {
- if
(line.startsWith(export + YoctoSDKProjectNature.SDK_VERSION)) {
+ if
(line.startsWith(export + SDK_VERSION)) {
int beginIndex
= 2;
String sVersion
= ;
for (;;) {
diff --git a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKUtils.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKUtils.java
index 35ff3d4..e95be4d 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKUtils.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKUtils.java
@@ -14,11 +14,17 @@ package org.yocto.sdk.ide;
import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
+import java.io.FileWriter;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
+import java.util.ArrayList;
import java.util.HashMap;
+import java.util.HashSet;
import java.util.Iterator;
+import java.util.Map;
+import java.util.Set;
+import java.util.StringTokenizer;
import org.eclipse.cdt.core.CCorePlugin;
import org.eclipse.cdt.core.ConsoleOutputStream;
@@ -29,6 +35,8 @@ import org.eclipse.cdt.core.model.CoreModel;
import org.eclipse.cdt.core.resources.IConsole;
import org.eclipse.cdt.core.settings.model.ICConfigurationDescription;
import org.eclipse.cdt.core.settings.model.ICProjectDescription;
+import org.eclipse.cdt.debug.core.ICDTLaunchConfigurationConstants;
+import org.eclipse.cdt.debug.mi.core.IMILaunchConfigurationConstants;
import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IProjectDescription;
import org.eclipse.core.resources.ProjectScope;
@@ -36,8 +44,14 @@ import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.preferences.IEclipsePreferences;
import org.eclipse.core.runtime.preferences.IScopeContext;
+import org.eclipse.debug.core.DebugPlugin;
+import org.eclipse.debug.core.ILaunchConfiguration;
+import org.eclipse.debug.core.ILaunchConfigurationType;
+import
[yocto] [PATCHv3 4/6] Moved nature-related utils in own class
From: Atanas Gegov atanas.ge...@bmw-carit.de
Created a nature specific utils class and moved
a method that is only relevant in the natures context.
---
.../ide/natures/YoctoSDKEmptyProjectNature.java|3 +-
.../yocto/sdk/ide/natures/YoctoSDKNatureUtils.java | 39
.../sdk/ide/natures/YoctoSDKProjectNature.java |2 +-
.../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 20 --
4 files changed, 41 insertions(+), 23 deletions(-)
create mode 100644
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKNatureUtils.java
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKEmptyProjectNature.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKEmptyProjectNature.java
index 9057b8e..6c9a5ac 100644
---
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKEmptyProjectNature.java
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKEmptyProjectNature.java
@@ -5,7 +5,6 @@ import org.eclipse.core.resources.IProjectNature;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.IProgressMonitor;
import org.yocto.sdk.ide.YoctoSDKPlugin;
-import org.yocto.sdk.ide.utils.YoctoSDKUtils;
public class YoctoSDKEmptyProjectNature implements IProjectNature {
@@ -34,7 +33,7 @@ public class YoctoSDKEmptyProjectNature implements
IProjectNature {
}
public static void addYoctoSDKEmptyNature(IProject project,
IProgressMonitor monitor) throws CoreException {
- YoctoSDKUtils.addNature(project, YoctoSDK_EMPTY_NATURE_ID,
monitor);
+ YoctoSDKNatureUtils.addNature(project,
YoctoSDK_EMPTY_NATURE_ID, monitor);
}
}
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKNatureUtils.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKNatureUtils.java
new file mode 100644
index 000..5a2a6b1
--- /dev/null
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKNatureUtils.java
@@ -0,0 +1,39 @@
+/***
+ * Copyright (c) 2010 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Intel - initial API and implementation
+ * BMW Car IT - extracted in an own class
+
***/
+package org.yocto.sdk.ide.natures;
+
+import org.eclipse.core.resources.IProject;
+import org.eclipse.core.resources.IProjectDescription;
+import org.eclipse.core.runtime.CoreException;
+import org.eclipse.core.runtime.IProgressMonitor;
+
+public class YoctoSDKNatureUtils {
+
+ public static void addNature(IProject project, String natureId,
IProgressMonitor monitor) throws CoreException
+ {
+ IProjectDescription description = project.getDescription();
+ String[] natures = description.getNatureIds();
+
+ for (int i = 0; i natures.length; ++i) {
+ if (natureId.equals(natures[i]))
+ return;
+ }
+
+ String[] newNatures = new String[natures.length + 1];
+ System.arraycopy(natures, 0, newNatures, 0, natures.length);
+ newNatures[natures.length] = natureId;
+ description.setNatureIds(newNatures);
+ project.setDescription(description, monitor);
+
+ }
+
+}
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
index 2c6a782..a299aa4 100644
---
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
@@ -60,7 +60,7 @@ public class YoctoSDKProjectNature implements IProjectNature {
}
public static void addYoctoSDKNature(IProject project, IProgressMonitor
monitor) throws CoreException {
- YoctoSDKUtils.addNature(project, YoctoSDK_NATURE_ID, monitor);
+ YoctoSDKNatureUtils.addNature(project, YoctoSDK_NATURE_ID,
monitor);
}
public static void configureAutotoolsOptions(IProject project) {
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
index 5ccd6e2..2d3850f 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
@@ -38,10 +38,8 @@ import
org.eclipse.cdt.core.settings.model.ICProjectDescription;
import
[yocto] [PATCHv3 5/6] Export the new subpackages of org.yocto.sdk.ide
From: Atanas Gegov atanas.ge...@bmw-carit.de --- plugins/org.yocto.sdk.ide/META-INF/MANIFEST.MF |2 ++ 1 file changed, 2 insertions(+) diff --git a/plugins/org.yocto.sdk.ide/META-INF/MANIFEST.MF b/plugins/org.yocto.sdk.ide/META-INF/MANIFEST.MF index b09abb3..0bdaa85 100644 --- a/plugins/org.yocto.sdk.ide/META-INF/MANIFEST.MF +++ b/plugins/org.yocto.sdk.ide/META-INF/MANIFEST.MF @@ -29,6 +29,8 @@ Require-Bundle: org.eclipse.ui, Bundle-RequiredExecutionEnvironment: JavaSE-1.6 Bundle-ActivationPolicy: lazy Export-Package: org.yocto.sdk.ide, + org.yocto.sdk.ide.natures, + org.yocto.sdk.ide.utils, org.yocto.sdk.ide.actions, org.yocto.sdk.ide.preferences, org.yocto.sdk.ide.wizard -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCHv3 6/6] Performed a whitespaces cleanup
From: Atanas Gegov atanas.ge...@bmw-carit.de
While moving these files into new packages
it turned out that there is a need of whitespaces cleanup.
---
.../sdk/ide/natures/YoctoSDKProjectNature.java |2 +-
.../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 102 ++--
2 files changed, 52 insertions(+), 52 deletions(-)
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
index a299aa4..fcb296d 100644
---
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java
@@ -73,7 +73,7 @@ public class YoctoSDKProjectNature implements IProjectNature {
String CXXFLAGS_str = YoctoSDKUtils.getEnvValue(project,
CXXFLAGS);
String CPPFLAGS_str = YoctoSDKUtils.getEnvValue(project,
CPPFLAGS);
String LDFLAGS_str = YoctoSDKUtils.getEnvValue(project,
LDFLAGS);
-
+
String command_prefix = CFLAGS=\ -g -O0 + CFLAGS_str + \
CXXFLAGS=\ -g -O0
+ CXXFLAGS_str + \ LDFLAGS=\ + LDFLAGS_str + \
CPPFLAGS=\ + CPPFLAGS_str + \;
String autogen_setting = command_prefix+ autogen.sh +
DEFAULT_LIBTOOL_SYSROOT_PREFIX + sysroot_str;
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
index 2d3850f..bd781b3 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
@@ -79,7 +79,7 @@ public class YoctoSDKUtils {
if (var == null)
{
System.out.printf(ENV key %s is NULL\n, strKey);
- return ;
+ return ;
}
else
@@ -123,7 +123,7 @@ public class YoctoSDKUtils {
IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
env.addVariable(PreferenceConstants.SYSROOT,
elem.getStrSysrootLoc(),
IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
-
+
if (envMap == null)
{
System.out.println(ENV var hasmap is NULL, Please
check ENV script File!);
@@ -131,15 +131,15 @@ public class YoctoSDKUtils {
}
IteratorString iter = envMap.keySet().iterator();
while (iter.hasNext())
- {
+ {
String sKey = (String)iter.next();
String sValue = (String)envMap.get(sKey);
String targetFilePath;
File targetFile;
//replace --sysroot
- if (sKey.matches(CFLAGS) || sKey.matches(CXXFLAGS)
|| sKey.matches(CXXFLAGS) || sKey.matches(LDFLAGS) ||
+ if (sKey.matches(CFLAGS) || sKey.matches(CXXFLAGS)
|| sKey.matches(CXXFLAGS) || sKey.matches(LDFLAGS) ||
sKey.matches(CPPFLAGS)) {
-
+
int SYSROOT_idx =
sValue.lastIndexOf(DEFAULT_SYSROOT_PREFIX);
if (SYSROOT_idx =0 )
sValue = sValue.substring(0,
SYSROOT_idx) + DEFAULT_SYSROOT_PREFIX + elem.getStrSysrootLoc();
@@ -149,7 +149,7 @@ public class YoctoSDKUtils {
targetFile = new File(targetFilePath);
if (targetFile.exists())
sValue = sValue + / +
elem.getStrTarget();
- } else if (sKey.matches(CONFIGURE_FLAGS)) {
+ } else if (sKey.matches(CONFIGURE_FLAGS)) {
int LIBTOOL_idx =
sValue.lastIndexOf(LIBTOOL_SYSROOT_PREFIX);
if (LIBTOOL_idx = 0)
sValue = sValue.substring(0,
LIBTOOL_idx) + LIBTOOL_SYSROOT_PREFIX + elem.getStrSysrootLoc();
@@ -158,7 +158,7 @@ public class YoctoSDKUtils {
targetFilePath = elem.getStrSysrootLoc() + /
+ elem.getStrTarget();
targetFile = new File(targetFilePath);
if (targetFile.exists())
- sValue = sValue + / +
elem.getStrTarget();
+ sValue = sValue + / +
elem.getStrTarget();
} else if(sKey.matches(PKG_CONFIG_SYSROOT_DIR) ||
sKey.matches(OECORE_TARGET_SYSROOT)) {
Re: [yocto] Busybox still old version: Still looking for a clear understanding of an old mystery.
On Tuesday 15 January 2013 15:28:25 Rudolf Streif wrote: What are you exactly referring to as new version? The package version that bitbake builds is defined by the recipe, through the version designation in the recipe's file name or through explicitly setting PV. I think what you are trying to do is to modify the busybox configuration and then recompile and package. Bitbake will not automatically recompile after menuconfig. Menuconfig does not invslidate the shared state cache. I think it possibly should though, since it does for the kernel. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A question on adding a new program to a new meta layer
Hi,
On 03/06/2013 08:00 PM, Bruce Ashfield wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Thanks a lot for your support! I'm already in contact with Insop, it
would be great to coordinate among ourselves.
As I already told to Insop, I don't have any automated test for the
patchset, but I usually run different scenarios using basically this
two tools (and giving a look at simple cases through kernelshark):
1- schedtool-dl: https://github.com/jlelli/schedtool-dl
the idea here is to let a 'yes' run through SCHED_DEADLINE and
check through kernelshark that the bandwidth enforcement
mechanism works.
2- rt-app: https://github.com/gbagnoli/rt-app
with this I usually let some tasksets run for several hours on
a 48-cores machine we have in our lab, I can provide the tasksets
(json files) and the script to run them.
Please let me know how I can help further.
Best Regards,
- Juri
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
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] Question about file systems
On Tue, Mar 5 2013 at 08:20 -0800, Paul D. DeRocco wrote: So I guess the questions are these: Are ext2, ext3 and ext4 all equally likely to need to do an fsck after a disorderly shutdown? Do they typically take different amounts of time to do an fsck? Or is the journaling of ext3 and ext4 something that should be avoided on a flash drive at all costs, even though my app won't be doing much file access? While ext2 will need a fsck after a disorderly shutdown, ext3 and ext4 should not. They are journalling file systems and an unclean shutdown shouldn't affect them... *if* they can trust the underlying disk. However, you are using SSD-type storage, so that basically means you *can't* trust the underlying disk. If you pull power from a device like that when it isn't entirely quiescent, then you run the risk of the *whole* device going wrong. It's got a kind of filesystem of its own *internally*, which uses the flash and makes it *pretend* to have atomically-overwritable 512-byte sectors like a disk. Oh, and it'll do its own garbage collection in the background even when you're not talking to it. So you can't *know* when it's quiescent. Those internal file systems, or flash translation layers, are almost universally poorly implemented, and *will* lose data if you apply random power failures to them. Asking about the file system that you use on *top* of that disk, be it fat/ext2/ext3/btrfs or whatever, is entirely irrelevant. If you care about data integrity in an environment where power is unsafe, then you really need to let the Linux system have direct access to real flash chips and use a proper flash file system like ubifs, *not* this misguided pretend-to-be-spinning-rust approach. That was sensible in the DOS days where the only way we could provide additional storage for the system was to implement an INT 13h DISK BIOS handler, but it's completely unnecessary now. If you try really hard and do extensive testing, and you pay over the odds for your devices, you *might* manage to find one which (at least for the batch you're testing until they change the innards again without changing the model number) will pass your powerfail testing. Best of luck with that. You'll need it. If you're really stuck with this model of storage and can't fix it, then I recommend you do some serious testing with automated power withdrawal and see if you can live with the results. Forget the file system on top; just test the device itself. On that note, I really ought to push some *code* to http://git.infradead.org/mmctest.git to go with the sternly-worded README. With few writes, you're probably better off with ext3 rather than ext2. It should avoid the need for a fsck. Until the device corrupts itself. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] trap: 80: SIGHUP: bad trap comes up when building core-image-sato.
I got an ERROR when building the core-image-sato. branch is danny-8.0 Build Configuration: BB_VERSION= 1.17.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-10.04 TARGET_SYS= x86_64-poky-linux MACHINE = qemux86-64 DISTRO= poky DISTRO_VERSION= 1.3+snapshot-20130307 TUNE_FEATURES = m64 TARGET_FPU= meta meta-yocto meta-yocto-bsp= danny-8.0:6663b79452bcdd95fc69e1ec853baae6c5297ab2 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: validating kernel config, see log.do_kernel_configcheck for details WARNING: QA Issue: rpm: Files/directories were installed but not shipped /etc /etc/rcS.d /etc/rcS.d/S98run-postinsts ERROR: Function failed: do_configure (see /home/zb/mnt/building/yocto/mybuild/tmp/work/x86_64-poky-linux/busybox/1.20.2-r5/temp/log.do_configure.15097 for further information) ERROR: Logfile of failure stored in: /home/zb/mnt/building/yocto/mybuild/tmp/work/x86_64-poky-linux/busybox/1.20.2-r5/temp/log.do_configure.15097 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | trap: 80: SIGHUP: bad trap | ERROR: Function failed: do_configure (see /home/zb/mnt/building/yocto/mybuild/tmp/work/x86_64-poky-linux/busybox/1.20.2-r5/temp/log.do_configure.15097 for further information) ERROR: Task 1217 (/mnt/working/yocto/poky/meta/recipes-core/busybox/busybox_1.20.2.bb, do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 3729 tasks of which 1320 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: /mnt/working/yocto/poky/meta/recipes-core/busybox/busybox_1.20.2.bb, do_configure Summary: There was 1 WARNING message shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. 1. What the problem might be?___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Full Pass Test Report for Yocto 1.3.1 RC1 201302262 Build
From: Stoicescu, CorneliuX Sent: Thursday, February 21, 2013 11:48 AM To: yocto Subject: Weekly Test Report for Yocto 1.4 20130213 Build Hello, Here is this the report for the 1.3.1 RC1 danny build: https://wiki.yoctoproject.org/wiki/Full_Pass_Test_Report_for_Yocto_1.3.1_RC1_201302262_Build NOTE: A follow-up full pass was started for danny 1.3.1 . It should be ready by next week's YPTM. Please send us feedback regarding what you like/don't like in this new reporting style. The current status of the real-time reporting tool: -The template used for each build is located at: https://wiki.yoctoproject.org/wiki/QA_Status_TEMPLATE -The report is generated from the template, replacing the template (placeholder) test runs with actual test run numbers from Testopia (https://wiki.yoctoproject.org/wiki/Testopia ) -NEW: a new summary report is in the works all will be ready this week. This will be used in the milestone reporting page: https://wiki.yoctoproject.org/wiki/Yocto_1.4_Milestone_Test_Report Thank you for the support ! If you have any questions or concerns, please contact me or my team. Regards, Cornel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to bitbake core-image-minimal on Archlinux
在 2013-03-04 06:16:55，Jack Mitchell m...@communistcode.co.uk 写道： On 03/03/13 18:02, Ismael Barros² wrote: Hi there, I'm new to Yocto, and I keep finding errors that prevent me from building a minimal image. I've just installed poky-danny-8.0, sourced oe-init-build-env, and bitbaked core-image-minimal. The first error is that bitbake sanity checks fail to detect the network access, while my network connectivity is perfect, and downloading packages seem to work if I disable this checks. Full log: http://pastebin.com/6jJCC1qp. I couldn't find any log that told me which piece of code was failing, so I jut disabled this check on ../meta-yocto/conf/distro/poky.conf Upon trying again, building started fine, but it started failing to build the documentation for some packages, i.e. binutils-cross. First off, I want to build a single mission appliance, I don't really want to build any documentation, is there any way I can disable it? Anyway, this is the build log: http://pastebin.com/n9U4GfjG. Looks like there are some texinfo commands my machine (texinfo 5.0) doesn't recognice. According to http://sourceware.org/bugzilla/show_bug.cgi?id=15183, it's a known bug on binuilts-2.22 and it's fixed on binuilts-2.23. Poking around, looks like updating to binutils-2.23 got it kind of working: mv ./meta/recipes-devtools/binutils/binutils-2.22.inc ./meta/recipes-devtools/binutils/binutils-2.23.1.inc mv ./meta/recipes-devtools/binutils/binutils-cross-canadian_2.22.bb ./meta/recipes-devtools/binutils/binutils-cross-canadian_2.23.1.bb mv ./meta/recipes-devtools/binutils/binutils_2.22.bb ./meta/recipes-devtools/binutils/binutils_2.23.1.bb mv ./meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb ./meta/recipes-devtools/binutils/binutils-crosssdk_2.23.1.bb mv ./meta/recipes-devtools/binutils/binutils-cross_2.22.bb ./meta/recipes-devtools/binutils/binutils-cross_2.23.1.bb I also had to update the md5 and sha1 on ./meta/recipes-devtools/binutils/binutils-2.23.1.inc. After that, some patches failed to apply: libtool-2.4-update.patch, binutils-2.19.1-ld-sysroot.patch, binutils-poison.patch, libtool-rpath-fix.patch, clone-shadow.patch... so gave up What would be the appropiate way to workaround this issue, besides not using Archlinux? Btw, if the bitbake core-image-minimal fails because there's not enough disk space, and the free disk in the partition is left to 0, after that even the bitbake clean command fails :\ Anyway, thank you guys for what seems to be an excellent BSP factory, I'm really looking forward to start using it at our company :) Kind regards, Ismael ___ yocto mailing list yocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto Hi Ismael, Archlinux currently has texinfo5 in it's core repo which breaks a significant amount of packages. I would suggest downgrading to textinfo4.x (can't remember the exact version) and then things should at least start to get going again. I'm afraid however if you insist on using a rolling release distro you are going to hit these problems more often than most, if you want a stable build environment then I would suggest using a sanity tested distro. If you do with to persist with Archlinux I suggest you follow oe-core/yocto master and update regulary. One dummy question, how to find out the list of all sanity tested distro, i just saw a long list from the output of git tag. Thanks, Biao Cheers, Jack. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hob terminal is getting terminated
Hi, I tried putting the tar files in the download folder but that did not work. I tried extracting the files too. But no luck :( What shall I do to make this work...??? On Thu, Mar 7, 2013 at 5:13 AM, Trevor Woerner twoer...@gmail.com wrote: I don't see any reason this conversation can't be on the public mailing list. That way others can help and/or learn from the discussion. I hope you don't mind be bringing it back to the mailing list. On Wed, Mar 6, 2013 at 11:32 AM, varun bhatnagar varun292...@gmail.com wrote: YesI have...I tried running bitbake todayit also checked for the dependencies and it was trying to download quilt-0.60.tar.gz from http://savannah.gnu.org and from many other mirror sitesbut connection was not getting established. Is there any way through which I can manually install these dependencies and then run bitbake? If you have look at your conf/local.conf file you'll see a variable called DL_DIR. If it is commented out, then your download directory will be a directory named downloads based wherever your build it taking place (if it is set to something, that something becomes your download directory). If you are having network issues, you can download the necessary files yourself. If you place them in this DL_DIR directory they will be found and used by your build. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze
Hi Khem, Any plans on moving to gcc-4.7.3 or 4.8.0 anytime soon? Nearly all the microblaze gcc patches are for gcc-4.8.0 on the trunk, several of them in fact. I've re-applied and ported all the existing patches that you've created for gcc-4.7.2 to gcc-4.7.3 (not yet tested). So, I was wondering if you'd like me to try to get gcc-4.7.3 or gcc-4.8.0 built against the current poky master branch? I can test ARM Cortex A9, ARM Cortex A8 and Microblaze at my end. Do let me know! Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with applying a patch using default -pnum
On Thursday 07 March 2013 13:12:57 Hans Beckérus wrote:
I have a patch file that needs to be applied to a source tree and the
patch file is copied properly to the ${WORKDIR} directory.
So far so good. But, the problem with this source tree is that it is
not built from the traditional root folder of the repo.
This means I need to change ${S} to point somewhere else. This also
causes the patch system to fail!
I did an override of do_patch() in my .bb and that seems to work, but
I do not like to use overrides unless I really have to.
So basically, is there some way to tell the built-in patch system to
use a different -pnum value?
Yes there is - use the striplevel parameter e.g (from make_3.82.bb):
file://make-savannah-bug30612-handling_of_archives.patch;striplevel=0
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Samba server?
From: Martin Jansa Are you talking about openembedded as openembedded-classic or meta-openembedded? Use samba from meta-openembedded. That's what I tried first. It's not a layer, but a collection of layers, and the layer that contains samba is called meta-oe. So I tried to include meta-openembedded/meta-oe, and it barfed due to the absence of fontcache.bbclass. But fontcache.bbclass is nowhere to be found in meta-openembedded; it's contained in openembedded-core/meta. So I included openembedded-core/meta, and got some other error message containing about a dozen lines of Python script that had raised an exception. I tried including openembedded instead/too, and got other error messages. To someone who understands the shape of the universe, this is probably easy to figure out. I might feel the trunk, or the tail, but I don't know it's an elephant yet. Since samba is a fairly common, standard module, I was hoping someone here had already done this, and could tell me what buttons to push. I've read the scant docs on bitbake, and pretty much the entire Yocto docs and Openembedded docs, and my head is spinning. I don't mind learning some stuff, but if I have to spend six months becoming an expert on something just to get it to work, then this is an economically unviable project for me. Or maybe I should just build the system without samba, run it, manually install samba just like any other user, and then use dd to save the modified image for production use. Does that sound like a good idea? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Samba server?
On Thu, Mar 07, 2013 at 10:22:54AM -0800, Paul D. DeRocco wrote: Or maybe I should just build the system without samba, run it, manually install samba just like any other user, and then use dd to save the modified image for production use. Does that sound like a good idea? No, adding extra layer is pretty basic operation and should be properly documented. Can you send some pointers what have you read about adding a layer and what wasn't easy to understand? -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] PREFERRED_PROVIDER_u-boot problem
Hi, in my BSP machine/conf I have the following: PREFERRED_PROVIDER_virtual/kernel = linux-xlnx PREFERRED_PROVIDER_u-boot = u-boot-xlnx I also have a linux-xlnx.bb and a u-boot-xlnx.bb in meta/mybsp/recipes_kernel and recipes_bsp respectively. When I do 'bitbake virtual/kernel', the correct .bb file is called and linux-xlnx is downloaded. But, for u-boot it does not work? I have to do 'bitbake u-boot-xlnx' to have the correct recipe being called. If I only do 'bitbake u-boot' I seem to get some default. What might I possibly have done wrong? I expected these two to behave exactly the same? Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with applying a patch using default -pnum
Hans,
Are you sure you're seeing the patch system use $WORKDIR instead of $S as
the root for patching? I've had to do a lot of patching in our own layers
recently and I've always seen $S used as the root for the patch. Are you
explicitly setting S = ${WORKDIR}/git? That's what we do for our git
recipes. That's how you get the system to recognize the source somewhere
other than just $WORKDIR.
As for specifying a different -pnum, you absolutely can do that like so:
*SRC_URI += file://my-change.patch;striplevel=X*
X is the pnum that you want. Its default value is 1.
You may also find this page useful -- it contains all sorts of hints for
setting up your recipes in a Yocto-standard way:
https://wiki.yoctoproject.org/wiki/Recipe__Patch_Style_Guide
That's where I learned about striplevel and the preference for it over the
deprecated pnum parameter.
Kind regards,
Jerrod
On Thu, Mar 7, 2013 at 7:33 AM, Hans Beckérus hans.becke...@gmail.comwrote:
On Thu, Mar 7, 2013 at 1:12 PM, Hans Beckérus hans.becke...@gmail.com
wrote:
Hi. More problems ;)
I have a patch file that needs to be applied to a source tree and the
patch file is copied properly to the ${WORKDIR} directory.
So far so good. But, the problem with this source tree is that it is
not built from the traditional root folder of the repo.
This means I need to change ${S} to point somewhere else. This also
causes the patch system to fail!
I did an override of do_patch() in my .bb and that seems to work, but
I do not like to use overrides unless I really have to.
So basically, is there some way to tell the built-in patch system to
use a different -pnum value?
If there is, I could stick with the do_patch() as provided by default.
Hans
Hmm, ok a correction from my side. Forget parts of what I said ;)
The patch system does not seem to use the value of ${S}, it is using
${WORKDIR} as the root for patching, this is also where the patch file
is placed. The problem in my case does not seem to be that is built
from a non-standard path. The reason why it fails seems to be because
the actual source is not in ${WORKDIR}, it is in ${WORKDIR}/git. The
patch file does include git as part of the source path for obvious
reasons. What am I doing wrong? Having actual source code in
${WORKDIR}/git I assume is very common for git based downloads.
Hans
___
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] Problem with applying a patch using default -pnum
On 2013-03-07 8:11, Jerrod Peach wrote:
Hans,
Are you sure you're seeing the patch system use $WORKDIR instead of $S
as the root for patching? I've had to do a lot of patching in our own
layers recently and I've always seen $S used as the root for the
patch. Are you explicitly setting S = ${WORKDIR}/git? That's what
we do for our git recipes. That's how you get the system to recognize
the source somewhere other than just $WORKDIR.
As for specifying a different -pnum, you absolutely can do that like so:
/SRC_URI += file://my-change.patch*;striplevel=X*/
X is the pnum that you want. Its default value is 1.
You may also find this page useful -- it contains all sorts of hints
for setting up your recipes in a Yocto-standard way:
https://wiki.yoctoproject.org/wiki/Recipe__Patch_Style_Guide
That's where I learned about striplevel and the preference for it over
the deprecated pnum parameter.
Kind regards,
Jerrod
Hi Jarod. Thanks, the pointer you gave will most certainly be of great
aid. I will try the striplevel approach
instead of writing my own do_patch() override.
Regarding how certain I am that the root folder is ${WORKDIR} when
patching, not at all ;)
In my do_patch() function is simply did `pwd` and it was not set to ${S}
as I set it to.
That does not mean that the built-in patch system is using ${WORKDIR}, I
am aware of that.
Things here is, even though my patch is placed in ${W} and I set ${S} to
eg. ${W}/git/some/folder,
why would it not work? In another package I set ${S} to ${WORKDIR}/git
and it works
just fine. I can not understand why setting ${S} to something else
breaks the logic?
It's not that bitbake can not find the patch file, it definitely does
that, but the -pnum seems to get
messed up. But maybe that is the whole point of having the striplevel=X
in the first place.
Hans
On Thu, Mar 7, 2013 at 7:33 AM, Hans Beckérus hans.becke...@gmail.com
mailto:hans.becke...@gmail.com wrote:
On Thu, Mar 7, 2013 at 1:12 PM, Hans Beckérus
hans.becke...@gmail.com mailto:hans.becke...@gmail.com wrote:
Hi. More problems ;)
I have a patch file that needs to be applied to a source tree
and the
patch file is copied properly to the ${WORKDIR} directory.
So far so good. But, the problem with this source tree is that it is
not built from the traditional root folder of the repo.
This means I need to change ${S} to point somewhere else. This also
causes the patch system to fail!
I did an override of do_patch() in my .bb and that seems to
work, but
I do not like to use overrides unless I really have to.
So basically, is there some way to tell the built-in patch system to
use a different -pnum value?
If there is, I could stick with the do_patch() as provided by
default.
Hans
Hmm, ok a correction from my side. Forget parts of what I said ;)
The patch system does not seem to use the value of ${S}, it is using
${WORKDIR} as the root for patching, this is also where the patch file
is placed. The problem in my case does not seem to be that is built
from a non-standard path. The reason why it fails seems to be because
the actual source is not in ${WORKDIR}, it is in ${WORKDIR}/git. The
patch file does include git as part of the source path for obvious
reasons. What am I doing wrong? Having actual source code in
${WORKDIR}/git I assume is very common for git based downloads.
Hans
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem with Xserver freezing
Hi Guys, I created a X11 image and I found that the init is freezing. Advice regarding configuring Xorg is very much appreciated. If I remove Xinitialization from init then its properly starting. my board is a specialized version of Nvidia Tegra Harmony board. Current version of pixman: 0.29.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Mar 7 19:36:27 2013 (==) Using system config directory /usr/share/X11/xorg.conf.d Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Cheers, Satya ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with applying a patch using default -pnum
On Thu, Mar 7, 2013 at 2:43 PM, Hans Beckerus hans.becke...@gmail.comwrote:
On 2013-03-07 8:11, Jerrod Peach wrote:
Hans,
Are you sure you're seeing the patch system use $WORKDIR instead of $S
as the root for patching? I've had to do a lot of patching in our own
layers recently and I've always seen $S used as the root for the patch.
Are you explicitly setting S = ${WORKDIR}/git? That's what we do for
our git recipes. That's how you get the system to recognize the source
somewhere other than just $WORKDIR.
As for specifying a different -pnum, you absolutely can do that like so:
*SRC_URI += file://my-change.patch;striplevel=X*
X is the pnum that you want. Its default value is 1.
You may also find this page useful -- it contains all sorts of hints for
setting up your recipes in a Yocto-standard way:
https://wiki.yoctoproject.org/wiki/Recipe__Patch_Style_Guide
That's where I learned about striplevel and the preference for it over
the deprecated pnum parameter.
Kind regards,
Jerrod
Hi Jarod. Thanks, the pointer you gave will most certainly be of great
aid. I will try the striplevel approach
instead of writing my own do_patch() override.
Regarding how certain I am that the root folder is ${WORKDIR} when
patching, not at all ;)
In my do_patch() function is simply did `pwd` and it was not set to ${S}
as I set it to.
That does not mean that the built-in patch system is using ${WORKDIR}, I
am aware of that.
Things here is, even though my patch is placed in ${W} and I set ${S} to
eg. ${W}/git/some/folder,
why would it not work? In another package I set ${S} to ${WORKDIR}/git and
it works
just fine. I can not understand why setting ${S} to something else breaks
the logic?
It's not that bitbake can not find the patch file, it definitely does
that, but the -pnum seems to get
messed up. But maybe that is the whole point of having the striplevel=X in
the first place.
Hans
pnum/striplevel's purpose is to strip off the leading paths from a patch
file. If you're having trouble understanding how that works, this link
might help:
http://drupal.org/patch/apply#comment-239397
Changing $S to a different depth and having do_patch() fail is certainly
expected behavior if you don't change the value of striplevel. Does that
answer your question?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project 1.4 milestone 4 released
Yocto Project 1.4 milestone 4 is ready. Kernel.org mirrors will be present shortly. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The fourth milestone for the upcoming Yocto Project 1.4 release is now available at: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.4-m4/poky-yocto-1.4-m4.tar.bz2 Thanks to everyone for all their hard work. Michael Halstead Yocto Project / System Administrator mich...@yoctoproject.org - yocto-1.4-m4 Errata - Release Name: eclipse-poky-yocto-1.4-m4 Branch: 1.4_M4 Tag: 1.4_M4.final Hash: d18c45e0f5367979f7402380ee123242da2b57d5 md5: f0ba42c65fbb53d456eb4c81a8e20672 eclipse-poky-yocto-1.4-m4.tar.bz2 Download Locations: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.4-m4/eclipse-poky-yocto-1.4-m4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.4-m4/eclipse-poky-yocto-1.4-m4.tar.bz2 Release Name: meta-intel-yocto-1.4-m4 Branch: 1.4_M4 Tag: 1.4_M4.final Hash: 150be7c8fb97ac88737f6017fdf9dd47b273bb3e md5: eae235635e155f544a94cf46d90ed30e meta-intel-yocto-1.4-m4.tar.bz2 Download Locations: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.4-m4/meta-intel-yocto-1.4-m4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.4-m4/meta-intel-yocto-1.4-m4.tar.bz2 Release Name: meta-qt3-yocto-1.4-m4 Branch: 1.4_M4 Tag: 1.4_M4.final Hash: 06e2fe600de962cdba53c23de1207501439a9c9f md5: 504f01a15fd52daffde64561bed6e689 meta-qt3-yocto-1.4-m4.tar.bz2 Download Locations: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.4-m4/meta-qt3-yocto-1.4-m4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.4-m4/meta-qt3-yocto-1.4-m4.tar.bz2 Release Name: poky-yocto-1.4-m4 Branch: 1.4_M4 Tag: 1.4_M4.final Hash: 7d22ef28e64de06b6238d0ef9b664c0bee6efa46 md5: aa9c6703d41087859d38cf9920f47950 poky-yocto-1.4-m4.tar.bz2 Download Locations: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.4-m4/poky-yocto-1.4-m4.tar.bz2 http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.4-m4/poky-yocto-1.4-m4.tar.bz2 - Features - Performance enhancement in places such as the packaging process, pseudo, etc., which leads to more than 10% improvement of the total build time for core-image-sato. The build time for rootfs with sstate cache enabled has also been reduced in half. Various improvements to HOB, bitbake, systemd support, buildhistory tool, yocto-kernel tool, multi-lib, etc. Zypper updater cleanup. New comprehensive git proxy script (oe-git-proxy) with improvements suggested by the community. Regular package updates including gtk+, qemu, pseudo, net-tools, qmmp, perl, etc. and various bug fixes. - Known Issues - Bug 3908: Kernel panic on qemux86-64 when using runqemu kvm and cpu host Bug 3930: [Test Case 146 Failure] Check if AUTOPR could be export/lockdown for package build Bug 3804: connman offline mode doesn't work on qemu images Bug 3921: Hob in Build Appliance doesn't start. Bug 3338: iptables-1.4.15: autoreconf run failed on gmae-toolchain -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJROMTAAAoJEEyK+E/MEkQPv78IANIO3/LF4suz3L3v2ZLZ4XJE 5EVSvmlHeUJGbhJU+mYsgdr/xBiYiKdn+4SPOYaJqzp8zcI/4l3WUBaBrHHK3w5k VDogNdMQpd+hTF5QFL832KPeL27tjbQFbhZpI7/vg4dnQfzGn14YFNKEXG52pmMB hjJf4sGYsuGFZOOk46Po7dZf8hM45dqb9zRGoithyQ6mVbVSb63bOJnOXSgDhwOz b0Jjp4zlgljGN+RWz+DGWGPnRS07xEICkpZrgJedE8A9SDQuORuiBB+rNcsdN+ln ZgkreHuQD3XZR9F/5s+XuO0QqHC3+T+BpKbp6SUaB4spsc6mwZLHSIWH+5S3kKA= =FaOw -END PGP SIGNATURE- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with applying a patch using default -pnum
On 2013-03-07 10:01, Jerrod Peach wrote:
On Thu, Mar 7, 2013 at 2:43 PM, Hans Beckerus hans.becke...@gmail.com
mailto:hans.becke...@gmail.com wrote:
On 2013-03-07 8:11, Jerrod Peach wrote:
Hans,
Are you sure you're seeing the patch system use $WORKDIR instead
of $S as the root for patching? I've had to do a lot of patching
in our own layers recently and I've always seen $S used as the
root for the patch. Are you explicitly setting S =
${WORKDIR}/git? That's what we do for our git recipes. That's
how you get the system to recognize the source somewhere other
than just $WORKDIR.
As for specifying a different -pnum, you absolutely can do that
like so:
/SRC_URI += file://my-change.patch*;striplevel=X*/
X is the pnum that you want. Its default value is 1.
You may also find this page useful -- it contains all sorts of
hints for setting up your recipes in a Yocto-standard way:
https://wiki.yoctoproject.org/wiki/Recipe__Patch_Style_Guide
That's where I learned about striplevel and the preference for it
over the deprecated pnum parameter.
Kind regards,
Jerrod
Hi Jarod. Thanks, the pointer you gave will most certainly be of
great aid. I will try the striplevel approach
instead of writing my own do_patch() override.
Regarding how certain I am that the root folder is ${WORKDIR} when
patching, not at all ;)
In my do_patch() function is simply did `pwd` and it was not set
to ${S} as I set it to.
That does not mean that the built-in patch system is using
${WORKDIR}, I am aware of that.
Things here is, even though my patch is placed in ${W} and I set
${S} to eg. ${W}/git/some/folder,
why would it not work? In another package I set ${S} to
${WORKDIR}/git and it works
just fine. I can not understand why setting ${S} to something else
breaks the logic?
It's not that bitbake can not find the patch file, it definitely
does that, but the -pnum seems to get
messed up. But maybe that is the whole point of having the
striplevel=X in the first place.
Hans
pnum/striplevel's purpose is to strip off the leading paths from a
patch file. If you're having trouble understanding how that works,
this link might help:
http://drupal.org/patch/apply#comment-239397
Changing $S to a different depth and having do_patch() fail is
certainly expected behavior if you don't change the value of
striplevel. Does that answer your question?
Yes, I am fully aware of how -pnum works. My confusion was based on how
bitbake will assume a certain depth and use that as default.
Actually it could have been more clever by doing a comparison between $W
(or patch file location), the patch itself, and $S.
Anyway, you did answer my question. Thanks. I will try the striplevel
tomorrow when I am back at work.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A question on adding a new program to a new meta layer
Hi Bruce,
What do you have in your defconfig ? I'm about to push patches that
will make enabling sched_dealine a KERNEL_FEATURE option, which makes
it even easier to use.
Here is my defconfg
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-kernel/linux/linux/defconfig
I've asked this to Juri, too. So this is for the config for sched_deadline
Every defconfig kernel should compile and work
fine (given HZ=1000, NO_HZ not set and HRTIMERS=y)
And here are the CONFIG that should set (Juri, please let us know if
I miss anything)
--
CONFIG_EXPERIMENTAL = y
CONFIG_CGROUPS = y
CONFIG_CGROUP_SCHED = n
CONFIG_HIGH_RES_TIMERS = y
CONFIG_PREEMPT = y
CONFIG_PREEMPT_RT = y
CONFIG_HZ_1000 = y
# CONFIG_NO_HZ is not set
--
But in the meantime, if you want to enable the support on a yocto BSP,
you can change your defconfig to be sched-deadline.cfg and only
put the kernel options required to enable the feature.
I will pick up yocto-3.8 bb file from master branch and will try
this way shortly.
Regards,
Insop
Cheers,
Bruce
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline
scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A question on adding a new program to a new meta layer
Thanks Juri, I was going to add you to my linux-yocto-3.8 announcement email and due to some last minute debug activities .. it slipped my mind. So I'm using this thread to let you, and anyone else that is interested know that sched_deadline support is available to try out in linux-yocto-3.8. Could you also add me in the announcement list? As I already told to Insop, I don't have any automated test for the patchset, but I usually run different scenarios using basically this two tools (and giving a look at simple cases through kernelshark): 1- schedtool-dl: https://github.com/jlelli/schedtool-dl the idea here is to let a 'yes' run through SCHED_DEADLINE and check through kernelshark that the bandwidth enforcement mechanism works. 2- rt-app: https://github.com/gbagnoli/rt-app with this I usually let some tasksets run for several hours on a 48-cores machine we have in our lab, I can provide the tasksets (json files) and the script to run them. Please let me know how I can help further. This is a good start. I have some old references to tests that I'll dig up as well. You can check this recipes-tool to find out the above programs (configuration and installation) in here, https://github.com/insop/meta-dl/tree/sched-dl-V7/recipes-tools I'm looking to develop some real world examples of the scheduler class in action, since as we've been saying .. getting those examples will both help the approach and perhaps help get it merged into the mainline kernel. I've been looking application descriptions when I was in Ericsson, and provided cases to Thomas and Juri. I am interested in this as well, and include them in easy-to test/validate form. I will also reply to your other mail shortly. Regards, Insop ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A question on adding a new program to a new meta layer
One observation and question:
1. I can build core-image-minimal/sato with meta-dl (with github 3.8
or yocto-3.8 kernel) with yocto on danny-8.0 tag
2. I cannot build a successfully bootable core-image-minimal (with
meta-dl) with yocto on 1.4_M4 tag,
the image was stuck during booting..
My build machine is Ubuntu 12.04 LTS.
Before I debug more, I want to check with you to see if there is any
thing that you can think of.
Since I am planning to move to the yocto's master, so that I can pick
up linux-yocto_3.8.bb.
Thank you,
Insop
On Thu, Mar 7, 2013 at 6:05 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-07 03:26 AM, Insop Song wrote:
Hi Bruce,
One more question on 3.8 kernel.
Is meta/recipes-kernel/linux/linux-yocto_3.8.bb added soon as well in
1.4?
It's in master as of a few days ago. So it's available and
ready for use.
Cheers,
Bruce
I am using 1.4_M4.final now.
Thank you.
Insop
On Wed, Mar 6, 2013 at 9:05 PM, Insop Song insop.s...@gmail.com wrote:
Bruce,
That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)
The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel
2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts
3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)
#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.
I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.
I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.
Regards,
Insop
* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel
#SRCREV =031d31cfaa1e0c00122bf52639e340353d3b8360
SRCREV =${AUTOREV}
-KBRANCH = sched-dl-V7
-SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = sched-dl-V7
+#SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+# file://defconfig
+KBRANCH = standard/edf
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
file://defconfig
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline
scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
Re: [yocto] Samba server?
From: Martin Jansa [mailto:martin.ja...@gmail.com]
No, adding extra layer is pretty basic operation and should
be properly
documented. Can you send some pointers what have you read
about adding a
layer and what wasn't easy to understand?
How to theoretically add a layer was easy enough to understand, but when it
failed to work, I came to a dead end.
I'm trying to make a basic non-GUI image based on the Atom cedartrail-nopvr
machine, plus Samba, so I began with the following items in BBLAYERS:
meta
meta-yocto
meta-yocto-bsp
meta-intel
meta-intel/meta-cedartrail
and I built core-image-base. That worked fine, but of course it had no Samba
in it, nor is Samba anywhere to be found within the Yocto stuff. So I
downloaded meta-openembedded from their GIT server, which I know from my
Gumstix experience contains Samba in its meta-oe layer, added
meta-openembedded/meta-oe to the end of BBLAYERS, and tried bitbaking both
core-image-base and samba. I quickly got the following error:
ERROR: ParseError at
/home/pauld/yocto-atom/poky-danny-8.0/meta-openembedded/meta-oe/recipes-grap
hics/ttf-fonts/ttf.inc:12: Could not inherit file classes/fontcache.bbclass
There is no fontcache.bbclass anywhere within meta-openembedded, or the
Yocto stuff, but looking through their GIT repository I found it exists
within openembedded-core, in the meta layer. So I downloaded that, and added
openembedded-core/meta to BBLAYERS before meta-openembedded/meta-oe and
tried again. It got past the above error, but this time I got the following
shell script error:
ERROR: ExpansionError during parsing
/home/pauld/yocto-atom/poky-danny-8.0/meta-openembedded/meta-oe/recipes-supp
ort/maliit/maliit-framework_git.bb: Failure expanding variable
gtk_immodule_cache_postinst: ExpansionError: Failure expanding variable
gtk_immodule_cache_postinst, expression was if [ x$D != x ]; then
for maj_ver in 2 3; do
if [ -x $D/usr/bin/gtk-query-immodules-$maj_ver.0 ]; then
IMFILES=$(ls $D/usr/lib/gtk-$maj_ver.0/*/immodules/*.so)
${@qemu_run_binary(d, '$D',
'/usr/bin/gtk-query-immodules-$maj_ver.0')} \
$IMFILES $D/etc/gtk-$maj_ver.0/gtk.immodules 2/dev/null
sed -i -e s:$D:: $D/etc/gtk-$maj_ver.0/gtk.immodules
[ $? -ne 0 ] exit 1
fi
done
exit 0
fi
if [ ! -z `which gtk-query-immodules-2.0` ]; then
gtk-query-immodules-2.0 /etc/gtk-2.0/gtk.immodules
fi
if [ ! -z `which gtk-query-immodules-3.0` ]; then
gtk-query-immodules-3.0 /etc/gtk-3.0/gtk.immodules
fi
which triggered exception NameError: name 'qemu_run_binary' is not defined
I'm sure this e-mail mangled the above due to line wrapping, but I doubt
anyone really needs to know what's going on in that shell script, and the
final line is the only meaningful one. I suspect that the meta-oe layer is
dependent on yet another layer that defines this 'qemu_run_binary' function,
and that even though I've got all of openmbedded-core and meta-openembedded
under my poky-danny-8.0 directory, bitbake only parses those parts that are
mentioned in BBLAYERS, relying upon the user to deal with inter-layer
dependencies.
Perhaps I could grep a bazillion files looking for qemu_run_binary, but I'm
worried that I'm wasting my time down a blind alley. Is pulling in somebody
else's layer (in this case an OpenEmbedded layer into a Yocto system)
something that's supposed to work, or does it only work if it's been tried
and debugged by the experts who create these things in the first place?
(And why doesn't Yocto include Samba anyway? It seems more of a common
standard package than a lot of the stuff I see included.)
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Samba server?
On Thu, Mar 07, 2013 at 02:29:08PM -0800, Paul D. DeRocco wrote: From: Martin Jansa [mailto:martin.ja...@gmail.com] No, adding extra layer is pretty basic operation and should be properly documented. Can you send some pointers what have you read about adding a layer and what wasn't easy to understand? How to theoretically add a layer was easy enough to understand, but when it failed to work, I came to a dead end. I'm trying to make a basic non-GUI image based on the Atom cedartrail-nopvr machine, plus Samba, so I began with the following items in BBLAYERS: meta meta-yocto meta-yocto-bsp meta-intel meta-intel/meta-cedartrail and I built core-image-base. That worked fine, but of course it had no Samba in it, nor is Samba anywhere to be found within the Yocto stuff. So I downloaded meta-openembedded from their GIT server, which I know from my Gumstix experience contains Samba in its meta-oe layer, added meta-openembedded/meta-oe to the end of BBLAYERS, and tried bitbaking both core-image-base and samba. I quickly got the following error: ERROR: ParseError at /home/pauld/yocto-atom/poky-danny-8.0/meta-openembedded/meta-oe/recipes-grap hics/ttf-fonts/ttf.inc:12: Could not inherit file classes/fontcache.bbclass From those errors I guess you're trying to add meta-oe from master branch which indeed is not compatible with danny release, use meta-oe from danny branch. (And why doesn't Yocto include Samba anyway? It seems more of a common standard package than a lot of the stuff I see included.) That's why it's called oe-core. uncommon stuff should be moved to more specific layers. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [eclipse-poky][PATCHv3 0/6] Refactorings in org.yocto.sdk.ide plugin
Merged to eclipse-poky master. Thanks for the contribution. Cheers, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Atanas Gegov Sent: Thursday, March 07, 2013 6:09 AM To: yocto@yoctoproject.org Subject: [yocto] [eclipse-poky][PATCHv3 0/6] Refactorings in org.yocto.sdk.ide plugin From: Atanas Gegov atanas.ge...@bmw-carit.de Hi, Currently the org.yocto.sdk.ide plugin has the YoctoSDKEmptyProjectNature and the YoctoSDKProjectNature. The latter is strongly coupled with the Autotools nature since this is by now the only supported build system. It would be nice if it is possible to introduce other Yocto IDE projects,e.g. projects using CMake for building. This patch series does some refactoring in the org.yocto.sdk.ide plugin. This allows a simplified addition of further natures and enables the decoupling between YoctoSDKProjectNature and the Autotools nature. The natures and the utils get their own packages. Some methods and members were also moved to suitable classes. Cheers, Atanas Atanas Gegov (6): Moved YoctoSDK natures to their own package Moved functionality that does not belong to YoctoSDKProjectNature Moved utils to their own package Moved nature-related utils in own class Export the new subpackages of org.yocto.sdk.ide Performed a whitespaces cleanup plugins/org.yocto.sdk.ide/META-INF/MANIFEST.MF |2 + plugins/org.yocto.sdk.ide/plugin.xml |4 +- .../src/org/yocto/sdk/ide/YoctoSDKChecker.java | 12 +- .../yocto/sdk/ide/YoctoSDKEmptyProjectNature.java | 38 - .../org/yocto/sdk/ide/YoctoSDKProjectNature.java | 267 --- .../src/org/yocto/sdk/ide/YoctoSDKUtils.java | 607 .../ide/natures/YoctoSDKEmptyProjectNature.java| 39 + .../yocto/sdk/ide/natures/YoctoSDKNatureUtils.java | 39 + .../sdk/ide/natures/YoctoSDKProjectNature.java | 111 +++ .../ide/preferences/YoctoSDKPreferencePage.java|4 +- .../preferences/YoctoSDKProjectPropertyPage.java |2 +- .../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 743 .../sdk/ide/utils/YoctoSDKUtilsConstants.java | 18 + .../sdk/ide/wizard/NewYoctoCProjectTemplate.java |6 +- 14 files changed, 969 insertions(+), 923 deletions(-) delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKEmptyProjectNature.java delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKProjectNature.java delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKUtils.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKEmptyProjectNature.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKNatureUtils.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKProjectNature.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtilsConstants.java -- 1.7.9.5 ___ 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] A question on adding a new program to a new meta layer
On 13-03-07 4:43 PM, Insop Song wrote:
Hi Bruce,
What do you have in your defconfig ? I'm about to push patches that
will make enabling sched_dealine a KERNEL_FEATURE option, which makes
it even easier to use.
Here is my defconfg
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-kernel/linux/linux/defconfig
I've asked this to Juri, too. So this is for the config for sched_deadline
Every defconfig kernel should compile and work
fine (given HZ=1000, NO_HZ not set and HRTIMERS=y)
And here are the CONFIG that should set (Juri, please let us know if
I miss anything)
--
CONFIG_EXPERIMENTAL = y
CONFIG_CGROUPS = y
CONFIG_CGROUP_SCHED = n
CONFIG_HIGH_RES_TIMERS = y
CONFIG_PREEMPT = y
CONFIG_PREEMPT_RT = y
CONFIG_HZ_1000 = y
So this is all that you should have in your configuration fragment addon.
We are trying to get people to separate BSP configuration from policy
with feature addons being incremental blocks of CONFIG_ items aded
at the end.
There's a base policy in place for every linux-yocto based BSP, all
you need to do is turn on the options that you want for your feature.
That way, as we migrate through kernel versions, tweak performance
options, etc, there is a central policy fragment that is changed and
all BSPs are updated. Versus hunting down hundreds of defconfigs, in
various layers and attempting to get them all synchronized and updated.
For non linux-yocto BSPs, as of 1.4 we can share the out of tree
kernel configuration fragments, and implement a similar policy. If we
are seeking to synchronize efforts, trying to use the configuration
extensions that are available makes a lot of sense to me!
# CONFIG_NO_HZ is not set
--
But in the meantime, if you want to enable the support on a yocto BSP,
you can change your defconfig to be sched-deadline.cfg and only
put the kernel options required to enable the feature.
I will pick up yocto-3.8 bb file from master branch and will try
this way shortly.
Sounds good!
Bruce
Regards,
Insop
Cheers,
Bruce
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline
scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
PARALLEL_MAKE =
BBCLASSEXTEND = native
COMPATIBLE_MACHINE_dl-qemux86 = dl-qemux86
- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += dl-qemux86
BBFILE_PATTERN_dl-qemux86 := ^${LAYERDIR}/
BBFILE_PRIORITY_dl-qemux86 = 6
=
Thank you.
Regards,
Insop
- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
Re: [yocto] A question on adding a new program to a new meta layer
On 13-03-07 4:49 PM, Insop Song wrote: Thanks Juri, I was going to add you to my linux-yocto-3.8 announcement email and due to some last minute debug activities .. it slipped my mind. So I'm using this thread to let you, and anyone else that is interested know that sched_deadline support is available to try out in linux-yocto-3.8. Could you also add me in the announcement list? I can definitely do that. Also if you sign up for the linux-yo...@yoctoproject.org mailing list, that's where announcements and kernel feature discussions happen around linux-yocto. It would be a great place (versus this main yocto mailing list) to talk about sched_deadline in particular. As I already told to Insop, I don't have any automated test for the patchset, but I usually run different scenarios using basically this two tools (and giving a look at simple cases through kernelshark): 1- schedtool-dl: https://github.com/jlelli/schedtool-dl the idea here is to let a 'yes' run through SCHED_DEADLINE and check through kernelshark that the bandwidth enforcement mechanism works. 2- rt-app: https://github.com/gbagnoli/rt-app with this I usually let some tasksets run for several hours on a 48-cores machine we have in our lab, I can provide the tasksets (json files) and the script to run them. Please let me know how I can help further. This is a good start. I have some old references to tests that I'll dig up as well. You can check this recipes-tool to find out the above programs (configuration and installation) in here, https://github.com/insop/meta-dl/tree/sched-dl-V7/recipes-tools I'm looking to develop some real world examples of the scheduler class in action, since as we've been saying .. getting those examples will both help the approach and perhaps help get it merged into the mainline kernel. I've been looking application descriptions when I was in Ericsson, and provided cases to Thomas and Juri. I am interested in this as well, and include them in easy-to test/validate form. Great! Bruce I will also reply to your other mail shortly. Regards, Insop ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] A question on adding a new program to a new meta layer
On 13-03-07 5:02 PM, Insop Song wrote:
One observation and question:
1. I can build core-image-minimal/sato with meta-dl (with github 3.8
or yocto-3.8 kernel) with yocto on danny-8.0 tag
2. I cannot build a successfully bootable core-image-minimal (with
meta-dl) with yocto on 1.4_M4 tag,
the image was stuck during booting..
My build machine is Ubuntu 12.04 LTS.
Before I debug more, I want to check with you to see if there is any
thing that you can think of.
Since I am planning to move to the yocto's master, so that I can pick
up linux-yocto_3.8.bb.
Nothing comes to mind. It all depends on what target you are using, and
if you are using the 'defconfig' that you mentioned earlier. Switching
to the linux-yocto policy and BSP fragments will likely fix your problem.
Bruce
Thank you,
Insop
On Thu, Mar 7, 2013 at 6:05 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-07 03:26 AM, Insop Song wrote:
Hi Bruce,
One more question on 3.8 kernel.
Is meta/recipes-kernel/linux/linux-yocto_3.8.bb added soon as well in
1.4?
It's in master as of a few days ago. So it's available and
ready for use.
Cheers,
Bruce
I am using 1.4_M4.final now.
Thank you.
Insop
On Wed, Mar 6, 2013 at 9:05 PM, Insop Songinsop.s...@gmail.com wrote:
Bruce,
That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)
The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel
2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts
3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)
#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.
I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.
I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.
Regards,
Insop
* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel
#SRCREV =031d31cfaa1e0c00122bf52639e340353d3b8360
SRCREV =${AUTOREV}
-KBRANCH = sched-dl-V7
-SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = sched-dl-V7
+#SRC_URI =
git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+# file://defconfig
+KBRANCH = standard/edf
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
file://defconfig
PV = 3.8
-PR = dl7
+PR = dl
KSRC ?=
S = '${@base_conditional(KSRC, , ${WORKDIR}/git, ${KSRC}, d)}'
Thank you.
Insop
On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-03-05 1:54 AM, Insop Song wrote:
Hi,
I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called meta-dl. I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/
FYI: I've already merged and staged sched_dl in linux-yocto_3.8:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf
I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.
Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.
Cheers,
Bruce
With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.
Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.
- problem: adding a new software into my meta-dl layer
- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do bitbake schedtool-dl -c install it builds and install,
but at i586 location instead of my machine staging rootfs
(dl-qemux86)
- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = schedtool-dl (scheduler test tool) for deadline
scheduler
HOMEPAGE = https://github.com/insop/schedtool-dl;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984
PR = r1
SRC_URI = git://github.com/insop/schedtool-dl.git;protocol=git
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D}
}
Re: [yocto] Problem with applying a patch using default -pnum
On 2013-03-07 8:11, Jerrod Peach wrote:
Hans,
Are you sure you're seeing the patch system use $WORKDIR instead of $S
as the root for patching? I've had to do a lot of patching in our own
layers recently and I've always seen $S used as the root for the
patch. Are you explicitly setting S = ${WORKDIR}/git? That's what
we do for our git recipes. That's how you get the system to recognize
the source somewhere other than just $WORKDIR.
As for specifying a different -pnum, you absolutely can do that like so:
/SRC_URI += file://my-change.patch*;striplevel=X*/
X is the pnum that you want. Its default value is 1.
You may also find this page useful -- it contains all sorts of hints
for setting up your recipes in a Yocto-standard way:
https://wiki.yoctoproject.org/wiki/Recipe__Patch_Style_Guide
That's where I learned about striplevel and the preference for it over
the deprecated pnum parameter.
Kind regards,
Jerrod
Hi Jarod. Thanks, the pointer you gave will most certainly be of great aid. I
will
try the striplevel approach instead of writing my own do_patch() override.
Regarding how certain I am that the root folder is ${WORKDIR} when
patching, not at all ;) In my do_patch() function is simply did `pwd` and it
was
not set to ${S} as I set it to.
That does not mean that the built-in patch system is using ${WORKDIR}, I am
aware of that.
Things here is, even though my patch is placed in ${W} and I set ${S} to eg.
${W}/git/some/folder, why would it not work? In another package I set ${S}
to ${WORKDIR}/git and it works just fine. I can not understand why setting
${S} to something else breaks the logic?
It's not that bitbake can not find the patch file, it definitely does that,
but the
-pnum seems to get messed up. But maybe that is the whole point of having
the striplevel=X in the first place.
Hans
On Thu, Mar 7, 2013 at 7:33 AM, Hans Beck?rus hans.becke...@gmail.com
mailto:hans.becke...@gmail.com wrote:
On Thu, Mar 7, 2013 at 1:12 PM, Hans Beck?rus
hans.becke...@gmail.com mailto:hans.becke...@gmail.com
wrote:
Hi. More problems ;)
I have a patch file that needs to be applied to a source tree
and the
patch file is copied properly to the ${WORKDIR} directory.
So far so good. But, the problem with this source tree is that it is
not built from the traditional root folder of the repo.
This means I need to change ${S} to point somewhere else. This also
causes the patch system to fail!
I did an override of do_patch() in my .bb and that seems to
work, but
I do not like to use overrides unless I really have to.
So basically, is there some way to tell the built-in patch system to
use a different -pnum value?
If there is, I could stick with the do_patch() as provided by
default.
Hans
Hmm, ok a correction from my side. Forget parts of what I said ;)
The patch system does not seem to use the value of ${S}, it is using
${WORKDIR} as the root for patching, this is also where the patch file
is placed. The problem in my case does not seem to be that is built
from a non-standard path. The reason why it fails seems to be because
the actual source is not in ${WORKDIR}, it is in ${WORKDIR}/git. The
patch file does include git as part of the source path for obvious
reasons. What am I doing wrong? Having actual source code in
${WORKDIR}/git I assume is very common for git based downloads.
Hans
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
I also found another useful patch param called patchdir that sets the directory
from which the patch is applied. This is useful when ${S} is set to a directory
deeper than you want to patch from but don't want to mess with setting ${S}. I
needed it to apply a patch to wpa_supplicant's src directory.
Ex.
file://gpio-sysfs-power-onoff-change.patch;patchdir=${WORKDIR}/wpa_supplicant-${PV}
Daniel Lazzari Jr.
Firmware Engineer
dlazz...@leapfrog.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
