Re: [yocto] BBMASK not working for me?

[chris warth]

On Wed, Mar 1, 2017 at 5:39 PM, Paul Eggleton  wrote:

> On Thursday, 2 March 2017 2:14:13 PM NZDT chris warth wrote:
> >  wrote:
> > > On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
> > >> This vendor-supplied version of yocto looks like 2.0, so the space
> > >> separated expressions are not available.
> > >> After putting some print statements in cooker.py I discovered that
> > >> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
> > >> effect.  It was not until I modified BBMASK_forcevariable in my
> > >> conf/bblayers.conf  that I saw any change in behavior.
> > >>
> > >> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
> > >>
> > >> This inability to modify BBMASK unless using _forcevariable was also
> > >> noted last year.
> > >> https://lists.yoctoproject.org/pipermail/yocto/2016-
> September/032033.html
> > >
> > > That sounds strange. Did you use bitbake -e | less to see where your
> non-
> > > forcevariable setting was being overridden? More than likely you have a
> > > layer or some other configuration you're bringing in and that's simply
> > > setting it with = at some point later in parsing than local.conf. The
> > > history of the BBMASK variable shown through bitbake -e will tell you
> > > exactly where that is.
> >
> > Thank you, Paul.  I didn't know about bitbake -e.
> > As you predicted, it shows that an earlier layer is setting BBMASK
> > with equals, in this case the
> > meta-freescale layer.
> >
> > BBMASK=".*openjre|.*openjdk"
> >
> > Should I be mad at the vendor for being careless?
>
> Personally I think you should, yes. BSP layers really should not be setting
> BBMASK, IMO. Interestingly though I can't see this BBMASK in meta-fsl-arm /
> meta-fsl-ppc either in current master or in the history for master - where
> is
> this exactly?
>
>
FWIW, This is in a SDK for the LS1046A development board supplied by NXP as
a couple of ISO images and a tarball in late 2016.For the most part it
seems to be based on publicly accessible sources although the ls1046a-rdb
support comes from cached copies of internal NXP git repos (e.g.
sw-stash.freescale.net/scm/dnnpi).

Here is the bitbake -e output showing BBMASK

# $BBMASK [2 operations]
#   set
/mnt/nxp-sdk/sources/meta-freescale/conf/machine/include/qoriq-arm64.inc:9
# ".*openjre|.*openjdk"
#   set /mnt/nxp-sdk/sources/poky/meta/conf/documentation.conf:95
# [doc] "Prevents BitBake from processing specific recipes or recipe
append files. Use the BBMASK variable from within conf/local.conf."
# pre-expansion value:
#   ".*openjre|.*openjdk"
BBMASK=".*openjre|.*openjdk"

 Thanks again for helping me to understand this stuff.

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

Re: [yocto] BBMASK not working for me?

[Paul Eggleton]

On Thursday, 2 March 2017 2:14:13 PM NZDT chris warth wrote:
>  wrote:
> > On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
> >> This vendor-supplied version of yocto looks like 2.0, so the space
> >> separated expressions are not available.
> >> After putting some print statements in cooker.py I discovered that
> >> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
> >> effect.  It was not until I modified BBMASK_forcevariable in my
> >> conf/bblayers.conf  that I saw any change in behavior.
> >> 
> >> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
> >> 
> >> This inability to modify BBMASK unless using _forcevariable was also
> >> noted last year.
> >> https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html
> > 
> > That sounds strange. Did you use bitbake -e | less to see where your non-
> > forcevariable setting was being overridden? More than likely you have a
> > layer or some other configuration you're bringing in and that's simply
> > setting it with = at some point later in parsing than local.conf. The
> > history of the BBMASK variable shown through bitbake -e will tell you
> > exactly where that is.
>
> Thank you, Paul.  I didn't know about bitbake -e.
> As you predicted, it shows that an earlier layer is setting BBMASK
> with equals, in this case the
> meta-freescale layer.
> 
> BBMASK=".*openjre|.*openjdk"
> 
> Should I be mad at the vendor for being careless?

Personally I think you should, yes. BSP layers really should not be setting 
BBMASK, IMO. Interestingly though I can't see this BBMASK in meta-fsl-arm / 
meta-fsl-ppc either in current master or in the history for master - where is 
this exactly?

> Is BBMASK_forcevariable the right workaround for this?

You should be able to use _append, provided you are OK with openjre/openjdk 
recipes also being masked out.

> Or is there some layer priority scheme beyond the ordering in the
> bblayers.conf file that I should playing nice with?

I usually describe BBMASK as a huge hammer - it prevents bitbake from even 
reading recipes / bbappends that match it. My recommendation is not to use it 
at all unless there's no other way.

One alternative way of dealing with recipes you don't want to have built is to 
use PNBLACKLIST. You do have to know the exact recipe name (PN) that you want 
to blacklist, you can't do it by regex - but usually that's not too much of a 
problem. The advantage of PNBLACKLIST is that you get to specify a reason why 
the recipe is blacklisted, and thus it is usually much more obvious what's 
going on when the recipe is requested anywhere (be it directly on the bitbake 
command line or indirectly as a dependency) - the reason will be printed in 
the resulting error. The actual filename in this case is qemu-qoriq_git.bb 
meaning that the PN is unique, so you can do this for example:

PNBLACKLIST[qemu-qoriq] = "Not supported by XYZ corp"

Cheers,
Paul

-- 

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

Re: [yocto] BBMASK not working for me?

[chris warth]

Thank you, Paul.  I didn't know about bitbake -e.
As you predicted, it shows that an earlier layer is setting BBMASK
with equals, in this case the
meta-freescale layer.

BBMASK=".*openjre|.*openjdk"

Should I be mad at the vendor for being careless?
Is BBMASK_forcevariable the right workaround for this?
Or is there some layer priority scheme beyond the ordering in the
bblayers.conf file that I should playing nice with?

Thanks for your help, really!

- Chris

On Wed, Mar 1, 2017 at 5:03 PM, Paul Eggleton
 wrote:
> Hi Chris,
>
> On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
>> Thanks, all.  I wanted to share the solution.
>>
>> This vendor-supplied version of yocto looks like 2.0, so the space
>> separated expressions are not available.
>> After putting some print statements in cooker.py I discovered that
>> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
>> effect.  It was not until I modified BBMASK_forcevariable in my
>> conf/bblayers.conf  that I saw any change in behavior.
>>
>> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
>>
>> This inability to modify BBMASK unless using _forcevariable was also
>> noted last year.
>> https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html
>
> That sounds strange. Did you use bitbake -e | less to see where your non-
> forcevariable setting was being overridden? More than likely you have a layer
> or some other configuration you're bringing in and that's simply setting it
> with = at some point later in parsing than local.conf. The history of the
> BBMASK variable shown through bitbake -e will tell you exactly where that is.
>
> Cheers,
> Paul
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBMASK not working for me?

[Paul Eggleton]

Hi Chris,

On Thursday, 2 March 2017 11:31:42 AM NZDT chris warth wrote:
> Thanks, all.  I wanted to share the solution.
> 
> This vendor-supplied version of yocto looks like 2.0, so the space
> separated expressions are not available.
> After putting some print statements in cooker.py I discovered that
> appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
> effect.  It was not until I modified BBMASK_forcevariable in my
> conf/bblayers.conf  that I saw any change in behavior.
> 
> BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"
> 
> This inability to modify BBMASK unless using _forcevariable was also
> noted last year.
> https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html

That sounds strange. Did you use bitbake -e | less to see where your non-
forcevariable setting was being overridden? More than likely you have a layer 
or some other configuration you're bringing in and that's simply setting it 
with = at some point later in parsing than local.conf. The history of the 
BBMASK variable shown through bitbake -e will tell you exactly where that is.

Cheers,
Paul


-- 

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

Re: [yocto] update mechanisms

[Eystein Måløy Stenberg]

On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote:

On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:
> Hi Patrick,
>
> On 30/11/2016 15:59, Patrick Ohly wrote:
> > I've started a Wiki page
> > https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
> > moment, but might as well be mentioned already now.
>
> I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
> like to edit for better explanation on some parts. Should I try to edit
> directly the page or is it better to discuss it here ?

Use your own judgment. If its uncontroversial, the feel free to edit the
page directly, otherwise let's discuss it here.

If feel that putting information directly into the table is too limiting
(it should be brief), then feel free to start a complete section about
SWUpdate.

I'll do the same for swupd. Editing the sections should be possible
without conflicts, we just have to be more careful about editing the
table concurrently.


I updated the Mender part of the wiki now that the stable version Mender 
1.0 is released. These changes should not be controversial, but let me 
know if you disagree. We are planning to keep the Mender section 
up-to-date as we release new versions, as I think this is what you expect.


Are there any plans for next steps or is the wiki the "final state" in 
terms of integrating OTA updates in Yocto/OE?



--

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

Re: [yocto] BBMASK not working for me?

[chris warth]

Thanks, all.  I wanted to share the solution.

This vendor-supplied version of yocto looks like 2.0, so the space
separated expressions are not available.
After putting some print statements in cooker.py I discovered that
appending to BBMASK in conf/bblayers.conf or conf/local.conf has no
effect.  It was not until I modified BBMASK_forcevariable in my
conf/bblayers.conf  that I saw any change in behavior.

BBMASK_forcevariable = ".*openjre|.*openjdk|.*qemu_qoriq"

This inability to modify BBMASK unless using _forcevariable was also
noted last year.
https://lists.yoctoproject.org/pipermail/yocto/2016-September/032033.html
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBMASK not working for me?

[Andre McCurdy]

On Wed, Mar 1, 2017 at 12:15 PM, Jeremy A. Puhlman  wrote:
>
> On 3/1/2017 12:06 PM, chris warth wrote:
>
> Can anyone suggest why my BBMASK is not working?
> Maybe I'm not putting it into the right file?
> Did I construct the regex incorrectly?
>
> In my conf/bblayers.conf I have,
>
>  BBMASK .= "qemu"
>
> This basically concatenates qemu to what ever is already in BBMASK. It is a
> regex expression so you want to treat it as such.
> You want to likely do something like:
> BBMASK .= "|(qemu)"
>
> OTOH, qemu matches anythin with qemu in the path. You likely want to use the
> full filename:
> BBMASK .= "|(qemu_qoriq.bb)"

If you are using Yocto 2.1 or later, it's safer and easier to
construct BBMASK as set of space separated expressions rather than
trying to append to a single regex. e.g. in this case:

  BBMASK += "qemu_qoriq.bb"

> Then I wipe out the cache by deleting the "tmp/" directory.

There's no need to wipe out sstate or tmp to test this. If you try to
build a recipe which doesn't exist or is masked, you'll get an error
regardless of whether the recipe has been built previously.

> Now I would expect
> bitbake -n -c fetch qemu
> to give a 'Nothing PROVIDES' error.
>
> That is not what happens.   Instead it still completes normally.
>
> I am trying to ignore recipes like
>  meta-freescale/recipes-devtools/qemu/qemu_qoriq.bb
>
> Thanks in advance for any help.
>
> - Chris
>
> --
> Jeremy A. Puhlman
> jpuhl...@mvista.com
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBMASK not working for me?

[Jeremy A. Puhlman]

On 3/1/2017 12:06 PM, chris warth wrote:

Can anyone suggest why my BBMASK is not working?
Maybe I'm not putting it into the right file?
Did I construct the regex incorrectly?

In my conf/bblayers.conf I have,

 BBMASK .= "qemu"


This basically concatenates qemu to what ever is already in BBMASK. It 
is a regex expression so you want to treat it as such.

You want to likely do something like:
BBMASK .= "|(qemu)"

OTOH, qemu matches anythin with qemu in the path. You likely want to use 
the full filename:

BBMASK .= "|(qemu_qoriq.bb )"




Then I wipe out the cache by deleting the "tmp/" directory.

Now I would expect
bitbake -n -c fetch qemu
to give a 'Nothing PROVIDES' error.

That is not what happens.   Instead it still completes normally.

I am trying to ignore recipes like
 meta-freescale/recipes-devtools/qemu/qemu_qoriq.bb 



Thanks in advance for any help.

- Chris




--
Jeremy A. Puhlman
jpuhl...@mvista.com

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

[yocto] BBMASK not working for me?

[chris warth]

Can anyone suggest why my BBMASK is not working?
Maybe I'm not putting it into the right file?
Did I construct the regex incorrectly?

In my conf/bblayers.conf I have,

 BBMASK .= "qemu"

Then I wipe out the cache by deleting the "tmp/" directory.

Now I would expect
bitbake -n -c fetch qemu
to give a 'Nothing PROVIDES' error.

That is not what happens.   Instead it still completes normally.

I am trying to ignore recipes like
 meta-freescale/recipes-devtools/qemu/qemu_qoriq.bb

Thanks in advance for any help.

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

[yocto] Yocto create tar image Permissions error, tar: ./etc/gshadow+: Cannot open: Permission denied

[Tomáš Galbička]

Hello,

I am using Yocto Project Krogoth 2.1.2.

And sometimes it happens to me that in the final stage
create tar image do_package it will fire error bellow about wrong
permissions.

tar: ./etc/gshadow+: Cannot open: Permission denied

It happens when tar is doing archive.
I am doing always clean build and it happens like every 3 or 4 times.

I have not find any resolution for this anywhere.
It looks like build will set wrong permissions what that file or something
--.   1 user all-users0 Mar  1 18:10 ./etc/gshadow+


Have you encounter this issue?
Have it could have been solved?

Build Under CentOS 7

Thanks


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

Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation

[Patrick Ohly]

On Wed, 2017-03-01 at 16:01 +, Richard Purdie wrote:
> On Wed, 2017-03-01 at 16:51 +0100, Patrick Ohly wrote:
> > On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote:
> > > 
> > > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote:
> > > > 
> > > > Is the "build single distro for different machines" scenario that
> > > > I
> > > > described part of the Yocto Compliance 2.0? Should there be tests
> > > > for
> > > > it?
> > > Right now its not
> > Okay, so the goal is a bit less ambitious than I had thought. I
> > wonder
> > whether that's useful, because at least the problems Ostro and AGL
> > (at
> > least as far as I understood it from lurking on their mailing list)
> > had
> > only happened when trying to combine multiple BSP layers *and*
> > actually
> > using the different machines in the same distro.
> > 
> > > 
> > > but I'd consider it.
> > At least I'd find that useful - not sure about others ;-}
> 
> I do like the idea, I'm also mindful of walking before running...

But bumping the requirements in the Yocto Compliance often will irritate
people, because they will have to redo the compliance testing more
often.

> > >  The question is can we write an
> > > easy generic test for it,
> > It's a bit more complicated than the existing tests, but I think it
> > is
> > doable.
> > 
> > > 
> > > and also clearly phrase the criteria in the
> > > list of compliance questions with a binary yes/no answer?
> > Does the BSP layer only modify machine-specific packages and only
> > when
> > the MACHINE(s) defined by the BSP layer are selected? [yes/no]
> > 
> > The "only when" part is covered by the existing tests (because they
> > keep
> > MACHINE constant). The missing part is comparing different MACHINE
> > sstamps.
> 
> That seems reasonable, unless the layer in question applying for
> compatibility is not a BSP layer but thats a minor detail.
> 
> I'm open to more details on what the test would look like.

I guess I now have the AR to write such a test? ;-}

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[yocto] how to use yocto make Individual components

[Ekko]

i have got an image with yocto & bitbake,now, i want to figure out what
happend with the u-boot and kernel when i run the command "bitbake
target",how does these task modify the source code of u-boot and kernel.

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

Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation

[Richard Purdie]

On Wed, 2017-03-01 at 16:51 +0100, Patrick Ohly wrote:
> On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote:
> > 
> > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote:
> > > 
> > > Is the "build single distro for different machines" scenario that
> > > I
> > > described part of the Yocto Compliance 2.0? Should there be tests
> > > for
> > > it?
> > Right now its not
> Okay, so the goal is a bit less ambitious than I had thought. I
> wonder
> whether that's useful, because at least the problems Ostro and AGL
> (at
> least as far as I understood it from lurking on their mailing list)
> had
> only happened when trying to combine multiple BSP layers *and*
> actually
> using the different machines in the same distro.
> 
> > 
> > but I'd consider it.
> At least I'd find that useful - not sure about others ;-}

I do like the idea, I'm also mindful of walking before running...

> > 
> >  The question is can we write an
> > easy generic test for it,
> It's a bit more complicated than the existing tests, but I think it
> is
> doable.
> 
> > 
> > and also clearly phrase the criteria in the
> > list of compliance questions with a binary yes/no answer?
> Does the BSP layer only modify machine-specific packages and only
> when
> the MACHINE(s) defined by the BSP layer are selected? [yes/no]
> 
> The "only when" part is covered by the existing tests (because they
> keep
> MACHINE constant). The missing part is comparing different MACHINE
> sstamps.

That seems reasonable, unless the layer in question applying for
compatibility is not a BSP layer but thats a minor detail.

I'm open to more details on what the test would look like.

Cheers,

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

Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation

[Patrick Ohly]

On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote:
> On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote:
> > Is the "build single distro for different machines" scenario that I
> > described part of the Yocto Compliance 2.0? Should there be tests for
> > it?
> 
> Right now its not

Okay, so the goal is a bit less ambitious than I had thought. I wonder
whether that's useful, because at least the problems Ostro and AGL (at
least as far as I understood it from lurking on their mailing list) had
only happened when trying to combine multiple BSP layers *and* actually
using the different machines in the same distro.

> but I'd consider it.

At least I'd find that useful - not sure about others ;-}

>  The question is can we write an
> easy generic test for it,

It's a bit more complicated than the existing tests, but I think it is
doable.

> and also clearly phrase the criteria in the
> list of compliance questions with a binary yes/no answer?

Does the BSP layer only modify machine-specific packages and only when
the MACHINE(s) defined by the BSP layer are selected? [yes/no]

The "only when" part is covered by the existing tests (because they keep
MACHINE constant). The missing part is comparing different MACHINE
sstamps.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation

[Richard Purdie]

On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote:
> On Wed, 2017-03-01 at 04:00 +, Richard Purdie wrote:
> > 
> > On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote:
> > > 
> > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
> > > > 
> > > > 
> > > > common.test_signatures: Test executed in BSP and DISTRO layers
> > > > to
> > > > review
> > > > doesn't comes with recipes that changes the signatures.
> > > I have a question about the goal for this test: is it meant to
> > > detect
> > > layers which incorrectly change the signatures of allarch recipes
> > > or
> > > recipes which share the same tune flags with other machines?
> > > 
> > > Let's take MACHINE=edison as an example.
> > The test is not for these things. Its using the sstate signatures
> > for
> > something different compared to those other tests.
> > 
> > The idea is that if you have a set of layers and generate the
> > signatures for world, then you add say a BSP layer but do not
> > select
> > that MACHINE, the signatures should remain unchanged.
> That's useful too, of course.
> 
> Is the "build single distro for different machines" scenario that I
> described part of the Yocto Compliance 2.0? Should there be tests for
> it?

Right now its not but I'd consider it. The question is can we write an
easy generic test for it, and also clearly phrase the criteria in the
list of compliance questions with a binary yes/no answer?

Cheers,

Richard

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

Re: [linux-yocto] [meta-intel] update kernel in local.conf

[Mikko Ylinen]

Hi,

I accidentally ran into this too and looked into it a bit.

There are two kernels in the package feedwhich Provides:the same
functionality. The one that's built afterwards is tracked in pkgdata
as runtime-reverse but the package manager has installed the other
(returned by image_list_installed_packages).

An easy workaround for me was to remove the undesired kernel-* packages from
deploy/ipk before do_rootfs.

-- Mikko

On 28/02/17 18:31, Wold, Saul wrote:

There is an existing bug open against a similar issue:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10597

It's being investigated.

Sau!

On Fri, 2017-02-24 at 11:02 +0200, Ran Shalit wrote:

Hello,

I wanted to try update to rt-kernel to I added the following in
local.conf:

#PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
#PREFERRED_VERSION_linux-yocto ?= "4.4%"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
PREFERRED_VERSION_linux-yocto-rt ?= "4.4%"

Everything compiled well with
bitbake core-image-sato-sdk

I then decided to return to the regular linux by doing:
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "4.4%"
#PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
#PREFERRED_VERSION_linux-yocto-rt ?= "4.4%"

But now I get errors as following:

NOTE: Preparing RunQueue
WARNING: /media/sde/yocto/poky/meta/recipes-sato/images/core-image-
sato-sdk.bb.do_rootfs
is tainted from a forced run
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: core-image-sato-sdk-1.0-r0 do_rootfs: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this
exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:

  0001:
  *** 0002:license_create_manifest(d)
  0003:
File: '/media/sde/yocto/poky/meta/classes/license.bbclass', lineno:
48, function: license_create_manifest
  0044:pkg_dic = {}
  0045:for pkg in sorted(image_list_installed_packages(d)):
  0046:pkg_info = os.path.join(d.getVar('PKGDATA_DIR',
True),
  0047:'runtime-reverse', pkg)
  *** 0048:pkg_name = os.path.basename(os.readlink(pkg_info))
  0049:
  0050:pkg_dic[pkg_name] =
oe.packagedata.read_pkgdatafile(pkg_info)
  0051:if not "LICENSE" in pkg_dic[pkg_name].keys():
  0052:pkg_lic_name = "LICENSE_" + pkg_name
Exception: OSError: [Errno 2] No such file or directory:
'/media/sde/yocto/poky/build/tmp/sysroots/congatec-qa3-
64/pkgdata/runtime-reverse/kernel-4.4.26-rt19-yocto-preempt-rt'

ERROR: core-image-sato-sdk-1.0-r0 do_rootfs: Function failed:
license_create_manifest
ERROR: Logfile of failure stored in:
/media/sde/yocto/poky/build/tmp/work/congatec_qa3_64-poky-linux/core-
image-sato-sdk/1.0-r0/temp/log.do_rootfs.13106
ERROR: Task 9 (/media/sde/yocto/poky/meta/recipes-sato/images/core-
image-sato-sdk.bb,
do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 7025 tasks of which 7024 didn't need
to
be rerun and 1 failed.

Does anyone have any idea ?
Ran


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

Re: [yocto] error while compiling external module in Krogoth branch

[praveen vattipalli]

Hi,

Already patched is  applied in latest Yocto source.

Thanks,
Praveen.

On Tue, Feb 28, 2017 at 8:31 PM, Khem Raj  wrote:

>
> On Tue, Feb 28, 2017 at 5:27 AM praveen vattipalli 
> wrote:
>
>> Hi,
>> I am using krogoth branch of meta-altera.
>> in meta/classes/kernel-yocto.bbclass file
>> SRCTREECOVEREDTASKS += "do_kernel_configme do_validate_branches
>> do_kernel_configcheck do_kernel_checkout do_shared_workdir do_fetch
>> do_unpack do_patch"
>>
>> if i remove "do_shared_workdir" . it worked. is this the right way.
>>
>
>
> Please send this as a patch
>
>>
>> Thanks.native']
>> NOTE: Runtime target 'packagegroup-meshwifi' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: ['packagegroup-meshwifi',
>> 'plumewifi', 'openvswitch-native', 'util-linux-uuidgen-native']
>> ERROR: Required build target 'comcast-br
>>
>> On Tue, Feb 28, 2017 at 12:46 PM, Khem Raj  wrote:
>>
>>
>> On Tue, Feb 21, 2017 at 6:31 AM praveen vattipalli <
>> praveen.v...@gmail.com> wrote:
>>
>> Hi All,
>> I am using poky-krogoth source and meta-altera layer. I am building
>> kernel locally using externalsrc. while building external module i am
>> getting error.
>>
>>
>> Which branch of meta-altera are you using
>>
>>
>>
>>
>> ERROR: Task do_make_scripts in /home/praveenk/source/
>> platform/build/../meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb 
>> depends
>> upon non-existent task do_shared_workdir in /home/praveenk/source/
>> platform/build/../meta-altera/recipes-kernel/linux/linux-
>> altera-ltsi_4.1.22.bb
>> ERROR: Command execution failed: 1
>>
>> linux.bb contains
>>
>> LINUX_VERSION = "4.1.22"
>> LINUX_VERSION_SUFFIX = "-ltsi"
>>
>> include linux-altera.inc
>>
>> SRC_URI = "file://${EXTERNALSRC}"
>>
>> LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=
>> d7810fab7487fb0aad327b76f1be7cd7"
>>
>> BUILD_DEFCONFIG = "socfpga_defconfig"
>> EXTERNALSRC = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
>> EXTERNALSRC_BUILD = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
>>
>> SRCREV_pn-${PN} = "${AUTOREV}"
>>
>> S= "${EXTERNALSRC}"
>>
>> hello-mod.bb  contains
>>
>> SUMMARY = "Example of how to build an external Linux kernel module"
>> LICENSE = "GPLv2"
>> LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
>>
>> inherit module
>>
>> SRC_URI = "file://Makefile \
>>file://hello.c \
>>file://COPYING \
>>   "
>>
>>
>> S = "${WORKDIR}"
>>
>> # The inherit of module.bbclass will automatically name module packages
>> with
>> # "kernel-module-" prefix as required by the oe-core build environment.
>> ~
>>
>>
>> Am I missing anything?
>>
>> Thanks,
>> Praveen.
>> --
>> ___
>> 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] Using armcc in Yocto

[Michael Schwarcz]

Hello,

I have an application which I am building for Yocto using the POKY toolchain 
(arm-poky-linux-gnueabi) and running on a BeagleBoneBlack device.

Is it possible to compile using the ARM compiler (armcc, armlink) and still 
target the linux-yocto OS?
Is it something that was done before?

Thanks,
Michael Schwarcz
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-rockchip][PATCH 2/2] recipes-graphics: Add recipe for libdrm-rk

[Jacob Chen]

It's rockchip modified libdrm, we can call rga by this libdrm.

Our development work in libdrm has not yet completed, so it have not pushed to 
the upstream.
We temporarily maintain it by ourself.
---
 recipes-graphics/libdrm/libdrm_rk.bb | 47 
 1 file changed, 47 insertions(+)
 create mode 100644 recipes-graphics/libdrm/libdrm_rk.bb

diff --git a/recipes-graphics/libdrm/libdrm_rk.bb 
b/recipes-graphics/libdrm/libdrm_rk.bb
new file mode 100644
index 000..6af5b6f
--- /dev/null
+++ b/recipes-graphics/libdrm/libdrm_rk.bb
@@ -0,0 +1,47 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SECTION = "x11/base"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+PROVIDES = "drm"
+DEPENDS = "libpthread-stubs udev libpciaccess"
+
+SRCREV = "${AUTOREV}"
+SRCBRANCH ?= "rockchip-2.4.74"
+SRC_URI = 
"git://github.com/rockchip-linux/libdrm-rockchip.git;branch=${SRCBRANCH}"
+
+S = "${WORKDIR}/git"
+
+inherit autotools pkgconfig
+
+EXTRA_OECONF += "--disable-cairo-tests \
+ --enable-omap-experimental-api \
+ --enable-install-test-programs \
+ --disable-manpages \
+ --disable-valgrind \
+--enable-rockchip-experimental-api \
+"
+
+ALLOW_EMPTY_${PN}-drivers = "1"
+PACKAGES =+ "${PN}-tests ${PN}-drivers ${PN}-radeon ${PN}-nouveau ${PN}-omap \
+ ${PN}-intel ${PN}-exynos ${PN}-kms ${PN}-freedreno ${PN}-amdgpu \
+${PN}-rockchip "
+
+RRECOMMENDS_${PN}-drivers = "${PN}-radeon ${PN}-nouveau ${PN}-omap ${PN}-intel 
\
+ ${PN}-exynos ${PN}-freedreno ${PN}-amdgpu 
${PN}-rockchip"
+
+FILES_${PN}-tests = "${bindir}/*"
+FILES_${PN}-radeon = "${libdir}/libdrm_radeon.so.*"
+FILES_${PN}-nouveau = "${libdir}/libdrm_nouveau.so.*"
+FILES_${PN}-omap = "${libdir}/libdrm_omap.so.*"
+FILES_${PN}-intel = "${libdir}/libdrm_intel.so.*"
+FILES_${PN}-exynos = "${libdir}/libdrm_exynos.so.*"
+FILES_${PN}-kms = "${libdir}/libkms*.so.*"
+FILES_${PN}-freedreno = "${libdir}/libdrm_freedreno.so.*"
+FILES_${PN}-amdgpu = "${libdir}/libdrm_amdgpu.so.*"
+FILES_${PN}-rockchip = "${libdir}/libdrm_rockchip.so.*"
+
+do_configure_prepend() {
+   ${S}/autogen.sh ${CONFIGUREOPTS} ${EXTRA_OECONF}
+}
-- 
2.7.4

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

[yocto] [meta-rockchip][PATCH 1/2] udev-extraconf: add rockchip specific rules

[Jacob Chen]

This rules file help to set suitable mode for device node.

vpu-service, vpu_service, rkvdec, hevc-service are different ip.
mali0 is mali-midgard and mali is mali-utgard.

Signed-off-by: Jacob Chen 
---
 recipes-core/udev/udev-extraconf/10-rk.rules |  6 ++
 recipes-core/udev/udev-extraconf_%.bbappend  | 13 +
 2 files changed, 19 insertions(+)
 create mode 100644 recipes-core/udev/udev-extraconf/10-rk.rules
 create mode 100644 recipes-core/udev/udev-extraconf_%.bbappend

diff --git a/recipes-core/udev/udev-extraconf/10-rk.rules 
b/recipes-core/udev/udev-extraconf/10-rk.rules
new file mode 100644
index 000..2308c9a
--- /dev/null
+++ b/recipes-core/udev/udev-extraconf/10-rk.rules
@@ -0,0 +1,6 @@
+KERNEL=="hevc-service", MODE="0666", GROUP="video"
+KERNEL=="rkvdec", MODE="0666", GROUP="video"
+KERNEL=="mali0", MODE="0666", GROUP="video"
+KERNEL=="mali", MODE="0666", GROUP="video"
+KERNEL=="vpu-service", MODE="0666", GROUP="video"
+KERNEL=="vpu_service", MODE="0666", GROUP="video"
diff --git a/recipes-core/udev/udev-extraconf_%.bbappend 
b/recipes-core/udev/udev-extraconf_%.bbappend
new file mode 100644
index 000..4691a31
--- /dev/null
+++ b/recipes-core/udev/udev-extraconf_%.bbappend
@@ -0,0 +1,13 @@
+# extra configuration udev rules
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append = " \
+file://10-rk.rules \
+"
+
+do_install_prepend () {
+   install -d ${D}${sysconfdir}/udev/rules.d
+   install -m 0644 ${WORKDIR}/*.rules ${D}${sysconfdir}/udev/rules.d
+}
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
-- 
2.7.4

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

Re: [yocto] [PATCH] recipes-graphics: Add recipe for libdrm-rk

[Jacob Chen]

oh， i forget to add meta-rockchip too.

2017-03-01 18:30 GMT+08:00 Jacob Chen :
> It's rockchip modified libdrm, we can call rga by this libdrm.
>
> Our development work in libdrm has not yet completed, so it have not pushed 
> to the upstream.
> We temporarily maintain it by ourself.
> ---
>  recipes-graphics/libdrm/libdrm_rk.bb | 47 
> 
>  1 file changed, 47 insertions(+)
>  create mode 100644 recipes-graphics/libdrm/libdrm_rk.bb
>
> diff --git a/recipes-graphics/libdrm/libdrm_rk.bb 
> b/recipes-graphics/libdrm/libdrm_rk.bb
> new file mode 100644
> index 000..6af5b6f
> --- /dev/null
> +++ b/recipes-graphics/libdrm/libdrm_rk.bb
> @@ -0,0 +1,47 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +SECTION = "x11/base"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = 
> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
> +PROVIDES = "drm"
> +DEPENDS = "libpthread-stubs udev libpciaccess"
> +
> +SRCREV = "${AUTOREV}"
> +SRCBRANCH ?= "rockchip-2.4.74"
> +SRC_URI = 
> "git://github.com/rockchip-linux/libdrm-rockchip.git;branch=${SRCBRANCH}"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit autotools pkgconfig
> +
> +EXTRA_OECONF += "--disable-cairo-tests \
> + --enable-omap-experimental-api \
> + --enable-install-test-programs \
> + --disable-manpages \
> + --disable-valgrind \
> +--enable-rockchip-experimental-api \
> +"
> +
> +ALLOW_EMPTY_${PN}-drivers = "1"
> +PACKAGES =+ "${PN}-tests ${PN}-drivers ${PN}-radeon ${PN}-nouveau ${PN}-omap 
> \
> + ${PN}-intel ${PN}-exynos ${PN}-kms ${PN}-freedreno ${PN}-amdgpu 
> \
> +${PN}-rockchip "
> +
> +RRECOMMENDS_${PN}-drivers = "${PN}-radeon ${PN}-nouveau ${PN}-omap 
> ${PN}-intel \
> + ${PN}-exynos ${PN}-freedreno ${PN}-amdgpu 
> ${PN}-rockchip"
> +
> +FILES_${PN}-tests = "${bindir}/*"
> +FILES_${PN}-radeon = "${libdir}/libdrm_radeon.so.*"
> +FILES_${PN}-nouveau = "${libdir}/libdrm_nouveau.so.*"
> +FILES_${PN}-omap = "${libdir}/libdrm_omap.so.*"
> +FILES_${PN}-intel = "${libdir}/libdrm_intel.so.*"
> +FILES_${PN}-exynos = "${libdir}/libdrm_exynos.so.*"
> +FILES_${PN}-kms = "${libdir}/libkms*.so.*"
> +FILES_${PN}-freedreno = "${libdir}/libdrm_freedreno.so.*"
> +FILES_${PN}-amdgpu = "${libdir}/libdrm_amdgpu.so.*"
> +FILES_${PN}-rockchip = "${libdir}/libdrm_rockchip.so.*"
> +
> +do_configure_prepend() {
> +   ${S}/autogen.sh ${CONFIGUREOPTS} ${EXTRA_OECONF}
> +}
> --
> 2.7.4
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] udev-extraconf: add rockchip specific rules

[Jacob Chen]

oh， i forget to add meta-rockchip too.

2017-03-01 18:23 GMT+08:00 Jacob Chen :
> This rules file help to set suitable mode for device node.
>
> vpu-service, vpu_service, rkvdec, hevc-service are different ip.
> mali0 is mali-midgard and mali is mali-utgard.
>
> Signed-off-by: Jacob Chen 
> ---
>  recipes-core/udev/udev-extraconf/10-rk.rules |  6 ++
>  recipes-core/udev/udev-extraconf_%.bbappend  | 13 +
>  2 files changed, 19 insertions(+)
>  create mode 100644 recipes-core/udev/udev-extraconf/10-rk.rules
>  create mode 100644 recipes-core/udev/udev-extraconf_%.bbappend
>
> diff --git a/recipes-core/udev/udev-extraconf/10-rk.rules 
> b/recipes-core/udev/udev-extraconf/10-rk.rules
> new file mode 100644
> index 000..2308c9a
> --- /dev/null
> +++ b/recipes-core/udev/udev-extraconf/10-rk.rules
> @@ -0,0 +1,6 @@
> +KERNEL=="hevc-service", MODE="0666", GROUP="video"
> +KERNEL=="rkvdec", MODE="0666", GROUP="video"
> +KERNEL=="mali0", MODE="0666", GROUP="video"
> +KERNEL=="mali", MODE="0666", GROUP="video"
> +KERNEL=="vpu-service", MODE="0666", GROUP="video"
> +KERNEL=="vpu_service", MODE="0666", GROUP="video"
> diff --git a/recipes-core/udev/udev-extraconf_%.bbappend 
> b/recipes-core/udev/udev-extraconf_%.bbappend
> new file mode 100644
> index 000..4691a31
> --- /dev/null
> +++ b/recipes-core/udev/udev-extraconf_%.bbappend
> @@ -0,0 +1,13 @@
> +# extra configuration udev rules
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +SRC_URI_append = " \
> +file://10-rk.rules \
> +"
> +
> +do_install_prepend () {
> +   install -d ${D}${sysconfdir}/udev/rules.d
> +   install -m 0644 ${WORKDIR}/*.rules ${D}${sysconfdir}/udev/rules.d
> +}
> +
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
> --
> 2.7.4
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] recipes-graphics: Add recipe for libdrm-rk

[Jacob Chen]

It's rockchip modified libdrm, we can call rga by this libdrm.

Our development work in libdrm has not yet completed, so it have not pushed to 
the upstream.
We temporarily maintain it by ourself.
---
 recipes-graphics/libdrm/libdrm_rk.bb | 47 
 1 file changed, 47 insertions(+)
 create mode 100644 recipes-graphics/libdrm/libdrm_rk.bb

diff --git a/recipes-graphics/libdrm/libdrm_rk.bb 
b/recipes-graphics/libdrm/libdrm_rk.bb
new file mode 100644
index 000..6af5b6f
--- /dev/null
+++ b/recipes-graphics/libdrm/libdrm_rk.bb
@@ -0,0 +1,47 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SECTION = "x11/base"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+PROVIDES = "drm"
+DEPENDS = "libpthread-stubs udev libpciaccess"
+
+SRCREV = "${AUTOREV}"
+SRCBRANCH ?= "rockchip-2.4.74"
+SRC_URI = 
"git://github.com/rockchip-linux/libdrm-rockchip.git;branch=${SRCBRANCH}"
+
+S = "${WORKDIR}/git"
+
+inherit autotools pkgconfig
+
+EXTRA_OECONF += "--disable-cairo-tests \
+ --enable-omap-experimental-api \
+ --enable-install-test-programs \
+ --disable-manpages \
+ --disable-valgrind \
+--enable-rockchip-experimental-api \
+"
+
+ALLOW_EMPTY_${PN}-drivers = "1"
+PACKAGES =+ "${PN}-tests ${PN}-drivers ${PN}-radeon ${PN}-nouveau ${PN}-omap \
+ ${PN}-intel ${PN}-exynos ${PN}-kms ${PN}-freedreno ${PN}-amdgpu \
+${PN}-rockchip "
+
+RRECOMMENDS_${PN}-drivers = "${PN}-radeon ${PN}-nouveau ${PN}-omap ${PN}-intel 
\
+ ${PN}-exynos ${PN}-freedreno ${PN}-amdgpu 
${PN}-rockchip"
+
+FILES_${PN}-tests = "${bindir}/*"
+FILES_${PN}-radeon = "${libdir}/libdrm_radeon.so.*"
+FILES_${PN}-nouveau = "${libdir}/libdrm_nouveau.so.*"
+FILES_${PN}-omap = "${libdir}/libdrm_omap.so.*"
+FILES_${PN}-intel = "${libdir}/libdrm_intel.so.*"
+FILES_${PN}-exynos = "${libdir}/libdrm_exynos.so.*"
+FILES_${PN}-kms = "${libdir}/libkms*.so.*"
+FILES_${PN}-freedreno = "${libdir}/libdrm_freedreno.so.*"
+FILES_${PN}-amdgpu = "${libdir}/libdrm_amdgpu.so.*"
+FILES_${PN}-rockchip = "${libdir}/libdrm_rockchip.so.*"
+
+do_configure_prepend() {
+   ${S}/autogen.sh ${CONFIGUREOPTS} ${EXTRA_OECONF}
+}
-- 
2.7.4

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

[yocto] [PATCH] udev-extraconf: add rockchip specific rules

[Jacob Chen]

This rules file help to set suitable mode for device node.

vpu-service, vpu_service, rkvdec, hevc-service are different ip.
mali0 is mali-midgard and mali is mali-utgard.

Signed-off-by: Jacob Chen 
---
 recipes-core/udev/udev-extraconf/10-rk.rules |  6 ++
 recipes-core/udev/udev-extraconf_%.bbappend  | 13 +
 2 files changed, 19 insertions(+)
 create mode 100644 recipes-core/udev/udev-extraconf/10-rk.rules
 create mode 100644 recipes-core/udev/udev-extraconf_%.bbappend

diff --git a/recipes-core/udev/udev-extraconf/10-rk.rules 
b/recipes-core/udev/udev-extraconf/10-rk.rules
new file mode 100644
index 000..2308c9a
--- /dev/null
+++ b/recipes-core/udev/udev-extraconf/10-rk.rules
@@ -0,0 +1,6 @@
+KERNEL=="hevc-service", MODE="0666", GROUP="video"
+KERNEL=="rkvdec", MODE="0666", GROUP="video"
+KERNEL=="mali0", MODE="0666", GROUP="video"
+KERNEL=="mali", MODE="0666", GROUP="video"
+KERNEL=="vpu-service", MODE="0666", GROUP="video"
+KERNEL=="vpu_service", MODE="0666", GROUP="video"
diff --git a/recipes-core/udev/udev-extraconf_%.bbappend 
b/recipes-core/udev/udev-extraconf_%.bbappend
new file mode 100644
index 000..4691a31
--- /dev/null
+++ b/recipes-core/udev/udev-extraconf_%.bbappend
@@ -0,0 +1,13 @@
+# extra configuration udev rules
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append = " \
+file://10-rk.rules \
+"
+
+do_install_prepend () {
+   install -d ${D}${sysconfdir}/udev/rules.d
+   install -m 0644 ${WORKDIR}/*.rules ${D}${sysconfdir}/udev/rules.d
+}
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
-- 
2.7.4

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