[yocto] Deploy new driver

2015-08-17 Thread binhancntt 

Hi all,
I'm deploying a customized usb gadget as following ways:
1. create a new recipes and specify MACHINE_ESSENTIAL_EXTRA_RDEPEND += 
"mygadget". I expect it is loaded with kernel but the .KO is included 
only to /lib/modules/3.14.28-1.0.0_ga+g91cf351/extra. I tried with 
KERNEL_MODULE_AUTOLOAD += "mygadget" but it does not help.


2. Kernel source code is extracted to 
build/tmp/work-shared//kernel-source. I intended to add my 
driver to drivers/usb/gadget/ but whenever I tried 'bitbake linux-imx -c 
menuconfig', this source is removed completely.


Can you please show me what wrong I have made and what direction should 
I follow to add a new driver to kernel?

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

Re: [yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?

2015-08-17 Thread Randy MacLeod 

On 2015-08-14 02:41 AM, wenzong fan wrote:

On 08/12/2015 09:05 PM, Joe MacDonald wrote:

[[yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?]
On 15.08.12 (Wed 17:08) wenzong fan wrote:


Hi All,

There's a libcap-ng in meta-oe layer, it has been updated to 0.7.7
and the
one in meta-selinux is 0.7.3.

How about removing the one in meta-selinux and get this layer depends on
meta-oe? Any suggestions?


The last time we had this discussion my sense was that most users of
meta-selinux wanted to continue with it only depending on oe-core.
That's my preference as well.

I'm happy to merge an updated version of libcap-ng (or maybe I'll get to
it myself, since I've known about it since Armin removed it from
meta-security, that was the time of the last discussion, I think).

All I'm saying right now is that this isn't a case of accidental
duplication of recipes in multiple layers, it's the result of a
conscious decision.  It's totally worthwhile re-visiting that decision,
though to make sure the reasons are still valid.



Thanks for clarifying this, just send out an update patch for libcap-ng.


I still think it belongs in oe-core.

Wenzong,

Can you try to build up a case for that?
If I look at the dependencies on Ubuntu-15.04:

Reverse Depends:
  qemu-system-common,libcap-ng0
  libvirt0,libcap-ng0
  libvirt-bin,libcap-ng0
  libcap-ng0:i386,libcap-ng0 0.7.4-2
  libcap-ng0:i386,libcap-ng0 0.7.4-2
  suricata,libcap-ng0
  libcap-ng-utils,libcap-ng0 0.7.4-2
  ladvd,libcap-ng0
  heimdal-kdc,libcap-ng0
  audispd-plugins,libcap-ng0
  smartmontools,libcap-ng0
  qemu-system-common,libcap-ng0
  libvirt0,libcap-ng0
  libvirt-bin,libcap-ng0
  libcap-ng-dev,libcap-ng0 0.7.4-2
  irqbalance,libcap-ng0
  gnome-keyring,libcap-ng0
  dbus-1-dbg,libcap-ng0
  dbus,libcap-ng0

note that pkgs in:
  meta-virtualization: irqbalance, libvirt, more?
  meta-selinux: audit
  meta-security-framework: audit
could drop the local versions of libcap-ng and use the
oe-core libcap-ng.


Please check on the actual source/configure options so that
we(I!!) get a better understanding of where libcap vs libcap-ng
is used.

In fact, since meta-security-framework isn't using selinux, I'd
say that both audit and libcap-ng should both move to oe-core.


Thanks,
../Randy




Wenzong



--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5

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

Re: [yocto] [oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 -- resend to right list.

2015-08-17 Thread Philip Tricca 
I started scoping out an upgrade over the weekend. I'm maintaining a
branch here: https://github.com/flihp/meta-selinux/tree/upgrade

It is very much a WIP so expect rebases. Some notes below:

On 08/14/2015 12:15 AM, wenzong fan wrote:
> I just sent uprev patches for:
> 
> libcap-ng 0.7.3 -> 0.7.7
> python-ipy 0.81 -> 0.83

Thanks for this!

> The remaining list that need to be updated:
> 
> selinux:
>   - libsemanage 2.3 2.4

https://github.com/flihp/meta-selinux/commit/0b75b251f789b4b5eb3adefd7c4c93569be0bc78

>   - sepolgen 1.2.1 1.2.2

Not yet.

>   - checkpolicy 2.3 2.4

https://github.com/flihp/meta-selinux/commit/cdc01a9976571852f123e1da59b99026307863ca

>   - libselinux 2.3 2.4

https://github.com/flihp/meta-selinux/commit/9ffd53dca0a02e16d25c1f382918fd12002c6c1d

>   - libsepol 2.3 2.4

https://github.com/flihp/meta-selinux/commit/41de80ba447ad665245b26bb1b72f9c2168b8288

>   - policycoreutils 2.3 2.4

There is a significant change between 2.3 and 2.4 with the addition of
the CIL. The policy build / link process has changed quite a bit and
there have been new utilities added to policycoreutils (the pp tool).
This tools doesn't play well with bzip2 compressed policy modules:

https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1069329

so we may have to drop compressed module support which would be
unfortunate given the size savings. There may be a workaround though so
I haven't given up hope yet. Just haven't found the fix.

I'm working through the upgrade to policycoreutils currently and I'm
slogging through the process of figuring out how to bootstrap a compiled
policy with the new format.

There hasn't been a new setools release to match the latest changes in
the toolchain. This means that the old recipe won't work and we'll have
to build from git if we want setools. I've got a recipe for that but
haven't pushed it. Personally I've never done anything with setools so I
wouldn't oppose dropping it till they do a new release. It looks like
there hasn't been any work on setools in a few years beyond maintaining
compatibility with the toolchain.

I'm also at LinuxCon this week if anyone else happens to be around and
wants to hack-a-thon this some evening :)

Best,
Philip

> On 08/14/2015 08:38 AM, Joe MacDonald wrote:
>> [[oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 --
>> resend to right list.] On 15.08.13 (Thu 17:37) Randy MacLeod wrote:
>>
>>>
>>> Resending to the right list.
>>> (yocto@yoctoproject.org rather than
>>>   openembedded-de...@lists.openembedded.org )
>>>
>>> Radzy will be working on meta-selinux and
>>> I've suggested that the start with a package uprev or two
>>> once the upstream selinux release intentions are known.
>>
>> Well, the backlog is cleared out (not quite true, but I'm waiting on a
>> final verification from my autobuilders before merging the last couple
>> of patches) and it looks like I didn't destroy Phil's work on the
>> filesystem labelling bits when rebasing them, so I expect I'll merge
>> those tomorrow too.  Let's say everything after that is negotiable.  :-)
>>
>> -J.
>>
>>>
>>> ../Randy
>>>
>>> ---
>>>
>>> Going on-list like I should have originally.
>>>
>>> On 2015-07-31 01:33 PM, Joe MacDonald wrote:
 Hey Randy,

 Good to hear from you.

 [meta-selinux updates for oe-core-1.9] On 15.07.31 (Fri 01:05) Randy
 MacLeod wrote:

> What's the plan for meta-selinux in the next 2 months?
>>>
>>> Roy dug up the current meta-selinux, upstream versions:
>>>
>>> swig 2.0.103.0.6
>>> python-ipy 0.81 0.83
>>> audit 2.3.22.4.3
>>> refpolicy-mls 2.201403112.20141203
>>> libcap-ng 0.7.30.7.7
>>> setools   3.3.83.3.8
>>> sepolgengit1.2.2
>>> libsemanage git  2.4
>>> checkpolicy 2.3  2.4
>>> policycoreutils git  2.4
>>> selinux-config  0.1  0.1
>>> libsepolgit  2.4
>>> libsemanage 2.3  2.4
>>> sepolgen  1.2.11.2.2
>>> libsepol2.3  2.4
>>> libselinux  git  2.4
>>> policycoreutils 2.3  2.4
>>> libselinux  2.3  2.4
>>> ustr  1.0.41.0.4
>>>
>>>

 There's a backlog of meta-selinux patches to integrate that have
 been in
 my merge queue for rather a long time now.  I expect to clear that out,
 which will include an update to the most recent (not the current, any
 longer, I don't think) refpolicy and a new recipe that will build from
 the refpolicy git repository rather than release tarballs.  I think
 this'll be a significant benefit to everyone in that it'll make it much
 easier to migrate patches and to try out a new release without waiting
 for a full update.  Those are the big things on the horizon.

 The other one is the filesyste

Re: [yocto] yocto Digest, Vol 59, Issue 81

2015-08-17 Thread Manish Thatte 
I am getting this error when i try to run hob:

openatvbuilder@mani ~/poky/build $ hob
Please set DISPLAY variable before running Hob.


Please help
Manish

On Mon, Aug 17, 2015 at 3:28 PM,  wrote:

> Send yocto mailing list submissions to
> yocto@yoctoproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
> yocto-requ...@yoctoproject.org
>
> You can reach the person managing the list at
> yocto-ow...@yoctoproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yocto digest..."
>
>
> Today's Topics:
>
>1. Re: [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build
>   audio driver into kernel (Andrei Gherzan)
>2. Re: [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build
>   audio driver into kernel (Petter Mab?cker)
>3. Kernel panic - not syncing: No working init found.
>   (Gorny Krystian)
>4. Re: [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build
>   audio driver into kernel (Alex J Lennon)
>5. Re: [meta-raspberrypi][PATCH v2 4/4] README: Add a section
>   about graphic stacks (Javier Martinez Canillas)
>
>
> --
>
> Message: 1
> Date: Mon, 17 Aug 2015 09:57:10 +0200
> From: Andrei Gherzan 
> To: "pet...@technux.se" 
> Cc: "yocto@yoctoproject.org" 
> Subject: Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi:
> build audio driver into kernel
> Message-ID:
> <
> cak18fxhq-isart0mebhqonc+jzuk+0ix50y6838ocpmrc7v...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> On Tuesday, August 11, 2015, Petter Mab?cker  wrote:
>
> > 2015-08-11 19:04 skrev Alex J Lennon:
> >
> > Signed-off-by: Alex J Lennon  >
> > ---
> >  recipes-kernel/linux/linux-raspberrypi.inc | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
> b/recipes-kernel/linux/linux-raspberrypi.inc
> > index e38d905..8024412 100644
> > --- a/recipes-kernel/linux/linux-raspberrypi.inc
> > +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> > @@ -6,6 +6,10 @@ SECTION = "kernel"
> >  LICENSE = "GPLv2"
> >  LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> >
> > +SRC_URI += " \
> > +file://build-in-audio.cfg \
> > +"
> >
> >
> This one didn't make it.
>
> --
> Andrei Gherzan
>
>
> --
> --
> Andrei Gherzan
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.yoctoproject.org/pipermail/yocto/attachments/20150817/bcd74813/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Mon, 17 Aug 2015 10:11:13 +0200
> From: Petter Mab?cker 
> To: Andrei Gherzan , Alex J Lennon
> 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi:
> build audio driver into kernel
> Message-ID: <8cc28d589389102b4fccf052fe238...@technux.se>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> 2015-08-17 09:57 skrev Andrei Gherzan:
>
> > Hello,
> >
> > On Tuesday,
> August 11, 2015, Petter Mab?cker  wrote:
> >
> >>
> 2015-08-11 19:04 skrev Alex J Lennon:
> >>
> >>> Signed-off-by: Alex J
> Lennon 
> >>> ---
> >>>
> recipes-kernel/linux/linux-raspberrypi.inc | 4 
> >>> 1 file changed,
> 4 insertions(+)
> >>>
> >>> diff --git
> a/recipes-kernel/linux/linux-raspberrypi.inc
> b/recipes-kernel/linux/linux-raspberrypi.inc
> >>> index e38d905..8024412
> 100644
> >>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> >>> +++
> b/recipes-kernel/linux/linux-raspberrypi.inc
> >>> @@ -6,6 +6,10 @@
> SECTION = "kernel"
> >>> LICENSE = "GPLv2"
> >>> LIC_FILES_CHKSUM =
> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> >>>
> >>> +SRC_URI
> += "
> >>> + file://build-in-audio.cfg
> >>> + "
> >
> > This one didn't make
> it.
> >
> > --
> > Andrei Gherzan
> >
> > --
> >
> > -- Andrei Gherzan
>
> Think
> you got the wrong receiver =) I

[yocto] [rrs][PATCH 2/2] rrs/base_toplevel.html: Navbar redesign

2015-08-17 Thread mariano . lopez 
From: Mariano Lopez 

This provides changes in the front end for the
navbar, now it shows the percentage of recipes
up-to-date, not update, unknown and can't be
updated along with the number of recipes.

This also moves the update percentage to the
end and adds clarity to what it means.

This also moves the export list button the the
top bar.

Signed-off-by: Mariano Lopez 
---
 rrs/static/css/rrs-additional.css | 13 
 templates/rrs/base_toplevel.html  | 44 ---
 2 files changed, 36 insertions(+), 21 deletions(-)

diff --git a/rrs/static/css/rrs-additional.css 
b/rrs/static/css/rrs-additional.css
index bdfa151..0066945 100644
--- a/rrs/static/css/rrs-additional.css
+++ b/rrs/static/css/rrs-additional.css
@@ -43,6 +43,11 @@
margin-top: 40px;
 }
 
+.nav > li.lead {
+   margin: 5px 25px 0 5px;
+}
+
+
 /* Sorting styles  */
 th > a, th.muted {
 font-weight: normal;
@@ -71,6 +76,10 @@ th > a, th.muted {
margin-bottom: 0;
 }
 
+.navbar .nav > li > .secondary-info {
+font-size:70%;
+}
+
 .navbar .badge {
margin-top: 10px;
margin-right: 10px;
@@ -104,10 +113,6 @@ th > a, th.muted {
padding: 8px 14px 8px 14px;
 }
 
-.nav > li.lead {
-   margin: 5px 0 0 5px;
-}
-
 
 /* about recipe styles */
 
diff --git a/templates/rrs/base_toplevel.html b/templates/rrs/base_toplevel.html
index fd0c96c..9e00cef 100644
--- a/templates/rrs/base_toplevel.html
+++ b/templates/rrs/base_toplevel.html
@@ -51,6 +51,7 @@
 
 {% endblock %}
 
+Export recipe list
 {% endblock %}
 
 {% block content %}
@@ -58,25 +59,34 @@
 
 
 
-
-{{ release_name }}
-{% if milestone_name != "All" %}
-{{ milestone_name }}
-{% endif %}
-
 
-
-{{ recipes_percentage }}% Updated
-
-Up-to-date: 
{{ recipes_up_to_date }}
-
-Not updated: 
{{ recipes_not_updated }}
-
-Can't be 
updated: {{ recipes_cant_be_updated }}
-
-Unknown: {{ recipes_unknown }}
+
+{{ release_name }}
+{% if milestone_name != "All" %}
+{{ milestone_name }}
+{% endif %}
+
+
+{{ 
recipes_percentage_up_to_date }}%
+up-to-date ({{ 
recipes_up_to_date }})
+
+
+{{ 
recipes_percentage_not_updated }}%
+not updated ({{ 
recipes_not_updated }})
+
+
+{{ 
recipes_percentage_cant_be_updated }}%
+can't be updated ({{ 
recipes_cant_be_updated }})
+
+
+{{ 
recipes_percentage_unknown }}%
+unknown ({{ 
recipes_unknown }})
+
+
+{{ recipes_percentage 
}}%
+of planned work done 
({{ recipes_all_upgraded }} of {{ recipes_all_not_upgraded }})
+
 
-Export recipe list
 
 {% block navs %}{% endblock %}
 
-- 
1.9.1

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

[yocto] [rrs][PATCH 1/2] rrs/views.py: Added percentages for navbar

2015-08-17 Thread mariano . lopez 
From: Mariano Lopez 

This adds the percentage for all the recipes types
(up-to-date, not updated, unknown, can't be updated)
so it can be displayed in the navbar.

This also adds the number of the recipes not updated
at the begining of the period and number of recipes
updated in the period.

The changes in the frontend are still missing, this
just adds the functionality.

Signed-off-by: Mariano Lopez 
---
 rrs/views.py | 71 ++--
 1 file changed, 55 insertions(+), 16 deletions(-)

diff --git a/rrs/views.py b/rrs/views.py
index e446c0d..01f14f5 100644
--- a/rrs/views.py
+++ b/rrs/views.py
@@ -47,22 +47,8 @@ def _get_milestone_statistics(milestone, 
maintainer_name=None):
 )
 
 if maintainer_name is None:
-if recipe_upstream_history_first:
-recipes_not_upgraded = \
-Raw.get_reup_by_date(recipe_upstream_history_first.id)
-if recipes_not_upgraded:
-recipes_upgraded = \
-Raw.get_reupg_by_dates_and_recipes(
-milestone.start_date, milestone.end_date, 
recipes_not_upgraded)
-milestone_statistics['all'] = \
-
float(len(recipes_upgraded))/float(len(recipes_not_upgraded))
-else:
-milestone_statistics['all'] = 0
-else:
-milestone_statistics['all'] = 0
-
-milestone_statistics['percentage'] = "%.0f" % \
-(float(milestone_statistics['all']) * 100.0)
+milestone_statistics['all'] = \
+RecipeUpstream.get_all_recipes(recipe_upstream_history).count()
 milestone_statistics['up_to_date'] = \
 
RecipeUpstream.get_recipes_up_to_date(recipe_upstream_history).count()
 milestone_statistics['not_updated'] = \
@@ -71,6 +57,39 @@ def _get_milestone_statistics(milestone, 
maintainer_name=None):
 
RecipeUpstream.get_recipes_cant_be_updated(recipe_upstream_history).count()
 milestone_statistics['unknown'] = \
 RecipeUpstream.get_recipes_unknown(recipe_upstream_history).count()
+milestone_statistics['percentage'] = 0
+milestone_statistics['all_upgraded'] = 0
+milestone_statistics['all_not_upgraded'] = 0
+milestone_statistics['percentage_up_to_date'] = 0
+milestone_statistics['percentage_not_updated'] = 0
+milestone_statistics['percentage_cant_be_updated'] = 0
+milestone_statistics['percentage_unknown'] = 0
+
+if recipe_upstream_history_first:
+recipes_not_upgraded = \
+Raw.get_reup_by_date(recipe_upstream_history_first.id)
+if recipes_not_upgraded:
+recipes_upgraded = \
+Raw.get_reupg_by_dates_and_recipes(
+milestone.start_date, milestone.end_date, 
recipes_not_upgraded)
+milestone_statistics['percentage'] = "%.0f" % \
+((float(len(recipes_upgraded)) * 100.0)
+/float(len(recipes_not_upgraded)))
+milestone_statistics['all_upgraded'] = len(recipes_upgraded)
+milestone_statistics['all_not_upgraded'] = 
len(recipes_not_upgraded)
+milestone_statistics['percentage_up_to_date'] = "%.0f" % \
+(float(milestone_statistics['up_to_date']) * 100.0 \
+/float(milestone_statistics['all']))
+milestone_statistics['percentage_not_updated'] = "%.0f" % \
+(float(milestone_statistics['not_updated']) * 100.0 \
+/float(milestone_statistics['all']))
+milestone_statistics['percentage_cant_be_updated'] = "%.0f" % \
+(float(milestone_statistics['cant_be_updated']) * 100.0 \
+/float(milestone_statistics['all']))
+milestone_statistics['percentage_unknown'] = "%.0f" % \
+(float(milestone_statistics['unknown']) * 100.0
+/float(milestone_statistics['all']))
+
 else:
 recipe_maintainer_history = Raw.get_remahi_by_end_date(
 milestone.end_date)
@@ -259,10 +278,20 @@ class RecipeListView(ListView):
 context['all_milestones'] = 
Milestone.get_by_release_name(self.release_name)
 
 context['recipes_percentage'] = self.milestone_statistics['percentage']
+context['recipes_all_upgraded'] = 
self.milestone_statistics['all_upgraded']
+context['recipes_all_not_upgraded'] = 
self.milestone_statistics['all_not_upgraded']
 context['recipes_up_to_date'] = self.milestone_statistics['up_to_date']
 context['recipes_not_updated'] = 
self.milestone_statistics['not_updated']
 context['recipes_cant_be_updated'] = 
self.milestone_statistics['cant_be_updated']
 context['recipes_unknown'] = self.milestone_statistics['unknown']
+context['recipes_percentage_up_to_date'] = \
+

[yocto] [rrs][PATCH 0/2] Changes to the navbar

2015-08-17 Thread mariano . lopez 
From: Mariano Lopez 

These patches change the design of the navbar.
It makes more clear what is the meaning of the
percentage in there and adds more information.

Mariano Lopez (2):
  rrs/views.py: Added percentages for navbar
  rrs/base_toplevel.html: Navbar redesign

 rrs/static/css/rrs-additional.css | 13 ---
 rrs/views.py  | 71 ++-
 templates/rrs/base_toplevel.html  | 44 ++--
 3 files changed, 91 insertions(+), 37 deletions(-)

-- 
1.9.1

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

[yocto] Issue with init scripts start-stop-daemon and use of set -e ?

2015-08-17 Thread Alex J Lennon 
Hi,

I've been trying to track down an issue I was seeing with ofono not
restarting on a fido image and have encountered what seems to be an
issue related to the sys v init script.

Sometimes when we make a call as follows the ofono daemon isn't started
correctly

/etc/init.d/ofono restart

It seems there's a "set -e" in there to cause the script to exit if a
command returns a non-zero.

When the do_stop() function is called from restart if the daemon isn't
already running busybox will return non-zero which causes the script to
drop out and the do_start() method is never called.

(I have yet to determine why the ofono daemon might not be running
already when we make the call but that's a separate problem...)

Given the expected behaviour of calling restart on a service is to start
it even if it was not running then perhaps the "set -e" needs to be
removed or || true added ?

This seems relevant to ofono in master, and some quick grepping of
init.d shows other scripts are similar.

Can anybody comment?

Thanks,

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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

2015-08-17 Thread Alex J Lennon 
On 17/08/2015 09:11, Petter Mabäcker wrote:
> 2015-08-17 09:57 skrev Andrei Gherzan:
> 
>> Hello,
>>
>> On Tuesday, August 11, 2015, Petter Mabäcker > > wrote:
>>
>> 2015-08-11 19:04 skrev Alex J Lennon:
>>
>> Signed-off-by: Alex J Lennon 
>> ---
>>  recipes-kernel/linux/linux-raspberrypi.inc | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index e38d905..8024412 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -6,6 +6,10 @@ SECTION = "kernel"
>>  LICENSE = "GPLv2"
>>  LIC_FILES_CHKSUM = 
>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>  
>> +SRC_URI += " \
>> +file://build-in-audio.cfg \
>> +"
>>
>>  
>> This one didn't make it.
>>  
>>  
>>  
>>  
>> --
>> Andrei Gherzan
>>
>>
>> -- 
>> --
>> Andrei Gherzan
> 
> Think you got the wrong receiver =) I notified Alex about this some days
> ago, Alex can you send up a v2 for this?
> 
>

The build-in-audio.cfg patch was just for testing of fragment support.
It's understood that we're not going to have this build into the kernel
by default, although I do still need to find some words to add to the
README on audio routing setup and so forth.

I started testing a build with master over the weekend and it built OK.
Just need to find some time to run up a couple of kernels and will
resubmit the v2 patch with Petter's enhanced commit message.

I don't have an RPiv1 around at the moment but I will probably double
check the kernel does still actually build for RPiv1 machine

Cheers,

Alex


> 
> BR, Petter
> 

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

Re: [yocto] [meta-raspberrypi][PATCH v2 4/4] README: Add a section about graphic stacks

2015-08-17 Thread Javier Martinez Canillas 
Hello Andrei and Khem,

Thanks a lot for your feedback.

On 08/17/2015 09:57 AM, Andrei Gherzan wrote:
> Hello,
> 
> On Thursday, August 13, 2015, Khem Raj  wrote:
> 
>>
>>> On Aug 13, 2015, at 10:07 AM, Javier Martinez Canillas <
>> jav...@osg.samsung.com > wrote:
>>>
>>> This patch adds to the README a section that explains the RPi can
>> different
>>> graphics stacks and that the user can choose by manually changing
>> providers.
>>>
>>> Signed-off-by: Javier Martinez Canillas > >
>>>
>>> ---
>>>
>>> Changes in v2: None
>>>
>>> README | 9 +
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/README b/README
>>> index 678c0eb4a4e3..0569b353870c 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -25,6 +25,7 @@ Contents:
>>> 2.K. Boot to U-Boot
>>> 2.L. Image with Initramfs
>>> 2.M. Device tree support
>>> +2.O. Graphic stacks
>>> 3. Extra apps
>>> 3.A. omxplayer
>>> 4. Source code and mirrors
>>> @@ -195,6 +196,14 @@ kernels.
>>> NOTE: KERNEL_DEVICETREE is default enabled for kernel >= 3.18 and always
>> disabled for
>>>   older kernel versions.
>>>
>>> +2.O. Graphic stacks
>>> +===
>>> +The Raspberry Pi boards can use one of two graphics stacks: The userland
>>> +user-space driver or the vc4 DRM/KMS kernel driver. By default userland
>>> +is used since the vc4 is still experimental. But this can be changed by
>>> +modifying the defaults for the kernel, egl, gles2, libgl and mesa
>> providers.
>>> +This is explained in the conf/machine/include/rpi-default-providers.inc
>> file.
>>> +
>>
>> you may want to add pointer to the commented out code that you have added
>> to select them
>> in rpi-default-providers.inc
>>
> 
> It would be nice to have some detailed info on what and where to comment
> out the configuration.
>

On patch 3/4 I added that documentation to rpi-default-providers but didn't
add it to the README and instead pointed out to rpi-default-providers to
have a level of indirection in case the providers change and to not have
duplicated information but I will add it to the README as well.

Do you have comments on the other patches in the series so I can address
all of them before re-spinning?

> --
> Andrei Gherzan
> 
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

2015-08-17 Thread Alex J Lennon 
On 17/08/2015 09:11, Petter Mabäcker wrote:
> 2015-08-17 09:57 skrev Andrei Gherzan:
> 
>> Hello,
>>
>> On Tuesday, August 11, 2015, Petter Mabäcker > > wrote:
>>
>> 2015-08-11 19:04 skrev Alex J Lennon:
>>
>> Signed-off-by: Alex J Lennon 
>> ---
>>  recipes-kernel/linux/linux-raspberrypi.inc | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index e38d905..8024412 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -6,6 +6,10 @@ SECTION = "kernel"
>>  LICENSE = "GPLv2"
>>  LIC_FILES_CHKSUM = 
>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>  
>> +SRC_URI += " \
>> +file://build-in-audio.cfg \
>> +"
>>
>>  
>> This one didn't make it.
>>  
>>  
>>  
>>  
>> --
>> Andrei Gherzan
>>
>>
>> -- 
>> --
>> Andrei Gherzan
> 
> Think you got the wrong receiver =) I notified Alex about this some days
> ago, Alex can you send up a v2 for this?
> 
>

The build-in-audio.cfg patch was just for testing of fragment support.
It's understood that we're not going to have this build into the kernel
by default, although I do still need to find some words to add to the
README on audio routing setup and so forth.

I started testing a build with master over the weekend and it built OK.
Just need to find some time to run up a couple of kernels and will
resubmit the v2 patch with Petter's enhanced commit message.

I don't have an RPiv1 around at the moment but I will probably double
check the kernel does still actually build for RPiv1 machine

Cheers,

Alex


> 
> BR, Petter
> 

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

[yocto] Kernel panic - not syncing: No working init found.

2015-08-17 Thread Gorny Krystian 
Hi,

I have a problem with booting my Linux image. The boot error message is:

(...)
VFS: Mounted root (vfat filesystem) readonly on device 3:1.
Devtmpfs: error mounting -2
Freeing unused kernel memory: 636K (c1aa6000 - c1b45000)
Write protecting the kernel text: 7544k
Write protecting the kernel read-only  data: 2800k
Kernel panic - not syncing: No working init found. Try passing init= option to 
kernel. See Linux Documentation/init.txt for guidance.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.39ltsi-rt37-yocto-preempt-rt #1
(...)

I'm using the fido branch and build an core-image-rt for the genericx86 
machine. Create the yocto image works well. I have used the 
https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F
 instructions to put my image to the hard drive. I use ext4 as file system. 
When I put the image to a VirtualBox hard drive the virtual machine boots 
correctly without issues. This issue occur only on my real hardware (industrial 
pc with intel atom cpu).

I already tried to put init=/sbin/init or init=/sbin/init.sysvinit to grub.cfg 
without success. Any ideas?

Thanks Krystian

_

Krystian Gorny
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com


[http://www.wipotec.com/fileadmin/user_upload/Signatur/W_Standard.jpg]

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. D?ppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

2015-08-17 Thread Petter Mabäcker 
 

2015-08-17 09:57 skrev Andrei Gherzan: 

> Hello,
> 
> On Tuesday,
August 11, 2015, Petter Mabäcker  wrote: 
> 
>>
2015-08-11 19:04 skrev Alex J Lennon: 
>> 
>>> Signed-off-by: Alex J
Lennon 
>>> ---
>>>
recipes-kernel/linux/linux-raspberrypi.inc | 4 
>>> 1 file changed,
4 insertions(+)
>>> 
>>> diff --git
a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc
>>> index e38d905..8024412
100644
>>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>>> +++
b/recipes-kernel/linux/linux-raspberrypi.inc
>>> @@ -6,6 +6,10 @@
SECTION = "kernel"
>>> LICENSE = "GPLv2"
>>> LIC_FILES_CHKSUM =
"file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>> 
>>> +SRC_URI
+= " 
>>> + file://build-in-audio.cfg 
>>> + "
> 
> This one didn't make
it. 
> 
> -- 
> Andrei Gherzan 
> 
> -- 
> 
> -- Andrei Gherzan

Think
you got the wrong receiver =) I notified Alex about this some days ago,
Alex can you send up a v2 for this? 

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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

2015-08-17 Thread Andrei Gherzan 
Hello,

On Tuesday, August 11, 2015, Petter Mabäcker  wrote:

> 2015-08-11 19:04 skrev Alex J Lennon:
>
> Signed-off-by: Alex J Lennon  >
> ---
>  recipes-kernel/linux/linux-raspberrypi.inc | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index e38d905..8024412 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -6,6 +6,10 @@ SECTION = "kernel"
>  LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>
> +SRC_URI += " \
> +file://build-in-audio.cfg \
> +"
>
>
This one didn't make it.

--
Andrei Gherzan


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

Re: [yocto] [meta-raspberrypi][PATCH v2 4/4] README: Add a section about graphic stacks

2015-08-17 Thread Andrei Gherzan 
Hello,

On Thursday, August 13, 2015, Khem Raj  wrote:

>
> > On Aug 13, 2015, at 10:07 AM, Javier Martinez Canillas <
> jav...@osg.samsung.com > wrote:
> >
> > This patch adds to the README a section that explains the RPi can
> different
> > graphics stacks and that the user can choose by manually changing
> providers.
> >
> > Signed-off-by: Javier Martinez Canillas  >
> >
> > ---
> >
> > Changes in v2: None
> >
> > README | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/README b/README
> > index 678c0eb4a4e3..0569b353870c 100644
> > --- a/README
> > +++ b/README
> > @@ -25,6 +25,7 @@ Contents:
> > 2.K. Boot to U-Boot
> > 2.L. Image with Initramfs
> > 2.M. Device tree support
> > +2.O. Graphic stacks
> > 3. Extra apps
> > 3.A. omxplayer
> > 4. Source code and mirrors
> > @@ -195,6 +196,14 @@ kernels.
> > NOTE: KERNEL_DEVICETREE is default enabled for kernel >= 3.18 and always
> disabled for
> >   older kernel versions.
> >
> > +2.O. Graphic stacks
> > +===
> > +The Raspberry Pi boards can use one of two graphics stacks: The userland
> > +user-space driver or the vc4 DRM/KMS kernel driver. By default userland
> > +is used since the vc4 is still experimental. But this can be changed by
> > +modifying the defaults for the kernel, egl, gles2, libgl and mesa
> providers.
> > +This is explained in the conf/machine/include/rpi-default-providers.inc
> file.
> > +
>
> you may want to add pointer to the commented out code that you have added
> to select them
> in rpi-default-providers.inc
>

It would be nice to have some detailed info on what and where to comment
out the configuration.

--
Andrei Gherzan


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

Re: [yocto] Deploying 2 machines, u-boot does not include with both.

2015-08-17 Thread Mike Looijmans 

On 16-08-15 09:39, Khem Raj wrote:






Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





On Jun 24, 2015, at 1:53 AM, John Ernberg  wrote:


Hi

This is a weird one that I have been researching for a while trying to
figure out how this can happen.
We recently had to extend our targets with another machine, they have
the same core CPU architecture, but we provide different configurations
of the kernel for them. Along with some IMAGE_INSTALL changes.

Since very little needs to be rebuilt, and the only thing needed to
change target machine is to edit the MACHINE variable, we chose to build
the images using the same build directory.

This means we set the MACHINE variable to machine_A. run bitbake
[machine_A_image], change the MACHINE variable to machine_B, and then
run bitbake [machine_B_image].

Here is when the weird happens. After machine_A has built, we can find
everything we expect to find in the machine_A image deploy directory.
When we change the MACHINE variable and build machine_B, we find that
the u-boot image from the machine_A directory has disappeared.
Depending on build machine it has moved into the machine_B directory, in
addition to u-boot image for machine_B being present in this directory,
OR it has just been removed.
Changing back to building machine_A, the u-boot(s) are removed from the
machine_B directory, and the machine_A u-boot will show up in the
machine_A directo

What could be at play here to cause such a strange behaviour? How can I
debug such a behaviour? I could not find anything on Google regarding
this, nor anything in the logs generated by bitbake.



u-boot is machine specific package so in theory, it should have rebuilt for 
each of your target machines
and deploy images directory is also per machine so there should be no conflicts 
at all, unless you modify
the u-boot recipes such that they are made to be SOC family specific or some 
other voodoo, share your configurations
and recipes to get clear picture and may be something can come out.



This happens to any recipe that is built for multiple machines, e.g. the 
kernel as well if it is shared between machines. Somewhere in the early tasks, 
the recipe just blatantly removes the last build, and then starts running 
anew, ignoring that the output of that build was not located in the current 
machine's path. I think it will happen to anything that is deployed but is not 
specific to one machine. It will even happen to a rootfs if you share that 
between machines.


The only 'solution' I found for this problem is to copy the resulting binaries 
to yet another location after building them. Then bitbake can't reach them.


The proper thing to do here would be to have ARCH specific deploy paths 
instead of MACHINE specific. Some symlinks in the MACHINE path would take care 
of backward compatibility.


I had a discussion about this problem on the oe-core list about a year ago 
when I bumped into the same problem you describe here.

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