Re: [yocto] Yocto-custom kernel build issue

2015-02-10 Thread Raghavendra Kakarla 
Yes I extracted the files on to the SD card.

I have one issue now.

I want to build some packages from openWRT which are not in YOCTO in yocto 
build system.

For this I download the package tar files from openwrt wrote the recipe for 
building this tar files. Building the tar files is completed without any errors 
but when installing this package in the image it give some error like following.
ERROR: hostapd not found in the base feeds (dhruwa_ioe mips32r2el mips32el 
mipsel noarch any all). 

Could you plese help in resolving this isssue.

Thanks and Regards,
Raghavendra.

- Original Message -
From: "Paul Eggleton" 
To: "Raghavendra Kakarla" , 
yocto@yoctoproject.org
Sent: Tuesday, February 10, 2015 7:06:37 PM
Subject: Re: [yocto] Yocto-custom kernel build issue

Please keep replies on the mailing list, thanks.

Is this perhaps because you extracted the files onto an SD card / other storage 
device as a non-root user?

Cheers,
Paul

On Tuesday 10 February 2015 17:55:25 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
> 
> Thank you for your response.
> 
> It is the rootfs permissions issue.
> 
> I give the "chown -R root rfs" to my rfs then it is working.
> 
> Thanks and Regards,
> 
> Raghavendra.
> 
> - Original Message -
> From: "Paul Eggleton" 
> To: "Raghavendra Kakarla" 
> Cc: yocto@yoctoproject.org
> Sent: Tuesday, February 10, 2015 4:30:19 PM
> Subject: Re: [yocto] Yocto-custom kernel build issue
> 
> On Tuesday 10 February 2015 13:47:45 Raghavendra Kakarla wrote:
> > I am built the yocto for my custom machine. After booting a login prompt
> > was came. For that I tried the "root" as user name but it did not take
> > it.
> > 
> > Could please tell me where i can get the login and password details for
> > yocto rootfs.
> 
> The default is root with no password. If that doesn't work, do you have
> "debug-tweaks" in your EXTRA_IMAGE_FEATURES? It should be there by default.
> 
> Cheers,
> Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issues with vardeps

2015-02-10 Thread Andrei Gherzan 
I encounter issues when using vardeps on do_install.

I have a recipe with a do_install function and want to do stuff inside
based on a specific DISTRO_FEATURE.

<-->if
${@bb.utils.contains('DISTRO_FEATURES','my-production','true','false',d)};
then
...
<-->else
...
<-->fi

I have a distro file where I inject a specific VARIABLE in the
DISTRO_FEATURES:

BUILD_TYPE ?= "production"
DISTRO_FEATURES_append = " my-${BUILD_TYPE}"

In order to force the dependency of do_install on DISTRO_FEATURES, I use:
do_install[vardeps] += "DISTRO_FEATURES"

For whatever reason this doesn't work as expected. To be more specifically,
it works for 2-3 changes of BUILD_TYPE (in local.conf) and then it just
ignores the BUILD_TYPE changes. I checked the dumpsig and after 2-3 changes
of BUILD_TYPE the hash of the last sig file doesn't change anymore even
though DISTRO_FEATURES is there.

http://pastebin.com/8AFxb4FZ

Any idea why do I get this behavior? Is this a known issue or do I miss
something? What I want to accomplish is to force do_install every-time
DISTRO_FEATURES changes.

-- 
*Andrei Gherzan*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OpenEmbedded Developer America's Meeting

2015-02-10 Thread akuster 



On 02/10/2015 12:47 PM, Denys Dmytriyenko wrote:

On Tue, Feb 10, 2015 at 03:27:23PM -0500, Philip Balister wrote:

We've scheduled a meeting in San Jose at a Monte Vista facility for


Correction, it's MontaVista with an 'a':
http://en.wikipedia.org/wiki/MontaVista

Do you have an address of said facility?



 2315 North 1st Street, San Jose, CA 95131

 In the Farm House out back. Behind the two high-rise buildings.

- Armin


March 27-28. This is after ELC (also in San Jose). There is a Yocto
Project developer Day the day after ELC.

I've made a page on the wiki to start collecting information:

http://openembedded.org/wiki/OEDAM_2015

To get an idea of what we cover, see the page from the prior year:

http://openembedded.org/wiki/OEDAM_2014

I apologize for the late notice. There were issues that led to a delay
with dates due to the YP Dev day.

Philip
--
___
Openembedded-members mailing list
openembedded-memb...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-members

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

[yocto] [meta-raspberrypi][PATCH 1/1] layer.conf: set layer depends

2015-02-10 Thread Petter Mabäcker 
Ensure that build fails in a informative way if not all layer
requirements are fulfilled.

To disable strict layer depend set 'LAYERDEPENDS_raspberrypi = ""'
in local.conf.

Also set a high layer prio to ensure that meta-raspberrypi addons
are always prioritized above the depended layers.

[Feature #46]

Change-Id: I8df772a59975ae379c3a1e93e2770e83be752bfd
Signed-off-by: Petter Mabäcker 
---
 README  | 4 
 conf/layer.conf | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/README b/README
index bb2f4be..3dad1ea 100644
--- a/README
+++ b/README
@@ -143,6 +143,10 @@ See: http://wayland.freedesktop.org/raspberrypi.html
 
 2.H. Images
 ===
+Note: 'rpi-hwup-image' and 'rpi-basic-image' can be build without
+  meta-multimedia. Set 'LAYERDEPENDS_raspberrypi = ""' in local.conf
+  to enable build without 'meta-multimedia'.
+
 * rpi-hwup-image
 Hardware up image
 * rpi-basic-image
diff --git a/conf/layer.conf b/conf/layer.conf
index 7bffd4b..b5ab695 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -7,7 +7,8 @@ BBFILES += "${LAYERDIR}/recipes*/*/*.bb \
 
 BBFILE_COLLECTIONS += "raspberrypi"
 BBFILE_PATTERN_raspberrypi := "^${LAYERDIR}/"
-BBFILE_PRIORITY_raspberrypi = "6"
+BBFILE_PRIORITY_raspberrypi = "9"
+LAYERDEPENDS_raspberrypi = "multimedia-layer"
 
 # Additional license directories.
 LICENSE_PATH += "${LAYERDIR}/files/custom-licenses"
-- 
1.9.1

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

[yocto] [meta-raspberrypi][PATCH 0/1] layer.conf: set layer depends

2015-02-10 Thread Petter Mabäcker 
The following changes since commit b99a09b25757ea2afe15fcf31323420edca1137d:

  Merge "devicetree: Add support for DT overlays with RPi bootloader" 
(2015-02-07 22:14:22 +0100)

are available in the git repository at:


  git://git.yoctoproject.org/poky-contrib petmab/rpi_redmine_46
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=petmab/rpi_redmine_46

Petter Mabäcker (1):
  layer.conf: set layer depends

 README  | 4 
 conf/layer.conf | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
1.9.1

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

Re: [yocto] OpenEmbedded Developer America's Meeting

2015-02-10 Thread Denys Dmytriyenko 
On Tue, Feb 10, 2015 at 03:27:23PM -0500, Philip Balister wrote:
> We've scheduled a meeting in San Jose at a Monte Vista facility for

Correction, it's MontaVista with an 'a':
http://en.wikipedia.org/wiki/MontaVista

Do you have an address of said facility?


> March 27-28. This is after ELC (also in San Jose). There is a Yocto
> Project developer Day the day after ELC.
> 
> I've made a page on the wiki to start collecting information:
> 
> http://openembedded.org/wiki/OEDAM_2015
> 
> To get an idea of what we cover, see the page from the prior year:
> 
> http://openembedded.org/wiki/OEDAM_2014
> 
> I apologize for the late notice. There were issues that led to a delay
> with dates due to the YP Dev day.
> 
> Philip
> -- 
> ___
> Openembedded-members mailing list
> openembedded-memb...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-members
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OpenEmbedded Developer America's Meeting

2015-02-10 Thread Philip Balister 
We've scheduled a meeting in San Jose at a Monte Vista facility for
March 27-28. This is after ELC (also in San Jose). There is a Yocto
Project developer Day the day after ELC.

I've made a page on the wiki to start collecting information:

http://openembedded.org/wiki/OEDAM_2015

To get an idea of what we cover, see the page from the prior year:

http://openembedded.org/wiki/OEDAM_2014

I apologize for the late notice. There were issues that led to a delay
with dates due to the YP Dev day.

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

Re: [yocto] [meta-freescale] tmp/work-shared and sstate

2015-02-10 Thread Gary Thomas 

On 2015-02-10 11:13, Christopher Larson wrote:


On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas mailto:g...@mlbassoc.com>> wrote:

If I run a build where the kernel package is brought in via
sstate, tmp/work-shared (in particular the kernel-source tree)
is not populated.  This will break at least these recipes:
   meta-fsl-arm/recipes-__multimedia/gstreamer/gst-fsl-__plugin_4.0.2.bb 

   meta-fsl-arm/recipes-__multimedia/alsa/fsl-alsa-__plugins_1.0.25.bb 


These programs reference the kernel includes directly for some
ARM/i.MX specific headers (e.g. ).  These headers
are not part of the mainline kernel which is used to create the
kernel headers that populates tmp/sysroots, so the build fails.
Note: I'm not sure of the mechanism that lets these programs
peek into the kernel build (I looked at them but nothing jumped
out), but they do build find if the kernel is actually built
and not just brought in by sstate.

Is this an error & if so, which recipe is at fault?  The FSL
recipes, or the new kernel build/classes?


Per commit 46cdaf1c7bc597735d926af6a46f9483f7e57ce5 (oe-core 
6a1ff0e7eacef595738f2fed086986fd622ec32a), you need to add this if you depend 
on the sources:

 do_configure[depends] += "virtual/kernel:do_shared_workdir"
--


Thanks, I'm checking now to see if this fixes the problem.

One thing I noted is I added that line to the two recipes in
question.  When I [re]built my target image with these changes
in a tree that I had just built using only sstate, it kicked
off a ton of tasks (~6000!), and it seems that it's now rebuilding
everything from scratch, not just unpacking the kernel.  Once this
finishes, I'll try another rebuild from sstate to see how that works,
but it sure looks like it's doing a lot more than necessary.

Is this to be expected?


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [meta-freescale] tmp/work-shared and sstate

2015-02-10 Thread Christopher Larson 
On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas  wrote:

> If I run a build where the kernel package is brought in via
> sstate, tmp/work-shared (in particular the kernel-source tree)
> is not populated.  This will break at least these recipes:
>   meta-fsl-arm/recipes-multimedia/gstreamer/gst-fsl-plugin_4.0.2.bb
>   meta-fsl-arm/recipes-multimedia/alsa/fsl-alsa-plugins_1.0.25.bb
>
> These programs reference the kernel includes directly for some
> ARM/i.MX specific headers (e.g. ).  These headers
> are not part of the mainline kernel which is used to create the
> kernel headers that populates tmp/sysroots, so the build fails.
> Note: I'm not sure of the mechanism that lets these programs
> peek into the kernel build (I looked at them but nothing jumped
> out), but they do build find if the kernel is actually built
> and not just brought in by sstate.
>
> Is this an error & if so, which recipe is at fault?  The FSL
> recipes, or the new kernel build/classes?
>

Per commit 46cdaf1c7bc597735d926af6a46f9483f7e57ce5
(oe-core 6a1ff0e7eacef595738f2fed086986fd622ec32a), you need to add this if
you depend on the sources:

do_configure[depends] += "virtual/kernel:do_shared_workdir"
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][ 0/4] More whack-a-mole with version numbers.

2015-02-10 Thread Philip Tricca 
Forgot to copy the maintainer ... again :)

On 01/28/2015 10:36 AM, Philip Tricca wrote:
> This is another round of renaming the meta-selinux bbappends to use
> wild cards. The three recipes renamed here had no patches to port.
> They're basically 3-4 line recipes that enable SELinux or add a 
> config file. Per previous guidance I've removed PRs so hopefully
> this is still the right thing to do.
> 
> One oddity here is the change made to the ustr recipe. It was using
> a variable I've never seen before and failing to fetch the SRC_URI.
> I think this variable was a typo and after changing ${BPV} -> ${PV}
> the expected behavior was restored.
> 
> Philip Tricca (4):
>   sysklogd: Use wildcard for version and remove PR.
>   dhcp: Use wildcard for version number.
>   coreutils: Use wildcard for version and remove PR.
>   ustr: Fix use of bad variable in SRC_URI.
> 
>  recipes-connectivity/dhcp/dhcp_%.bbappend   |3 +++
>  recipes-connectivity/dhcp/dhcp_4.3.0.bbappend   |3 ---
>  recipes-core/coreutils/coreutils_%.bbappend |1 +
>  recipes-core/coreutils/coreutils_8.22.bbappend  |3 ---
>  recipes-extended/sysklogd/sysklogd_%.bbappend   |1 +
>  recipes-extended/sysklogd/sysklogd_1.5.bbappend |3 ---
>  recipes-extended/ustr/ustr_1.0.4.bb |2 +-
>  7 files changed, 6 insertions(+), 10 deletions(-)
>  create mode 100644 recipes-connectivity/dhcp/dhcp_%.bbappend
>  delete mode 100644 recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
>  create mode 100644 recipes-core/coreutils/coreutils_%.bbappend
>  delete mode 100644 recipes-core/coreutils/coreutils_8.22.bbappend
>  create mode 100644 recipes-extended/sysklogd/sysklogd_%.bbappend
>  delete mode 100644 recipes-extended/sysklogd/sysklogd_1.5.bbappend
> 

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

[yocto] tmp/work-shared and sstate

2015-02-10 Thread Gary Thomas 

If I run a build where the kernel package is brought in via
sstate, tmp/work-shared (in particular the kernel-source tree)
is not populated.  This will break at least these recipes:
  meta-fsl-arm/recipes-multimedia/gstreamer/gst-fsl-plugin_4.0.2.bb
  meta-fsl-arm/recipes-multimedia/alsa/fsl-alsa-plugins_1.0.25.bb

These programs reference the kernel includes directly for some
ARM/i.MX specific headers (e.g. ).  These headers
are not part of the mainline kernel which is used to create the
kernel headers that populates tmp/sysroots, so the build fails.
Note: I'm not sure of the mechanism that lets these programs
peek into the kernel build (I looked at them but nothing jumped
out), but they do build find if the kernel is actually built
and not just brought in by sstate.

Is this an error & if so, which recipe is at fault?  The FSL
recipes, or the new kernel build/classes?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, Feb. 10, 2015 8:00 AM US Pacific Time

2015-02-10 Thread Jolley, Stephen K 
Attendees: Armin, Saul, Paul, Stephen, Michael, Richard, Denys, Ross, Joe, 
Bruce, Cristian,



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.8_Status

https://wiki.yoctoproject.org/wiki/Yocto_1.8_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_1.8_Features

YP 1.8 M2 - Out of QA, should release later this week.

YP 1.8 M3 - Enhancement Cut off is targeted for 2/18.  Driving review of 
enhancement.

YP 1.7.2 - Collecting patches, will do a build today and decide if it ready for 
QA.

YP 1.6.3 - Collecting patches, no date for cut off yet.

* SWAT team rotation: Cristian -> Saul/Randy

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

* Opens - 10 min

Richard - We have a performance regression adding about 10 minutes to the build 
time a few weeks ago.  We found part of the problem in lib_tools and fixed it 
so now we are about 3-4 minutes longer on build time.  I also found that 
lsb_release will give interesting input to our oe/lib checking code.

* Team Sharing - 10 min

Michael - Main AutoBuilder will be moving to a new URL most likely today.




Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

Re: [yocto] Yocto Realtime tests on beaglebone black

2015-02-10 Thread Stephen Flowers 
Sorry, no I have not run cyclictest yet.  The results are latencies 
measured via gpio toggles from running the code posted previously.


Steve

On 10/02/2015 14:40, Bruce Ashfield wrote:

On 15-02-10 09:39 AM, Stephen Flowers wrote:


Thanks for your input.  Here are results of 1000 samples over a 10
second period:


To be clear ? Is that the cyclictest run that I was asking
about ?

If it is, what parameters did you use for the run ? It makes a
huge difference in the results from the test.

Bruce



Interrupt response (microseconds)
standard: min: 81, max:118, average: 84
rt: min: 224, max: 289, average: 231

Will share the .config later once I get on that machine.

Steve


On 10/02/2015 14:16, Bruce Ashfield wrote:

On 15-02-10 08:06 AM, Stephen Flowers wrote:

Hi All,

I have built the realtime kernel using Yocto and deployed on the
beaglebone black (specifically core-image-rt-sdk).  I have written a
program to test the timer latency and interrupt latency of userspace
applications.  For this I'm using a simple timerfd to generate a
periodic 10ms gpio toggle which itself acts as a gpio interrupt on
another gpio pin.
I find the latency is much worse on the preempt_rt kernel than the
standard one.  RT kernel gives around 220us average with the standard
kernel about 80us.  Testing with Xenomai gives about 60us. The 
response

times are measured with an external logic analyser, and taken with no
other load on the system.  Kernel version is 3.14.

The difference between standard and RT kernel configs:
Preemption model: desktop vs. realtime kernel
Timer: 100Hz vs 1000Hz
High resolution timers disabled


Can you share the full .config for both configurations ? That should
shed a bit more light on what might be misconfigured.

I haven't run tests on the beaglebone black myself, but on similar
ARM boards, performance has been as expected.

You are talking about average latency above, what about the max
latency ? We expect that the preempt-rt kernel will have a higher
minimum, and often average latency .. but will be significantly
better in maximum latency.

It would also be useful to grab cyclictest results for the standard
and preempt-rt kernel as a baseline performance measure.

Bruce



I'm having a hard time figuring out why the RT kernel gives worse
latency.  Anyone have any insight into this?
Included the source code below.

Thanks & Regards,
Steve

#include
#include
#include
#include 
#include 
#include 
#include 
#include 
#include "poll.h"
#include "fcntl.h"
#include "string.h"
#include "errno.h"
#include 

#define TIMER_OUT_PATH "/sys/class/gpio/gpio47"
#define LED_OUT_PATH "/sys/class/gpio/gpio26"
#define IRQ_IN_PATH "/sys/class/gpio/gpio46"

static int timer_toggle = 0;
static int output_toggle = 0;

void stack_prefault(void)
{
 unsigned char dummy[8192];
 memset(dummy, 0, 8192);
}


int main(int argc, char* argv[])
{
struct itimerspec itv;
unsigned long long timer_increment = 0;

clock_t prevClock;
int sigCnt = 0;
struct sigaction sa;
struct sched_param sp;

struct pollfd fdset[2];
int fd_in;
int action;
int fd_led;
int fd_timer_out;
int fd_timer_in;

char buf[2];
int len;

// setup gpio
if(system("echo 46 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 46");

if(system("echo 47 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 47");

if(system("echo 26 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 26");

// timer out
if(system("echo out > /sys/class/gpio/gpio47/direction") == -1)
 perror("unable to set 47 to output");

 // led out
 if(system("echo out > /sys/class/gpio/gpio26/direction") == -1)
 perror("unable to set 26 to output");

 // irq in
 if(system("echo in > /sys/class/gpio/gpio46/direction") == -1)
 perror("unable to set 46 to input");

 if(system("echo both > /sys/class/gpio/gpio46/edge") == -1)
 perror("unable to set 46 edge");

 // set scheduling parameters
 sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
 if(sched_setscheduler(0, SCHED_FIFO, &sp) == -1)
 {
 perror("setscheduler");
 exit(-1);
 }

 // lock memory
 if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1)
 perror("mlockall");

 stack_prefault();

// Set up timer
 fd_timer_in = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
 printf("fd_timer:%d\n",fd_timer_in);

 if(fd_timer_in < 0)
 {
 perror("timerfd_create()");
 }

itv.it_value.tv_sec = 0;
itv.it_value.tv_nsec = 1000;
itv.it_interval.tv_sec = 0;
itv.it_interval.tv_nsec = 1000;
if(-1 == timerfd_settime(fd_timer_in, 0, &itv, NULL))
{
perror("settime()");
}

// setup file descriptor for poll()
fd_in = open(IRQ_IN_PATH "/value", O_RDONLY | O_NONBLOCK);
printf("fd irq input:%d\n",fd_in);

if(fd_in < 0)
{

Re: [yocto] Yocto Realtime tests on beaglebone black

2015-02-10 Thread Bruce Ashfield 

On 15-02-10 09:39 AM, Stephen Flowers wrote:


Thanks for your input.  Here are results of 1000 samples over a 10
second period:


To be clear ? Is that the cyclictest run that I was asking
about ?

If it is, what parameters did you use for the run ? It makes a
huge difference in the results from the test.

Bruce



Interrupt response (microseconds)
standard: min: 81, max:118, average: 84
rt: min: 224, max: 289, average: 231

Will share the .config later once I get on that machine.

Steve


On 10/02/2015 14:16, Bruce Ashfield wrote:

On 15-02-10 08:06 AM, Stephen Flowers wrote:

Hi All,

I have built the realtime kernel using Yocto and deployed on the
beaglebone black (specifically core-image-rt-sdk).  I have written a
program to test the timer latency and interrupt latency of userspace
applications.  For this I'm using a simple timerfd to generate a
periodic 10ms gpio toggle which itself acts as a gpio interrupt on
another gpio pin.
I find the latency is much worse on the preempt_rt kernel than the
standard one.  RT kernel gives around 220us average with the standard
kernel about 80us.  Testing with Xenomai gives about 60us. The response
times are measured with an external logic analyser, and taken with no
other load on the system.  Kernel version is 3.14.

The difference between standard and RT kernel configs:
Preemption model: desktop vs. realtime kernel
Timer: 100Hz vs 1000Hz
High resolution timers disabled


Can you share the full .config for both configurations ? That should
shed a bit more light on what might be misconfigured.

I haven't run tests on the beaglebone black myself, but on similar
ARM boards, performance has been as expected.

You are talking about average latency above, what about the max
latency ? We expect that the preempt-rt kernel will have a higher
minimum, and often average latency .. but will be significantly
better in maximum latency.

It would also be useful to grab cyclictest results for the standard
and preempt-rt kernel as a baseline performance measure.

Bruce



I'm having a hard time figuring out why the RT kernel gives worse
latency.  Anyone have any insight into this?
Included the source code below.

Thanks & Regards,
Steve

#include
#include
#include
#include 
#include 
#include 
#include 
#include 
#include "poll.h"
#include "fcntl.h"
#include "string.h"
#include "errno.h"
#include 

#define TIMER_OUT_PATH "/sys/class/gpio/gpio47"
#define LED_OUT_PATH "/sys/class/gpio/gpio26"
#define IRQ_IN_PATH "/sys/class/gpio/gpio46"

static int timer_toggle = 0;
static int output_toggle = 0;

void stack_prefault(void)
{
 unsigned char dummy[8192];
 memset(dummy, 0, 8192);
}


int main(int argc, char* argv[])
{
struct itimerspec itv;
unsigned long long timer_increment = 0;

clock_t prevClock;
int sigCnt = 0;
struct sigaction sa;
struct sched_param sp;

struct pollfd fdset[2];
int fd_in;
int action;
int fd_led;
int fd_timer_out;
int fd_timer_in;

char buf[2];
int len;

// setup gpio
if(system("echo 46 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 46");

if(system("echo 47 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 47");

if(system("echo 26 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 26");

// timer out
if(system("echo out > /sys/class/gpio/gpio47/direction") == -1)
 perror("unable to set 47 to output");

 // led out
 if(system("echo out > /sys/class/gpio/gpio26/direction") == -1)
 perror("unable to set 26 to output");

 // irq in
 if(system("echo in > /sys/class/gpio/gpio46/direction") == -1)
 perror("unable to set 46 to input");

 if(system("echo both > /sys/class/gpio/gpio46/edge") == -1)
 perror("unable to set 46 edge");

 // set scheduling parameters
 sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
 if(sched_setscheduler(0, SCHED_FIFO, &sp) == -1)
 {
 perror("setscheduler");
 exit(-1);
 }

 // lock memory
 if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1)
 perror("mlockall");

 stack_prefault();

// Set up timer
 fd_timer_in = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
 printf("fd_timer:%d\n",fd_timer_in);

 if(fd_timer_in < 0)
 {
 perror("timerfd_create()");
 }

itv.it_value.tv_sec = 0;
itv.it_value.tv_nsec = 1000;
itv.it_interval.tv_sec = 0;
itv.it_interval.tv_nsec = 1000;
if(-1 == timerfd_settime(fd_timer_in, 0, &itv, NULL))
{
perror("settime()");
}

// setup file descriptor for poll()
fd_in = open(IRQ_IN_PATH "/value", O_RDONLY | O_NONBLOCK);
printf("fd irq input:%d\n",fd_in);

if(fd_in < 0)
{
perror("file open problem");
exit(0);
}

while(1)
{
 memset((void*)fdset, 0, sizeof(fdset));
 fdset[0].fd = fd_in;
 fdset[0].events = POLLPRI |

Re: [yocto] Yocto Realtime tests on beaglebone black

2015-02-10 Thread Stephen Flowers 


Thanks for your input.  Here are results of 1000 samples over a 10 
second period:


Interrupt response (microseconds)
standard: min: 81, max:118, average: 84
rt: min: 224, max: 289, average: 231

Will share the .config later once I get on that machine.

Steve


On 10/02/2015 14:16, Bruce Ashfield wrote:

On 15-02-10 08:06 AM, Stephen Flowers wrote:

Hi All,

I have built the realtime kernel using Yocto and deployed on the
beaglebone black (specifically core-image-rt-sdk).  I have written a
program to test the timer latency and interrupt latency of userspace
applications.  For this I'm using a simple timerfd to generate a
periodic 10ms gpio toggle which itself acts as a gpio interrupt on
another gpio pin.
I find the latency is much worse on the preempt_rt kernel than the
standard one.  RT kernel gives around 220us average with the standard
kernel about 80us.  Testing with Xenomai gives about 60us. The response
times are measured with an external logic analyser, and taken with no
other load on the system.  Kernel version is 3.14.

The difference between standard and RT kernel configs:
Preemption model: desktop vs. realtime kernel
Timer: 100Hz vs 1000Hz
High resolution timers disabled


Can you share the full .config for both configurations ? That should
shed a bit more light on what might be misconfigured.

I haven't run tests on the beaglebone black myself, but on similar
ARM boards, performance has been as expected.

You are talking about average latency above, what about the max
latency ? We expect that the preempt-rt kernel will have a higher
minimum, and often average latency .. but will be significantly
better in maximum latency.

It would also be useful to grab cyclictest results for the standard
and preempt-rt kernel as a baseline performance measure.

Bruce



I'm having a hard time figuring out why the RT kernel gives worse
latency.  Anyone have any insight into this?
Included the source code below.

Thanks & Regards,
Steve

#include
#include
#include
#include 
#include 
#include 
#include 
#include 
#include "poll.h"
#include "fcntl.h"
#include "string.h"
#include "errno.h"
#include 

#define TIMER_OUT_PATH "/sys/class/gpio/gpio47"
#define LED_OUT_PATH "/sys/class/gpio/gpio26"
#define IRQ_IN_PATH "/sys/class/gpio/gpio46"

static int timer_toggle = 0;
static int output_toggle = 0;

void stack_prefault(void)
{
 unsigned char dummy[8192];
 memset(dummy, 0, 8192);
}


int main(int argc, char* argv[])
{
struct itimerspec itv;
unsigned long long timer_increment = 0;

clock_t prevClock;
int sigCnt = 0;
struct sigaction sa;
struct sched_param sp;

struct pollfd fdset[2];
int fd_in;
int action;
int fd_led;
int fd_timer_out;
int fd_timer_in;

char buf[2];
int len;

// setup gpio
if(system("echo 46 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 46");

if(system("echo 47 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 47");

if(system("echo 26 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 26");

// timer out
if(system("echo out > /sys/class/gpio/gpio47/direction") == -1)
 perror("unable to set 47 to output");

 // led out
 if(system("echo out > /sys/class/gpio/gpio26/direction") == -1)
 perror("unable to set 26 to output");

 // irq in
 if(system("echo in > /sys/class/gpio/gpio46/direction") == -1)
 perror("unable to set 46 to input");

 if(system("echo both > /sys/class/gpio/gpio46/edge") == -1)
 perror("unable to set 46 edge");

 // set scheduling parameters
 sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
 if(sched_setscheduler(0, SCHED_FIFO, &sp) == -1)
 {
 perror("setscheduler");
 exit(-1);
 }

 // lock memory
 if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1)
 perror("mlockall");

 stack_prefault();

// Set up timer
 fd_timer_in = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
 printf("fd_timer:%d\n",fd_timer_in);

 if(fd_timer_in < 0)
 {
 perror("timerfd_create()");
 }

itv.it_value.tv_sec = 0;
itv.it_value.tv_nsec = 1000;
itv.it_interval.tv_sec = 0;
itv.it_interval.tv_nsec = 1000;
if(-1 == timerfd_settime(fd_timer_in, 0, &itv, NULL))
{
perror("settime()");
}

// setup file descriptor for poll()
fd_in = open(IRQ_IN_PATH "/value", O_RDONLY | O_NONBLOCK);
printf("fd irq input:%d\n",fd_in);

if(fd_in < 0)
{
perror("file open problem");
exit(0);
}

while(1)
{
 memset((void*)fdset, 0, sizeof(fdset));
 fdset[0].fd = fd_in;
 fdset[0].events = POLLPRI | POLLERR;
 fdset[0].revents = 0;

 fdset[1].fd = fd_timer_in;
 fdset[1].events = POLLIN | POLLERR;
 fdset[1].revents = 0;
 action = poll(fdset, 2, -1);

 if(action < 0)
 {

[yocto] [error-report-web] New errors-report-web

2015-02-10 Thread Michael Wood 

Hi,

I've updated the errors.yoctoproject.org site with the latest version of 
error-report-web [1] that myself and Belén have been working on.


error-report-web is a project to provide a web service that can be used 
to collect and display build error reports. Error report generation can 
be enabled in your build's local.conf [2]


Here are some of the highlights for the latest version:

- Option to have a JSON response on error report submission
- Optional "Special submitter" allowing an extra tab in the UI for 
quick access to a defined submitter (e.g "autobuilder")

- Filtering and ordering on columns
- Searching improved to allow search of the contents of error 
reports and other useful fields

- Improved page loading speed
- Non blocking graph generation
- Unit tests
- Update to Django 1.7
- Add support for Django migrations
- View errors by build
- Many UI tweaks
- Better error handling
- Simpler url structure

Thanks,

Michael

[1] http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/
[2] 
http://www.yoctoproject.org/docs/1.7.1/dev-manual/dev-manual.html#using-the-error-reporting-tool



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

Re: [yocto] Yocto Realtime tests on beaglebone black

2015-02-10 Thread Bruce Ashfield 

On 15-02-10 08:06 AM, Stephen Flowers wrote:

Hi All,

I have built the realtime kernel using Yocto and deployed on the
beaglebone black (specifically core-image-rt-sdk).  I have written a
program to test the timer latency and interrupt latency of userspace
applications.  For this I'm using a simple timerfd to generate a
periodic 10ms gpio toggle which itself acts as a gpio interrupt on
another gpio pin.
I find the latency is much worse on the preempt_rt kernel than the
standard one.  RT kernel gives around 220us average with the standard
kernel about 80us.  Testing with Xenomai gives about 60us. The response
times are measured with an external logic analyser, and taken with no
other load on the system.  Kernel version is 3.14.

The difference between standard and RT kernel configs:
Preemption model: desktop vs. realtime kernel
Timer: 100Hz vs 1000Hz
High resolution timers disabled


Can you share the full .config for both configurations ? That should
shed a bit more light on what might be misconfigured.

I haven't run tests on the beaglebone black myself, but on similar
ARM boards, performance has been as expected.

You are talking about average latency above, what about the max
latency ? We expect that the preempt-rt kernel will have a higher
minimum, and often average latency .. but will be significantly
better in maximum latency.

It would also be useful to grab cyclictest results for the standard
and preempt-rt kernel as a baseline performance measure.

Bruce



I'm having a hard time figuring out why the RT kernel gives worse
latency.  Anyone have any insight into this?
Included the source code below.

Thanks & Regards,
Steve

#include
#include
#include
#include 
#include 
#include 
#include 
#include 
#include "poll.h"
#include "fcntl.h"
#include "string.h"
#include "errno.h"
#include 

#define TIMER_OUT_PATH "/sys/class/gpio/gpio47"
#define LED_OUT_PATH "/sys/class/gpio/gpio26"
#define IRQ_IN_PATH "/sys/class/gpio/gpio46"

static int timer_toggle = 0;
static int output_toggle = 0;

void stack_prefault(void)
{
 unsigned char dummy[8192];
 memset(dummy, 0, 8192);
}


int main(int argc, char* argv[])
{
struct itimerspec itv;
unsigned long long timer_increment = 0;

clock_t prevClock;
int sigCnt = 0;
struct sigaction sa;
struct sched_param sp;

struct pollfd fdset[2];
int fd_in;
int action;
int fd_led;
int fd_timer_out;
int fd_timer_in;

char buf[2];
int len;

// setup gpio
if(system("echo 46 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 46");

if(system("echo 47 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 47");

if(system("echo 26 > /sys/class/gpio/export") == -1)
 perror("unable to export gpio 26");

// timer out
if(system("echo out > /sys/class/gpio/gpio47/direction") == -1)
 perror("unable to set 47 to output");

 // led out
 if(system("echo out > /sys/class/gpio/gpio26/direction") == -1)
 perror("unable to set 26 to output");

 // irq in
 if(system("echo in > /sys/class/gpio/gpio46/direction") == -1)
 perror("unable to set 46 to input");

 if(system("echo both > /sys/class/gpio/gpio46/edge") == -1)
 perror("unable to set 46 edge");

 // set scheduling parameters
 sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
 if(sched_setscheduler(0, SCHED_FIFO, &sp) == -1)
 {
 perror("setscheduler");
 exit(-1);
 }

 // lock memory
 if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1)
 perror("mlockall");

 stack_prefault();

// Set up timer
 fd_timer_in = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
 printf("fd_timer:%d\n",fd_timer_in);

 if(fd_timer_in < 0)
 {
 perror("timerfd_create()");
 }

itv.it_value.tv_sec = 0;
itv.it_value.tv_nsec = 1000;
itv.it_interval.tv_sec = 0;
itv.it_interval.tv_nsec = 1000;
if(-1 == timerfd_settime(fd_timer_in, 0, &itv, NULL))
{
perror("settime()");
}

// setup file descriptor for poll()
fd_in = open(IRQ_IN_PATH "/value", O_RDONLY | O_NONBLOCK);
printf("fd irq input:%d\n",fd_in);

if(fd_in < 0)
{
perror("file open problem");
exit(0);
}

while(1)
{
 memset((void*)fdset, 0, sizeof(fdset));
 fdset[0].fd = fd_in;
 fdset[0].events = POLLPRI | POLLERR;
 fdset[0].revents = 0;

 fdset[1].fd = fd_timer_in;
 fdset[1].events = POLLIN | POLLERR;
 fdset[1].revents = 0;
 action = poll(fdset, 2, -1);

 if(action < 0)
 {
 if(errno == EINTR)
 {
 // when signal interrupts poll, we poll again
 continue;
 }
 else
 {
 perror("poll failed");
 exit(0);
 }
 }

 if(fdset[1].revents & POL

Re: [yocto] Yocto-custom kernel build issue

2015-02-10 Thread Paul Eggleton 
Please keep replies on the mailing list, thanks.

Is this perhaps because you extracted the files onto an SD card / other storage 
device as a non-root user?

Cheers,
Paul

On Tuesday 10 February 2015 17:55:25 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
> 
> Thank you for your response.
> 
> It is the rootfs permissions issue.
> 
> I give the "chown -R root rfs" to my rfs then it is working.
> 
> Thanks and Regards,
> 
> Raghavendra.
> 
> - Original Message -
> From: "Paul Eggleton" 
> To: "Raghavendra Kakarla" 
> Cc: yocto@yoctoproject.org
> Sent: Tuesday, February 10, 2015 4:30:19 PM
> Subject: Re: [yocto] Yocto-custom kernel build issue
> 
> On Tuesday 10 February 2015 13:47:45 Raghavendra Kakarla wrote:
> > I am built the yocto for my custom machine. After booting a login prompt
> > was came. For that I tried the "root" as user name but it did not take
> > it.
> > 
> > Could please tell me where i can get the login and password details for
> > yocto rootfs.
> 
> The default is root with no password. If that doesn't work, do you have
> "debug-tweaks" in your EXTRA_IMAGE_FEATURES? It should be there by default.
> 
> Cheers,
> Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Realtime tests on beaglebone black

2015-02-10 Thread Stephen Flowers 

Hi All,

I have built the realtime kernel using Yocto and deployed on the 
beaglebone black (specifically core-image-rt-sdk).  I have written a 
program to test the timer latency and interrupt latency of userspace 
applications.  For this I'm using a simple timerfd to generate a 
periodic 10ms gpio toggle which itself acts as a gpio interrupt on 
another gpio pin.
I find the latency is much worse on the preempt_rt kernel than the 
standard one.  RT kernel gives around 220us average with the standard 
kernel about 80us.  Testing with Xenomai gives about 60us. The response 
times are measured with an external logic analyser, and taken with no 
other load on the system.  Kernel version is 3.14.


The difference between standard and RT kernel configs:
Preemption model: desktop vs. realtime kernel
Timer: 100Hz vs 1000Hz
High resolution timers disabled

I'm having a hard time figuring out why the RT kernel gives worse 
latency.  Anyone have any insight into this?

Included the source code below.

Thanks & Regards,
Steve

#include
#include
#include
#include 
#include 
#include 
#include 
#include 
#include "poll.h"
#include "fcntl.h"
#include "string.h"
#include "errno.h"
#include 

#define TIMER_OUT_PATH "/sys/class/gpio/gpio47"
#define LED_OUT_PATH "/sys/class/gpio/gpio26"
#define IRQ_IN_PATH "/sys/class/gpio/gpio46"

static int timer_toggle = 0;
static int output_toggle = 0;

void stack_prefault(void)
{
unsigned char dummy[8192];
memset(dummy, 0, 8192);
}


int main(int argc, char* argv[])
{
   struct itimerspec itv;
   unsigned long long timer_increment = 0;

   clock_t prevClock;
   int sigCnt = 0;
   struct sigaction sa;
   struct sched_param sp;

   struct pollfd fdset[2];
   int fd_in;
   int action;
   int fd_led;
   int fd_timer_out;
   int fd_timer_in;

   char buf[2];
   int len;

   // setup gpio
   if(system("echo 46 > /sys/class/gpio/export") == -1)
perror("unable to export gpio 46");

   if(system("echo 47 > /sys/class/gpio/export") == -1)
perror("unable to export gpio 47");

   if(system("echo 26 > /sys/class/gpio/export") == -1)
perror("unable to export gpio 26");

   // timer out
   if(system("echo out > /sys/class/gpio/gpio47/direction") == -1)
perror("unable to set 47 to output");

// led out
if(system("echo out > /sys/class/gpio/gpio26/direction") == -1)
perror("unable to set 26 to output");

// irq in
if(system("echo in > /sys/class/gpio/gpio46/direction") == -1)
perror("unable to set 46 to input");

if(system("echo both > /sys/class/gpio/gpio46/edge") == -1)
perror("unable to set 46 edge");

// set scheduling parameters
sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
if(sched_setscheduler(0, SCHED_FIFO, &sp) == -1)
{
perror("setscheduler");
exit(-1);
}

// lock memory
if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1)
perror("mlockall");

stack_prefault();

   // Set up timer
fd_timer_in = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
printf("fd_timer:%d\n",fd_timer_in);

if(fd_timer_in < 0)
{
perror("timerfd_create()");
}

   itv.it_value.tv_sec = 0;
   itv.it_value.tv_nsec = 1000;
   itv.it_interval.tv_sec = 0;
   itv.it_interval.tv_nsec = 1000;
   if(-1 == timerfd_settime(fd_timer_in, 0, &itv, NULL))
   {
   perror("settime()");
   }

   // setup file descriptor for poll()
   fd_in = open(IRQ_IN_PATH "/value", O_RDONLY | O_NONBLOCK);
   printf("fd irq input:%d\n",fd_in);

   if(fd_in < 0)
   {
   perror("file open problem");
   exit(0);
   }

   while(1)
   {
memset((void*)fdset, 0, sizeof(fdset));
fdset[0].fd = fd_in;
fdset[0].events = POLLPRI | POLLERR;
fdset[0].revents = 0;

fdset[1].fd = fd_timer_in;
fdset[1].events = POLLIN | POLLERR;
fdset[1].revents = 0;
action = poll(fdset, 2, -1);

if(action < 0)
{
if(errno == EINTR)
{
// when signal interrupts poll, we poll again
continue;
}
else
{
perror("poll failed");
exit(0);
}
}

if(fdset[1].revents & POLLIN)
{
//len = read(fdset[1].fd, 0, SEEK_SET);
len = read(fdset[1].fd, &timer_increment, 
sizeof(timer_increment));


fd_timer_out = open( TIMER_OUT_PATH "/value", O_WRONLY);

   if(timer_toggle ^= 1)
   {
   write(fd_timer_out, "1", 2);
   }
   else
   {
   write(fd_timer_out, "0", 2);
   }

   close(fd_timer_out);
}

if(fdset[0].revents & POLLPRI)
{
lseek(fdset[0].fd, 0, SEEK_SET);// read from start of file
len = read(fdset[0].fd, buf, sizeof(buf));

fd_led = open( LED_OUT_PATH "/value", O_WRONLY | O_NONBLOCK);

if

Re: [yocto] Error while trying to read environment variable from a recipe file

2015-02-10 Thread Paul Eggleton 
On Tuesday 10 February 2015 10:24:45 Bipnesh, Abhinav wrote:
> Hi All,
> 
> I was trying to read some of the environment variables from a recipe file
> using below python code
> 
> PACKAGES = "{TEST_PACKAGE}"

Problem #1 - if you are attempting to refer to the value of the
TEST_PACKAGE variable, you need ${TEST_PACKAGE} not {TEST_PACKAGE}.

> python __anonymous () {
> packages = []
> buildScriptVersion = os.environ['MajorVersion'] + "." +
> os.environ['MinorVersion'] buildID = os.environ['BuildID']
> buildOffSet = os.environ['BuildOffsetNum']
> buildNum = int(buildID) - int(buildOffSet)
> if buildNum <= 0:
> buildNum = 1
> Num = os.environ['Num']
> version = buildScriptVersion + "." + sprintNum + "." + str(buildNum)
> packageName = "test-" + version
> d.setVar("TEST_PACKAGE", " ".join(packages))
> }
> 
> But while running I am getting below error
> 
> 0001:def __anon_29__test_bb(d):
>  0002:packages = []
> *** 0003:buildScriptVersion = os.environ['MajorVersion'] + "." +
> os.environ['MinorVersion'] 0004:buildID = os.environ['BuildID']
>  0005:buildOffSet = os.environ['BuildOffsetNum']
>  0006:buildNum = int(buildID) - int(buildOffSet)
>  0007:if buildNum <= 0:
> File: '/usr/lib64/python2.7/UserDict.py', lineno: 23, function: __getitem__
>  0019:if key in self.data:
>  0020:return self.data[key]
>  0021:if hasattr(self.__class__, "__missing__"):
>  0022:return self.__class__.__missing__(self, key)
> *** 0023:raise KeyError(key)
>  0024:def __setitem__(self, key, item): self.data[key] = item
>  0025:def __delitem__(self, key): del self.data[key]
>  0026:def clear(self): self.data.clear()
>  0027:def copy(self):
> Exception: KeyError: 'MajorVersion'
> 
> So any thoughts to fix this issue. As we need to have a package name with
> such variable which will be set in the environment at run time.

The environment available within the build is sanitised, only certain
variables are allowed through by default. There are a couple of alternatives
for working around this - whitelist the variable through, or access it via
BB_ORIGENV:

http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#passing-information-into-the-build-task-environment

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDKMACHINE settings

2015-02-10 Thread Paul Eggleton 
On Tuesday 10 February 2015 09:45:45 Parthiban Kandasamy wrote:
> On 9 February 2015 at 16:36, Paul Eggleton 
> wrote:
> > On Thursday 05 February 2015 17:43:31 Parthiban Kandasamy wrote:
> > > entirely i am new to embedded linux. first i did bitbake of
> > > core-image-minimal it came out very well. then again i tried sdk
> > > toolchain development using bitbake -k meta-toolchain-qte. it gives so
> > > many error. so could you provide details for how do i start to develop
> > > BSP for beagleboard-XM. i am entirely confused to understand yocto
> > > online document.
> > 
> > Can you please include a log of the errors you are receiving?
>
> while building toolchain for beagleboard-xm in my laptop, i got this
> compilation error oc autoconf, then how do i get back working level?

Firstly, please keep replies CC'd to the mailing list so that there is a 
chance for others to participate - thanks.

You are using 1.5. Can I suggest that you at least use the last stable release 
from the 1.5 branch i.e. 1.5.4? You may also wish to note that this release is 
no longer officially supported by our project, so a newer stable release would 
be preferred (1.6.2 or 1.7.1).

Having said that, there are two failures in the log:

1) Fetch failure for qt4-native. It's true that the upstream URL is no longer 
valid; however, the Yocto Project source mirror (set up as a MIRRORS entry by 
default in meta-yocto/conf/distro/poky.conf) definitely still has this file. 
Either you've disabled this or you have some kind of connectivity issue 
(firewall, proxy, intermittent connection failure) preventing the mirror from 
working. Check the log file 
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-
dora-10.0.0/BeagleBuild/tmp/work/x86_64-linux/qt4-native/4.8.5-
r0/temp/log.do_fetch.3111 to see if there is an indication as to why the 
mirror fetch failed if you are unsure.
 (I've just verified, fetching qt4-native with the 1.5.4 release automatically 
falls back to the mirror and succeeds here.)

2) Are you running the build within a buildtools or SDK environment? The 
/opt/poky/... path in the error message suggests that you might be. I can't 
reproduce this error with 1.5.4 either.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto-custom kernel build issue

2015-02-10 Thread Paul Eggleton 
On Tuesday 10 February 2015 13:47:45 Raghavendra Kakarla wrote:
> I am built the yocto for my custom machine. After booting a login prompt was
> came. For that I tried the "root" as user name but it did not take it.
> 
> Could please tell me where i can get the login and password details for
> yocto rootfs.

The default is root with no password. If that doesn't work, do you have 
"debug-tweaks" in your EXTRA_IMAGE_FEATURES? It should be there by default.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Error while trying to read environment variable from a recipe file

2015-02-10 Thread Bipnesh, Abhinav (Abhinav) 
Hi All,

I was trying to read some of the environment variables from a recipe file using 
below python code

PACKAGES = "{TEST_PACKAGE}"
python __anonymous () {
packages = []
buildScriptVersion = os.environ['MajorVersion'] + "." + 
os.environ['MinorVersion']
buildID = os.environ['BuildID']
buildOffSet = os.environ['BuildOffsetNum']
buildNum = int(buildID) - int(buildOffSet)
if buildNum <= 0:
buildNum = 1
Num = os.environ['Num']
version = buildScriptVersion + "." + sprintNum + "." + str(buildNum)
packageName = "test-" + version
d.setVar("TEST_PACKAGE", " ".join(packages))
}

But while running I am getting below error

0001:def __anon_29__test_bb(d):
 0002:packages = []
*** 0003:buildScriptVersion = os.environ['MajorVersion'] + "." + 
os.environ['MinorVersion']
 0004:buildID = os.environ['BuildID']
 0005:buildOffSet = os.environ['BuildOffsetNum']
 0006:buildNum = int(buildID) - int(buildOffSet)
 0007:if buildNum <= 0:
File: '/usr/lib64/python2.7/UserDict.py', lineno: 23, function: __getitem__
 0019:if key in self.data:
 0020:return self.data[key]
 0021:if hasattr(self.__class__, "__missing__"):
 0022:return self.__class__.__missing__(self, key)
*** 0023:raise KeyError(key)
 0024:def __setitem__(self, key, item): self.data[key] = item
 0025:def __delitem__(self, key): del self.data[key]
 0026:def clear(self): self.data.clear()
 0027:def copy(self):
Exception: KeyError: 'MajorVersion'

So any thoughts to fix this issue. As we need to have a package name with such 
variable which will be set in the environment at run time.

Thanks,
Abhinav
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple packages from single recipe file

2015-02-10 Thread Anders Darander 
Hi,

I'm not really following what you'd like to learn...

* Bipnesh, Abhinav (Abhinav)  [150209 17:43]:
> We have done on similar line for one of the package. We have to write
> another recipe for a package in which we need to just create packages
> and delivery it.  But we need to do it for couple of directories i.e.
> let say 10 directories.  Previously we have an script which perform
> some conversion and then create package in loop i.e. creating RPM in
> loop for such package.  Now we want to achieve the same using a
> recipe.  One of the solution is to write 10 such recipe and creating a
> package, But it means we need to check-out 10 times the code and then
> create the package.  But we are looking for some optimize way to do so
> as below

> 1. Check out all 10 directories in one shot.

Are these in different repositories or tarball? Or what do you mean with
"check out"?

> 2. Write small shell script code and call do_install() passing ${S}
> and ${D} as argument to create the package. Here we are also looking
> for package name for each such call different say package-1-ro.rpm
> package-2.r0.rpm etc.

Just write a do_install(), that installs all the files from your above
list in it's correct place.

Make sure that FILES_${PN} includes all the locations where you want to
pick-up files.

If you're creating multiple packages, just ensure that
FILES_${PN}-pkg1 = "..."
FILES_${PN}-pkg2 = "..."
etc
points to which files you want packaged in which package. 

> 3. Also avoid calling do_compile() as there is no makefile its plain
> file repo which need to be packaged.

Just create an empty do_compile(). Or you could remove do_package() from
the task list for this recipe, though, it's slightly easier to just
provide an empty do_compile().

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-selinux] audit: sleep to wait for stop finished

2015-02-10 Thread wenzong.fan 
From: Wenzong Fan 

This issue only occurs on Board Target that boot with local disk.

Steps to reproduce the issue:

$ for x in `seq 1 10`; do /etc/init.d/auditd restart; done
$ ps -e | grep auditd

There will be many auditd processes running.

If stop is not finished completely, then start will generate two
auditd processes in the case.

Signed-off-by: Wenzong Fan 
---
 recipes-security/audit/audit/auditd | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-security/audit/audit/auditd 
b/recipes-security/audit/audit/auditd
index fcd96c9..bac9a77 100755
--- a/recipes-security/audit/audit/auditd
+++ b/recipes-security/audit/audit/auditd
@@ -73,6 +73,10 @@ do_stop()
no|NO) ;;
*) /sbin/auditctl -D >/dev/null ;;
esac
+
+   # Waiting for start-stop-daemon finished
+   sleep 1
+
return "$RETVAL"
 }
 
-- 
1.9.1

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

Re: [yocto] Yocto-custom kernel build issue

2015-02-10 Thread Raghavendra Kakarla 
Hi,

I am built the yocto for my custom machine. After booting a login prompt was 
came.
For that I tried the "root" as user name but it did not take it.

Could please tell me where i can get the login and password details for yocto 
rootfs.



Thanks and Regards,

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