Re: [yocto] Using Yocto with NXP QorIQ Processors

[Zhenhua Luo]

Hi Chris,

The QorIQ SDK uses recent Yocto version, e.g. the SDK 2.0  is based on Yocto 
2.0(Jethro).  When the SDK is formally released in Q2/2016, the SDK recipes 
will be upstreamed to master of community layers.

You can use either SDK ISOs available in NXP official 
website(www.nxp.com) or the BSP layers in Yocto website 
(http://git.yoctoproject.org/cgit.cgi/).

* QorIQ ARM targets: meta-fsl-arm

* QorIQ PPC targets: meta-fsl-ppc


Best Regards,

Zhenhua

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Chris Trobridge
Sent: Monday, April 18, 2016 9:58 PM
To: yocto@yoctoproject.org
Subject: [yocto] Using Yocto with NXP QorIQ Processors

Has anyone attempted to use the Qoriq BSP layers with them main Yocto release 
rather than the NXP (ex Freescale) SDK they come bundled in?

I ask because the NXP SDK is somewhat behind the main Yocto release schedule.

It should be easier to port the BSP to the current Yocto but I have no idea 
what issues I am likely to hit.

I will try this at some point when I have enough free time but for planning 
purposes I would interested in how anyone else has got on attempting this.

Are Qoriq users restricted to the official SDK or would they get third-party 
support?

Regards,
Chris

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

Re: [yocto] [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Christopher Larson]

On Mon, Apr 18, 2016 at 5:50 PM Khem Raj  wrote:

>
> On Apr 18, 2016 3:51 PM, "Richard Purdie" <
> richard.pur...@linuxfoundation.org> wrote:
> >
> > On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> > > Can we have a possibility to select  field like "affected version"
> > > and have it such that multiple versions can be specified
> >
> > That doesn't really allow us to mark version X as merged and version Y
> > as pending review though and as I understand it, that is the real issue
> > atm :/.
>
> May be bugzilla can be programmed to have such triggers. Having separate
> bug is not a good looking solution
>

I'd agree that it's not ideal, but it's definitely a *common* solution in
many bug tracking systems, since it's usually the only way to maintain
separate states for each version. I know I've seen it done that way in
bugzilla, jira, and others over the years.

There may be something better out there, and if we can find it, great, but
I think separate issues is better than not addressing the issue at all, but
only if the tooling is good enough to help reduce overhead on the part of
the devs dealing with it. Issue tracker overhead gets pretty frustrating at
times.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] linux-yocto: do_compile failed when DEFAULTTUNE = "aarch64_be"

[Robert Yang]

Filed:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=9480
linux-yocto: make it work with arm big endian

// Robert

On 04/19/2016 09:32 AM, Bruce Ashfield wrote:

On 2016-04-18 9:30 PM, Robert Yang wrote:



On 04/18/2016 08:17 PM, Bruce Ashfield wrote:

On 2016-04-18 5:47 AM, Robert Yang wrote:


Reproducer: (both in YP 2.1 and 2.0.1):

MACHINE = "qemuarm64"
DEFAULTTUNE = "aarch64_be"

$ bitbake linux-yocto


aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file usr/initramfs_data.o
make[3]: *** [usr/built-in.o] Error 1
   CC  kernel/exec_domain.o
make[2]: *** [usr] Error 2
make[2]: *** Waiting for unfinished jobs
   OBJCOPY arch/arm64/kernel/vdso/vdso.so
   VDSOSYM arch/arm64/kernel/vdso/vdso-offsets.h
   CC  security/keys/keyring.o
   CC  kernel/panic.o
   CC  kernel/cpu.o
   AS  arch/arm64/kernel/vdso/vdso.o
   CC  kernel/exit.o
   CC  kernel/softirq.o
   LD  security/integrity/integrity.o
   CC  kernel/resource.o
aarch64_be-poky-linux-ld.bfd: security/integrity/iint.o: compiled for a
little endian system and target is big endian  CC  fs/open.o

aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file security/integrity/iint.o
make[4]: *** [security/integrity/integrity.o] Error 1
make[3]: *** [security/integrity] Error 2
make[3]: *** Waiting for unfinished jobs

[snip]
   LD  arch/arm64/mm/built-in.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/dma-mapping.o: compiled for
a little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/dma-mapping.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/extable.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/extable.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/fault.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/fault.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/init.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/init.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/cache.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/cache.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/copypage.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/copypage.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/flush.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/flush.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/ioremap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/ioremap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pgd.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pgd.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmu.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmu.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/context.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/context.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/proc.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/proc.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pageattr.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pageattr.o
make[3]: *** [arch/arm64/mm/built-in.o] Error 1
make[2]: *** [arch/arm64/mm] Error 2
   CC  fs/exec.o
[snip]

Any comments, please ?


big endian ARM64 is not something we've been building or testing. The
default for that BSP is LE, and if you want to build the kernel big
endian, you'll need to adjust the kernel configuration (since the
kernel build doesn't know, or care, about the default tune).


Thanks, do you think that we need make it work or not in YP 2.2 ?
If yes, I 

Re: [linux-yocto] linux-yocto: do_compile failed when DEFAULTTUNE = "aarch64_be"

[Bruce Ashfield]

On 2016-04-18 9:30 PM, Robert Yang wrote:



On 04/18/2016 08:17 PM, Bruce Ashfield wrote:

On 2016-04-18 5:47 AM, Robert Yang wrote:


Reproducer: (both in YP 2.1 and 2.0.1):

MACHINE = "qemuarm64"
DEFAULTTUNE = "aarch64_be"

$ bitbake linux-yocto


aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file usr/initramfs_data.o
make[3]: *** [usr/built-in.o] Error 1
   CC  kernel/exec_domain.o
make[2]: *** [usr] Error 2
make[2]: *** Waiting for unfinished jobs
   OBJCOPY arch/arm64/kernel/vdso/vdso.so
   VDSOSYM arch/arm64/kernel/vdso/vdso-offsets.h
   CC  security/keys/keyring.o
   CC  kernel/panic.o
   CC  kernel/cpu.o
   AS  arch/arm64/kernel/vdso/vdso.o
   CC  kernel/exit.o
   CC  kernel/softirq.o
   LD  security/integrity/integrity.o
   CC  kernel/resource.o
aarch64_be-poky-linux-ld.bfd: security/integrity/iint.o: compiled for a
little endian system and target is big endian  CC  fs/open.o

aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file security/integrity/iint.o
make[4]: *** [security/integrity/integrity.o] Error 1
make[3]: *** [security/integrity] Error 2
make[3]: *** Waiting for unfinished jobs

[snip]
   LD  arch/arm64/mm/built-in.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/dma-mapping.o: compiled for
a little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/dma-mapping.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/extable.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/extable.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/fault.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/fault.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/init.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/init.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/cache.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/cache.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/copypage.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/copypage.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/flush.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/flush.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/ioremap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/ioremap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pgd.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pgd.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmu.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmu.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/context.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/context.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/proc.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/proc.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pageattr.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pageattr.o
make[3]: *** [arch/arm64/mm/built-in.o] Error 1
make[2]: *** [arch/arm64/mm] Error 2
   CC  fs/exec.o
[snip]

Any comments, please ?


big endian ARM64 is not something we've been building or testing. The
default for that BSP is LE, and if you want to build the kernel big
endian, you'll need to adjust the kernel configuration (since the
kernel build doesn't know, or care, about the default tune).


Thanks, do you think that we need make it work or not in YP 2.2 ?
If yes, I will fire an enhancement request track it.


It is worth adding as an enhancement, that way we can prioritize it
and decide if it does (or doesn't) fit in 2.2

Bruce



// 

Re: [linux-yocto] linux-yocto: do_compile failed when DEFAULTTUNE = "aarch64_be"

[Robert Yang]

On 04/18/2016 08:17 PM, Bruce Ashfield wrote:

On 2016-04-18 5:47 AM, Robert Yang wrote:


Reproducer: (both in YP 2.1 and 2.0.1):

MACHINE = "qemuarm64"
DEFAULTTUNE = "aarch64_be"

$ bitbake linux-yocto


aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file usr/initramfs_data.o
make[3]: *** [usr/built-in.o] Error 1
   CC  kernel/exec_domain.o
make[2]: *** [usr] Error 2
make[2]: *** Waiting for unfinished jobs
   OBJCOPY arch/arm64/kernel/vdso/vdso.so
   VDSOSYM arch/arm64/kernel/vdso/vdso-offsets.h
   CC  security/keys/keyring.o
   CC  kernel/panic.o
   CC  kernel/cpu.o
   AS  arch/arm64/kernel/vdso/vdso.o
   CC  kernel/exit.o
   CC  kernel/softirq.o
   LD  security/integrity/integrity.o
   CC  kernel/resource.o
aarch64_be-poky-linux-ld.bfd: security/integrity/iint.o: compiled for a
little endian system and target is big endian  CC  fs/open.o

aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file security/integrity/iint.o
make[4]: *** [security/integrity/integrity.o] Error 1
make[3]: *** [security/integrity] Error 2
make[3]: *** Waiting for unfinished jobs

[snip]
   LD  arch/arm64/mm/built-in.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/dma-mapping.o: compiled for
a little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/dma-mapping.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/extable.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/extable.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/fault.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/fault.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/init.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/init.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/cache.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/cache.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/copypage.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/copypage.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/flush.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/flush.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/ioremap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/ioremap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pgd.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pgd.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmu.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmu.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/context.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/context.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/proc.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/proc.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pageattr.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pageattr.o
make[3]: *** [arch/arm64/mm/built-in.o] Error 1
make[2]: *** [arch/arm64/mm] Error 2
   CC  fs/exec.o
[snip]

Any comments, please ?


big endian ARM64 is not something we've been building or testing. The
default for that BSP is LE, and if you want to build the kernel big
endian, you'll need to adjust the kernel configuration (since the
kernel build doesn't know, or care, about the default tune).


Thanks, do you think that we need make it work or not in YP 2.2 ?
If yes, I will fire an enhancement request track it.

// Robert



Cheers,

Bruce







--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org

Re: [yocto] [OE-core] [RFT] GCC 6 Recipes

[Khem Raj]

On Mon, Apr 18, 2016 at 12:48 PM Dan McGregor 
wrote:

> On 17 April 2016 at 23:15, Khem Raj  wrote:
> > Hello all,
> >
> > I have put together a potential gcc6 upgrade recipe set, and pushed the
> branch to tree here
> >
> >
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-6
> >
> > and also at github fork of mine.
> >
> > https://github.com/kraj/openembedded-core/tree/kraj/master
> >
> > You need to set
> >
> > GCCVERSION = “6.%”
> >
> > in local.conf to enable it.
> >
> >
> > There are few recipes in OE-Core which still don’t compile e.g.
> >
> > see
> >
> > http://errors.yoctoproject.org/Errors/Build/14782/
> >
> > any help in fixing them or otherwise fixing other layers is appreciated.
> >
> > gcc6 is a major release for some info see
> >
> > https://gcc.gnu.org/gcc-6/changes.html
> >
> > and porting guide
> >
> > https://gcc.gnu.org/gcc-6/porting_to.html
> >
> >
>
> I haven't built an image with gcc6 as the compiler yet, but I did
> check out your branch to try building with gcc 6 as the host compiler
> (Fedora 24). I needed a few more fixes, available at
> http://git.openembedded.org/openembedded-core-contrib/log/?h=dankm/gcc-6.
> I fixed lzop, pkgconfig, and disabled werror on binutils.
> core-image-minimal appears to be well on its way to building.
>
>
I had fixed lzop locally meanwhile. I cherry-picked the pkgconfig and
binutils fixes into my branch


>
> > Thanks
> >
> > -Khem
> >
> > --
> > ___
> > Openembedded-core mailing list
> > openembedded-c...@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

On Apr 18, 2016 3:51 PM, "Richard Purdie" <
richard.pur...@linuxfoundation.org> wrote:
>
> On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> > Can we have a possibility to select  field like "affected version"
> > and have it such that multiple versions can be specified
>
> That doesn't really allow us to mark version X as merged and version Y
> as pending review though and as I understand it, that is the real issue
> atm :/.

May be bugzilla can be programmed to have such triggers. Having separate
bug is not a good looking solution
>
> Cheers,
>
> Richard
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Richard Purdie]

On Mon, 2016-04-18 at 10:35 -0700, Khem Raj wrote:
> Can we have a possibility to select  field like "affected version"
> and have it such that multiple versions can be specified

That doesn't really allow us to mark version X as merged and version Y
as pending review though and as I understand it, that is the real issue
atm :/.

Cheers,

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

Re: [yocto] [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

On 18 April 2016 at 18:35, Khem Raj  wrote:

> Can we have a possibility to select  field like "affected version" and
> have it such that multiple versions can be specified
>

You'd then need to have the ability to set multiple target versions, and
track each of those independently.  Without this you won't gain anything
beyond leaving a comment saying "needs to be fixed in fido" or "patch sent
for fido", there's no tracking.

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

Re: [yocto] [OE-core] [RFT] GCC 6 Recipes

[Dan McGregor]

On 17 April 2016 at 23:15, Khem Raj  wrote:
> Hello all,
>
> I have put together a potential gcc6 upgrade recipe set, and pushed the 
> branch to tree here
>
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-6
>
> and also at github fork of mine.
>
> https://github.com/kraj/openembedded-core/tree/kraj/master
>
> You need to set
>
> GCCVERSION = “6.%”
>
> in local.conf to enable it.
>
>
> There are few recipes in OE-Core which still don’t compile e.g.
>
> see
>
> http://errors.yoctoproject.org/Errors/Build/14782/
>
> any help in fixing them or otherwise fixing other layers is appreciated.
>
> gcc6 is a major release for some info see
>
> https://gcc.gnu.org/gcc-6/changes.html
>
> and porting guide
>
> https://gcc.gnu.org/gcc-6/porting_to.html
>
>

I haven't built an image with gcc6 as the compiler yet, but I did
check out your branch to try building with gcc 6 as the host compiler
(Fedora 24). I needed a few more fixes, available at
http://git.openembedded.org/openembedded-core-contrib/log/?h=dankm/gcc-6.
I fixed lzop, pkgconfig, and disabled werror on binutils.
core-image-minimal appears to be well on its way to building.


> Thanks
>
> -Khem
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mono][PATCH 2/2] mono: Add libikvm-native to FILES_${PN}-libs

[Fabio Berton]

Fix error:

ERROR: mono-4.3.2.467-r0 do_package_qa: QA Issue: -dev package contains
non-symlink .so: mono-dev path 'work/cortexa9hf-neon-linux-gnueabi/mono/
4.3.2.467-r0/packages-split/mono-dev/usr/lib/libikvm-native.so' [dev-elf]

Signed-off-by: Fabio Berton 
---
 recipes-mono/mono/mono-4.xx.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mono/mono/mono-4.xx.inc b/recipes-mono/mono/mono-4.xx.inc
index 0225aaa..855c857 100644
--- a/recipes-mono/mono/mono-4.xx.inc
+++ b/recipes-mono/mono/mono-4.xx.inc
@@ -71,7 +71,7 @@ PACKAGES += "${PN}-lldb "
 PACKAGES += "${PN} "
 
 FILES_${PN}= "${sysconfdir}/* ${bindir}/* 
${libdir}/*.so*"
-FILES_${PN}-libs   = "${libdir}/libMono*.so"
+FILES_${PN}-libs   = "${libdir}/libMono*.so 
${libdir}/libikvm-native.so"
 FILES_${PN}-lldb= "${libdir}/mono/lldb/*"
 FILES_${PN}-libs-2.0= "${libdir}/mono/2.0/* 
${libdir}/mono/2.0-api/*"
 FILES_${PN}-libs-3.5= "${libdir}/mono/3.5/* 
${libdir}/mono/3.5-api/*"
-- 
2.1.4

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

[yocto] [meta-mono][PATCH 1/2] mono-4xx: Add zlib to DEPENDS

[Fabio Berton]

Signed-off-by: Fabio Berton 
---
 recipes-mono/mono/mono-4.xx.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-mono/mono/mono-4.xx.inc b/recipes-mono/mono/mono-4.xx.inc
index 6075766..0225aaa 100644
--- a/recipes-mono/mono/mono-4.xx.inc
+++ b/recipes-mono/mono/mono-4.xx.inc
@@ -5,6 +5,8 @@ BUGTRACKER = "http://bugzilla.xamarin.com/;
 SECTION = "devel"
 LICENSE = "GPLv2"
 
+DEPENDS = "zlib"
+
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=80862f3fd0e11a5fa0318070c54461ce"
 
 SRC_URI = "http://download.mono-project.com/sources/mono/mono-${PV}.tar.bz2 \
-- 
2.1.4

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

Re: [yocto] [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

Can we have a possibility to select  field like "affected version" and have
it such that multiple versions can be specified
On Apr 18, 2016 3:27 AM, "Burton, Ross"  wrote:

> Hi,
>
> At the moment we don't really have a policy for oe-core bugs in
> bugzilla.yoctoproject.org that apply to multiple releases, for example
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9400.  This is a CVE
> bug that should be fixed in all supported branches, and indeed Sona has
> sent patches for Fido/Dizzy/Jethro/master.  Of course now we've got to
> track where these patches are in the submission process and ensure that we
> don't drop any of these, but bugzilla only has a single target milestone
> for each bug.
>
> I propose that for bugs such as this we file a bug report for master and
> then clone it (there's a Clone This Bug button at the bottom) for each
> stable release that is affected.  Then each bug can have it's own target
> milestone set and we can be sure that the patches don't get left out of
> being merged and that QA can effectively verify each branch.
>
> Any objection or feedback? (the first person to suggest moving to Jira
> gets to manually review all CVEs from CVE-1999-0001 onwards are fixed in
> krogoth).
>
> Ross
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Poky-Tiny errors building util-linux/2.26.2-r0

[Khem Raj]

You propbably need to enable more. Eglibc options than default. Or else
update to 2.1 release which uses musl
On Apr 18, 2016 7:56 AM, "Ronald Oakes"  wrote:

> When I attempt to build using the poky-tiny distribution (or my
> distribution still very closely based on it), I keep getting link
> errors when building util-linux.  These seem to be related to the
> functions provided by wchar.h and locale.h and their associated
> library files.
>
> For example:
>
> x86_64-poky-linux-libtool: link: x86_64-poky-linux-gcc -m64
> -march=core2 -mtune=core2 -msse3 -mfpmath=sse
> --sysroot=/home/ron/yocto_production/build/tmp/sysroot
> s/qemux86-64 -fsigned-char -fno-common -Wall -Werror=sequence-point
> -Wextra -Wmissing-declarations -Wmissing-parameter-type
> -Wmissing-prototypes -Wno-missing-fi
> eld-initializers -Wredundant-decls -Wsign-compare -Wtype-limits
> -Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable
> -Wunused-parameter -Wunused
> -result -Wunused-variable -Wnested-externs -Wpointer-arith
> -Wstrict-prototypes -Wimplicit-function-declaration -O2 -pipe -g
> -feliminate-unused-debug-types -Wl,-
> O1 -Wl,--hash-style=gnu -Wl,--as-needed -o dmesg sys-utils/dmesg.o
> lib/monotonic.o  ./.libs/libcommon.a
> sys-utils/dmesg.o: In function `safe_fwrite':
>
> /home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/sys-utils/dmesg.c:628:
> undefined reference to `mbrtowc'
> /home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/
> sys-utils/dmesg.o: In function `safe_fwrite':
>
> /home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/sys-utils/dmesg.c:628:
> undefined reference to `mbrtowc'
>
> /home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/sys-utils/dmesg.c:636:
> undefined reference to `iswprint'
> ./.libs/libcommon.a(libcommon_la-strutils.o): In function `parse_size':
>
> /home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/lib/strutils.c:109:
> undefined reference to `localeconv'
> ./.libs/libcommon.a(libcommon_la-strutils.o): In function
> `size_to_human_string':
>
> /home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/lib/strutils.c:486:
> undefined reference to `localeconv'
> collect2: error: ld returned 1 exit status
>
>
> 
>
> I suspect that I need to modify something to pull these libraries in
> when building util-linux for this distribution, but I'm new to Yocto
> and unsure where or how to do this.
>
> For what it is worth, I can build poky just fine using the same poky
> and layer downloads.
>
> I can attach my bblayers.conf file if needed.  At this point, I have
> no custom code or recipes included, but am including more than just
> the default poky layers.
>
> Ron Oakes
> --
> ___
> 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] is there a powerpc alternative to kickstart/installer-support?

[Robert P. J. Day]

  if i understand this correctly, the current installer support in YP
is for x86 only (requiring grub or syslinux or what have you). is
there a powerpc equivalent? i've looked around and found nothing.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] Hi, Re: Serial Timeout

[Christian Ege]

Am 18. April 2016 5:14:34 nachm. schrieb Markus Haege :


Hello there,

We use a Freescale imx6 with u-boot. Everything works fine, via serial
loader we copy
devictree, u-boot and kernel+initramfs to the board an it all starts. We
can login but after
5 sec the connection breaks and no further input is possible via serial
console.


Could be watchdog related. You habe an external watchdog or  power monitor 
in your system?


When you run from USB you should see a hid device after a reset.


For the rootfs we use core-image-minimal and bundle it with little code via
a configfile which
I add to bitbake with -R. I found these instructions in the web. Don't find
it now.
But why everything stops after 5 sec? I searched the web for hours but
don't find anything.


Those fixed timing smells like timer/watchdog ...


Help is appreciated, thanks

Markus





Best,
Christian



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





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

Re: [yocto] bugzilla.yoctoproject.org policy for bugs against multiple releases

[akuster]

On 04/18/2016 03:26 AM, Burton, Ross wrote:
> Hi,
> 
> At the moment we don't really have a policy for oe-core bugs in
> bugzilla.yoctoproject.org that apply to multiple releases, for example
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9400.  This is a CVE bug
> that should be fixed in all supported branches, and indeed Sona has sent
> patches for Fido/Dizzy/Jethro/master.  Of course now we've got to track
> where these patches are in the submission process and ensure that we don't
> drop any of these, 

If the worry is about patches being left out than every change requires
a bug number and needs to be managed to ensure a clone is created for
any branch affected by the fix.

but bugzilla only has a single target milestone for each
> bug.
> 
> I propose that for bugs such as this
 we file a bug report for master and
> then clone it (there's a Clone This Bug button at the bottom) for each
> stable release that is affected.

This also means maintainers who cherry-pick fixes from another branch
would have to amend the commit to change the bug number. Do we really
want to add to the workload of the maintainers?

  Then each bug can have it's own target
> milestone set and we can be sure that the patches don't get left out of
> being merged and that QA can effectively verify each branch.
> 
> Any objection or feedback? 

This is why I stopped opening Yocto Bugs. I would rather spend my time
fixing things than managing them.

- Armin

(the first person to suggest moving to Jira gets
> to manually review all CVEs from CVE-1999-0001 onwards are fixed in
> krogoth).

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

[yocto] Serial Timeout

[Markus Haege]

Hello there,

We use a Freescale imx6 with u-boot. Everything works fine, via serial
loader we copy
devictree, u-boot and kernel+initramfs to the board an it all starts. We
can login but after
5 sec the connection breaks and no further input is possible via serial
console.
For the rootfs we use core-image-minimal and bundle it with little code via
a configfile which
I add to bitbake with -R. I found these instructions in the web. Don't find
it now.
But why everything stops after 5 sec? I searched the web for hours but
don't find anything.

Help is appreciated, thanks

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

[yocto] Poky-Tiny errors building util-linux/2.26.2-r0

[Ronald Oakes]

When I attempt to build using the poky-tiny distribution (or my
distribution still very closely based on it), I keep getting link
errors when building util-linux.  These seem to be related to the
functions provided by wchar.h and locale.h and their associated
library files.

For example:

x86_64-poky-linux-libtool: link: x86_64-poky-linux-gcc -m64
-march=core2 -mtune=core2 -msse3 -mfpmath=sse
--sysroot=/home/ron/yocto_production/build/tmp/sysroot
s/qemux86-64 -fsigned-char -fno-common -Wall -Werror=sequence-point
-Wextra -Wmissing-declarations -Wmissing-parameter-type
-Wmissing-prototypes -Wno-missing-fi
eld-initializers -Wredundant-decls -Wsign-compare -Wtype-limits
-Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable
-Wunused-parameter -Wunused
-result -Wunused-variable -Wnested-externs -Wpointer-arith
-Wstrict-prototypes -Wimplicit-function-declaration -O2 -pipe -g
-feliminate-unused-debug-types -Wl,-
O1 -Wl,--hash-style=gnu -Wl,--as-needed -o dmesg sys-utils/dmesg.o
lib/monotonic.o  ./.libs/libcommon.a
sys-utils/dmesg.o: In function `safe_fwrite':
/home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/sys-utils/dmesg.c:628:
undefined reference to `mbrtowc'
/home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/
sys-utils/dmesg.o: In function `safe_fwrite':
/home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/sys-utils/dmesg.c:628:
undefined reference to `mbrtowc'
/home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/sys-utils/dmesg.c:636:
undefined reference to `iswprint'
./.libs/libcommon.a(libcommon_la-strutils.o): In function `parse_size':
/home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/lib/strutils.c:109:
undefined reference to `localeconv'
./.libs/libcommon.a(libcommon_la-strutils.o): In function
`size_to_human_string':
/home/ron/yocto_production/build/tmp/work/core2-64-poky-linux/util-linux/2.26.2-r0/util-linux-2.26.2/lib/strutils.c:486:
undefined reference to `localeconv'
collect2: error: ld returned 1 exit status




I suspect that I need to modify something to pull these libraries in
when building util-linux for this distribution, but I'm new to Yocto
and unsure where or how to do this.

For what it is worth, I can build poky just fine using the same poky
and layer downloads.

I can attach my bblayers.conf file if needed.  At this point, I have
no custom code or recipes included, but am including more than just
the default poky layers.

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

Re: [yocto] Using Yocto with NXP QorIQ Processors

[Eric Nelson]

Hi Chris,

On 04/18/2016 06:58 AM, Chris Trobridge wrote:
> Has anyone attempted to use the Qoriq BSP layers with them main Yocto
> release rather than the NXP (ex Freescale) SDK they come bundled in?
> 
> I ask because the NXP SDK is somewhat behind the main Yocto release
> schedule.
> 
> It should be easier to port the BSP to the current Yocto but I have no
> idea what issues I am likely to hit.
> 
> I will try this at some point when I have enough free time but for
> planning purposes I would interested in how anyone else has got on
> attempting this.
> 
> Are Qoriq users restricted to the official SDK or would they get
> third-party support?
> 

There's a community BSP and a mailing list at:
meta-freesc...@yoctoproject.org

The release notes for the Jethro release say that the Layerscape
processors are supported:
http://freescale.github.io/doc/release-notes/2.0/

Regards,


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

[yocto] Using Yocto with NXP QorIQ Processors

[Chris Trobridge]

Has anyone attempted to use the Qoriq BSP layers with them main Yocto release 
rather than the NXP (ex Freescale) SDK they come bundled in?
I ask because the NXP SDK is somewhat behind the main Yocto release schedule.
It should be easier to port the BSP to the current Yocto but I have no idea 
what issues I am likely to hit.
I will try this at some point when I have enough free time but for planning 
purposes I would interested in how anyone else has got on attempting this.
Are Qoriq users restricted to the official SDK or would they get third-party 
support?
Regards,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding kernel module to rootfs without changing machine's configuration

[Bruce Ashfield]

On 2016-04-18 2:54 AM, Yigal Reiss (yreiss) wrote:

I am able to add a kernel module to the rootfs by appending it to the 
MACHINE_EXTRA_RDEPENDS of the .conf under the machine folder of the 
BSP. E.g. for adding nfq:
MACHINE_EXTRA_RDEPENDS += "kernel-module-xt-multiport ...  
kernel-module-xt-nfqueue"

I would like to make the override (i.e. add my own kernel module, and possibly 
apply kernel patches) from my own layer without touching the provided BSP 
layer. Is this possible?


It is possible. The kernel recipe, and the MACHINE_EXTRA_RDEPENDS, are just
like any other recipe and variable in the system.

If you have your own layer, you can bbappend the kernel recipe to add 
patches

and in your .conf files, you can append to the extra_rdepends.

Bruce



Thanks,
Yigal


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

Re: [linux-yocto] linux-yocto: do_compile failed when DEFAULTTUNE = "aarch64_be"

[Bruce Ashfield]

On 2016-04-18 5:47 AM, Robert Yang wrote:


Reproducer: (both in YP 2.1 and 2.0.1):

MACHINE = "qemuarm64"
DEFAULTTUNE = "aarch64_be"

$ bitbake linux-yocto


aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file usr/initramfs_data.o
make[3]: *** [usr/built-in.o] Error 1
   CC  kernel/exec_domain.o
make[2]: *** [usr] Error 2
make[2]: *** Waiting for unfinished jobs
   OBJCOPY arch/arm64/kernel/vdso/vdso.so
   VDSOSYM arch/arm64/kernel/vdso/vdso-offsets.h
   CC  security/keys/keyring.o
   CC  kernel/panic.o
   CC  kernel/cpu.o
   AS  arch/arm64/kernel/vdso/vdso.o
   CC  kernel/exit.o
   CC  kernel/softirq.o
   LD  security/integrity/integrity.o
   CC  kernel/resource.o
aarch64_be-poky-linux-ld.bfd: security/integrity/iint.o: compiled for a
little endian system and target is big endian  CC  fs/open.o

aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file security/integrity/iint.o
make[4]: *** [security/integrity/integrity.o] Error 1
make[3]: *** [security/integrity] Error 2
make[3]: *** Waiting for unfinished jobs

[snip]
   LD  arch/arm64/mm/built-in.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/dma-mapping.o: compiled for
a little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/dma-mapping.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/extable.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/extable.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/fault.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/fault.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/init.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/init.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/cache.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/cache.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/copypage.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/copypage.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/flush.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/flush.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/ioremap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/ioremap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmap.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pgd.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pgd.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmu.o: compiled for a little
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/mmu.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/context.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/context.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/proc.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/proc.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pageattr.o: compiled for a
little endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of
file arch/arm64/mm/pageattr.o
make[3]: *** [arch/arm64/mm/built-in.o] Error 1
make[2]: *** [arch/arm64/mm] Error 2
   CC  fs/exec.o
[snip]

Any comments, please ?


big endian ARM64 is not something we've been building or testing. The
default for that BSP is LE, and if you want to build the kernel big
endian, you'll need to adjust the kernel configuration (since the
kernel build doesn't know, or care, about the default tune).

Cheers,

Bruce





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

Re: [yocto] RPM bogus signature

[Dmytro Milinevskyy]

Hi,

I've found the culprit.
RPM5 does package auto-signing. Itself it's not a big deal but the problem
is that it also considers that package is valid if the pubkey is present in
the RPM header.
This is an extremely severe security issue - any "signed" package can be
installed on the target even if the public key is not installed in the
local RPM DB.

I would consider to either switch to RPM4 or just disable this "feature" in
RPM5.
BTW, what's purpose of using RPM5 in Yocto? The gross distros(SuSe, Fedora,
etc) still successfully use RPM4. This means that it is exhaustively
verified.

Best regards,
Dimitri

On Sat, Apr 16, 2016 at 2:57 PM, Dmytro Milinevskyy 
wrote:

> Hello,
>
> currently I'm trying to enforce rpm signature verification on the target
> device and get weird bogus signature of the RPM packages when the signature
> is not enabled in the configuration.
> The main issue that this signature is considered as valid by the RPM
> 5.4.14 which is used by Yocto. And thus it is "correctly" installed by
> "smart" packaging system on the target.
>
> For example here 2 packages built w/o signing. Both packages have
> different keys and RPM is not complaining:
> >tmp/sysroots/x86_64-linux/usr/bin/rpm -Kv
> ./tmp/deploy/rpm/all/os-release-1.0-r0.all.rpm
> ./tmp/deploy/rpm/all/tzdata-2016a-r0.all.rpm
> ./tmp/deploy/rpm/all/os-release-1.0-r0.all.rpm:
> Header V4 DSA signature: OK, key ID bd8f688a
> Header SHA1 digest: OK (45dfa7cbfe3cfc3a6c4a928e58b100d81f5a367d)
> MD5 digest: OK (a8450299f5c2d9adecc4bda799b7038d)
> ./tmp/deploy/rpm/all/tzdata-2016a-r0.all.rpm:
> Header V4 DSA signature: OK, key ID bc6abdd3
> Header SHA1 digest: OK (e95dc6b40965224ae443460117fe2ada4f855b2d)
> MD5 digest: OK (1dda4ae1673ab96dd9edbdc423df29ac)
>
> Nevertheless the host RPM(rpm4 from ubuntu) is correctly identifying that
> the signature is invalid:
> >rpm -Kv ./tmp/deploy/rpm/all/os-release-1.0-r0.all.rpm
> ./tmp/deploy/rpm/all/tzdata-2016a-r0.all.rpm
> ./tmp/deploy/rpm/all/os-release-1.0-r0.all.rpm:
> Header V4 DSA/SHA1 Signature, key ID bd8f688a: NOKEY
> Header SHA1 digest: OK (45dfa7cbfe3cfc3a6c4a928e58b100d81f5a367d)
> MD5 digest: OK (a8450299f5c2d9adecc4bda799b7038d)
> ./tmp/deploy/rpm/all/tzdata-2016a-r0.all.rpm:
> Header V4 DSA/SHA1 Signature, key ID bc6abdd3: NOKEY
> Header SHA1 digest: OK (e95dc6b40965224ae443460117fe2ada4f855b2d)
> MD5 digest: OK (1dda4ae1673ab96dd9edbdc423df29ac)
>
> Following is an output of properly signed packages. You may see that the
> keys are valid(you can also check the pub key on MIT key storage):
> rpm -Kv ./tmp/deploy/rpm/all/os-release-1.0-r0.all.rpm
> ./tmp/deploy/rpm/all/tzdata-2016a-r0.all.rpm
> ./tmp/deploy/rpm/all/os-release-1.0-r0.all.rpm:
> Header V4 RSA/SHA1 Signature, key ID 5a906f4c: OK
> Header SHA1 digest: OK (e82b83bc3a4713d36548a3ea6b7c0d3c3dc35f1f)
> MD5 digest: OK (e9bfa1fc6a4ae90e84851bfd4583ec29)
> ./tmp/deploy/rpm/all/tzdata-2016a-r0.all.rpm:
> Header V4 RSA/SHA1 Signature, key ID 5a906f4c: OK
> Header SHA1 digest: OK (d6925400698be829e08bc5013fd28d2c829a2600)
> MD5 digest: OK (427f42d79b83e314f741ff73a672c5dc)
>
>
> Host RPM version
> >rpm --version
> RPM version 4.11.2
>
> Yocto RPM version
> >tmp/sysroots/x86_64-linux/usr/bin/rpm --version
> rpm (RPM) 5.4.14
>
> Yocto version: jethro (1a52eceaa5df89914b6a711defdcf0046e74c7f6)
>
> Best regards,
> Dimitri
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

Hi,

At the moment we don't really have a policy for oe-core bugs in
bugzilla.yoctoproject.org that apply to multiple releases, for example
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9400.  This is a CVE bug
that should be fixed in all supported branches, and indeed Sona has sent
patches for Fido/Dizzy/Jethro/master.  Of course now we've got to track
where these patches are in the submission process and ensure that we don't
drop any of these, but bugzilla only has a single target milestone for each
bug.

I propose that for bugs such as this we file a bug report for master and
then clone it (there's a Clone This Bug button at the bottom) for each
stable release that is affected.  Then each bug can have it's own target
milestone set and we can be sure that the patches don't get left out of
being merged and that QA can effectively verify each branch.

Any objection or feedback? (the first person to suggest moving to Jira gets
to manually review all CVEs from CVE-1999-0001 onwards are fixed in
krogoth).

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

Re: [yocto] module do_configure depends on kernel .config and headers

[Vajzovic, Tom]

Hi Bruce,

From: Bruce Ashfield
Sent: 15 April 2016 18:15
> On Fri, Apr 15, 2016 at 12:02 PM, Vajzovic, Tom wrote:
>>
>> I am using a meta layer provided by a SOM manufacturer.
>> They have a recipe which sets:
>
> What branch are you using ?

Fido.
 
>> inherit module
>>
>> export KLIB_BUILD="${STAGING_KERNEL_DIR}"
>> export KLIB="${D}"
>> 
>> and then its do_configure script calls make, and the Makefile
>> expects $(KLIB_BUILD)/.config to exist, and the kernel headers to be
>> in the same place.
>>
>> This sometimes succeeds and sometimes fails, which I presume is to
>> do with the order that the other entries in the run-queue are
>> executed.
>> 
>> I thought that this might be because the dependency on the kernel
>> .config and headers is not correctly recorded in the recipe.
>> 
>> I added a .bbappend file to the recipe in my own layer which
>> contains:
>>
>> do_configure[depends] += "virtual/kernel:do_shared_workdir"
>>
>> But this has not resolved the problem.  I have used
>> bitbake-layers to verify that my bbappend is being applied.
>>
>> So my questions are:
>>
>> Is $(KLIB_BUILD) the correct place to look for the kernel
>> .config and headers?
>
> The .config is in: STAGING_KERNEL_BUILDDIR, that also has any
> generated files as part of the build.
>
> The headers are in the shared_workdir, as you had found:
> STAGING_KERNEL_DIR

I have a copy of .config in both STAGING_KERNEL_DIR and 
STAGING_KERNEL_BUILDDIR.  They differ only on that the latter has
CONFIG_LOCALVERSION added.  Is this normal?  Can I depend on the
copy in STAGING_KERNEL_DIR? I think that is what the configure
script is currently using.  How else might it differ?

>> What is the correct way to record the dependency in the recipe?
>>
>> Why isn't this done in module.bbclass?  Wouldn't all modules depend
>> on the kernel headers?
>
> It pretty much does, with this in module-base.bbclass:
> do_configure[depends] += "virtual/kernel:do_compile_kernelmodules"

In my Fido modules-base.bbclass I have exactly:

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

So this means that my bbappend is a no-op (I only looked as far as
modules.bbclass; I missed modules-base).

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

[linux-yocto] linux-yocto: do_compile failed when DEFAULTTUNE = "aarch64_be"

[Robert Yang]

Reproducer: (both in YP 2.1 and 2.0.1):

MACHINE = "qemuarm64"
DEFAULTTUNE = "aarch64_be"

$ bitbake linux-yocto


aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a little endian 
system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
usr/initramfs_data.o

make[3]: *** [usr/built-in.o] Error 1
  CC  kernel/exec_domain.o
make[2]: *** [usr] Error 2
make[2]: *** Waiting for unfinished jobs
  OBJCOPY arch/arm64/kernel/vdso/vdso.so
  VDSOSYM arch/arm64/kernel/vdso/vdso-offsets.h
  CC  security/keys/keyring.o
  CC  kernel/panic.o
  CC  kernel/cpu.o
  AS  arch/arm64/kernel/vdso/vdso.o
  CC  kernel/exit.o
  CC  kernel/softirq.o
  LD  security/integrity/integrity.o
  CC  kernel/resource.o
aarch64_be-poky-linux-ld.bfd: security/integrity/iint.o: compiled for a little 
endian system and target is big endian  CC  fs/open.o


aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
security/integrity/iint.o

make[4]: *** [security/integrity/integrity.o] Error 1
make[3]: *** [security/integrity] Error 2
make[3]: *** Waiting for unfinished jobs

[snip]
  LD  arch/arm64/mm/built-in.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/dma-mapping.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/dma-mapping.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/extable.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/extable.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/fault.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/fault.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/init.o: compiled for a little endian 
system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/init.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/cache.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/cache.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/copypage.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/copypage.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/flush.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/flush.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/ioremap.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/ioremap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmap.o: compiled for a little endian 
system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/mmap.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pgd.o: compiled for a little endian 
system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/pgd.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmu.o: compiled for a little endian 
system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/mmu.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/context.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/context.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/proc.o: compiled for a little endian 
system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/proc.o
aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pageattr.o: compiled for a little 
endian system and target is big endian
aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
arch/arm64/mm/pageattr.o

make[3]: *** [arch/arm64/mm/built-in.o] Error 1
make[2]: *** [arch/arm64/mm] Error 2
  CC  fs/exec.o
[snip]

Any comments, please ?

--
Thanks

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

Re: [yocto] Running an own script after kernel compilation

[Yegor Yefremov]

On Thu, Apr 14, 2016 at 12:19 PM, Belisko Marek  wrote:
> Hi,
>
> On Thu, Apr 14, 2016 at 12:12 PM, Yegor Yefremov
>  wrote:
>> I have my own ITS file, that is required to create a FIT image. ITS
>> file has a special configuration, that cannot be automatically created
>> using Yocto's recipes. So I need a way to invoke my own script. How
>> can I do it?
> depends which yocto version you are using but you can use (reuse)
> kernel-fitimage.bbclass present in jethro.
> which will generate its file from kernel + dts you will define + with
> that its will build FIT image. But not sure if it's really what you
> need.

So, I've solved the problem via adding a task:

do_create_fitimage() {
cp ${THISDIR}/linux-yocto-custom/kernel-fit.its ${DEPLOY_DIR_IMAGE}
uboot-mkimage -f ${DEPLOY_DIR_IMAGE}/kernel-fit.its
${DEPLOY_DIR_IMAGE}/kernel-fit.itb
}

addtask create_fitimage before do_packagedata after do_deploy

No the question is, how to handle out-of-tree DTS files?
meta/recipes-kernel/linux/linux-dtb.inc won't copy DTS files to
"${B}/arch/${ARCH}/boot/dts/${DTB}"

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

[linux-yocto] [PATCH 1/1] sched/cgroup: Fix/cleanup cgroup teardown/init

[Mikko Ylinen]

This commit backports 2f5177f0fd7e531b26d54633be62d1d4cb94621c
from linux-stable.

We've seen frequent oopses with linux-yocto-4.4 and this commit
helps to get rid of those.

Changes:

Peter Zijlstra (1):
  sched/cgroup: Fix/cleanup cgroup teardown/init

 kernel/sched/core.c | 35 ++-
 1 file changed, 14 insertions(+), 21 deletions(-)

Commit log:

The CPU controller hasn't kept up with the various changes in the whole
cgroup initialization / destruction sequence, and commit:

  2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups")

caused it to explode.

The reason for this is that zombies do not inhibit css_offline() from
being called, but do stall css_released(). Now we tear down the cfs_rq
structures on css_offline() but zombies can run after that, leading to
use-after-free issues.

The solution is to move the tear-down to css_released(), which
guarantees nobody (including no zombies) is still using our cgroup.

Furthermore, a few simple cleanups are possible too. There doesn't
appear to be any point to us using css_online() (anymore?) so fold that
in css_alloc().

And since cgroup code guarantees an RCU grace period between
css_released() and css_free() we can forgo using call_rcu() and free the
stuff immediately.

Signed-off-by: Mikko Ylinen 
---
 kernel/sched/core.c | 35 ++-
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index eb70592..bcda4f8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7692,7 +7692,7 @@ void set_curr_task(int cpu, struct task_struct *p)
 /* task_group_lock serializes the addition/removal of task groups */
 static DEFINE_SPINLOCK(task_group_lock);
 
-static void free_sched_group(struct task_group *tg)
+static void sched_free_group(struct task_group *tg)
 {
free_fair_sched_group(tg);
free_rt_sched_group(tg);
@@ -7718,7 +7718,7 @@ struct task_group *sched_create_group(struct task_group 
*parent)
return tg;
 
 err:
-   free_sched_group(tg);
+   sched_free_group(tg);
return ERR_PTR(-ENOMEM);
 }
 
@@ -7738,17 +7738,16 @@ void sched_online_group(struct task_group *tg, struct 
task_group *parent)
 }
 
 /* rcu callback to free various structures associated with a task group */
-static void free_sched_group_rcu(struct rcu_head *rhp)
+static void sched_free_group_rcu(struct rcu_head *rhp)
 {
/* now it should be safe to free those cfs_rqs */
-   free_sched_group(container_of(rhp, struct task_group, rcu));
+   sched_free_group(container_of(rhp, struct task_group, rcu));
 }
 
-/* Destroy runqueue etc associated with a task group */
 void sched_destroy_group(struct task_group *tg)
 {
/* wait for possible concurrent references to cfs_rqs complete */
-   call_rcu(>rcu, free_sched_group_rcu);
+   call_rcu(>rcu, sched_free_group_rcu);
 }
 
 void sched_offline_group(struct task_group *tg)
@@ -8209,31 +8208,26 @@ cpu_cgroup_css_alloc(struct cgroup_subsys_state 
*parent_css)
if (IS_ERR(tg))
return ERR_PTR(-ENOMEM);
 
+   sched_online_group(tg, parent);
+
return >css;
 }
 
-static int cpu_cgroup_css_online(struct cgroup_subsys_state *css)
+static void cpu_cgroup_css_released(struct cgroup_subsys_state *css)
 {
struct task_group *tg = css_tg(css);
-   struct task_group *parent = css_tg(css->parent);
 
-   if (parent)
-   sched_online_group(tg, parent);
-   return 0;
+   sched_offline_group(tg);
 }
 
 static void cpu_cgroup_css_free(struct cgroup_subsys_state *css)
 {
struct task_group *tg = css_tg(css);
 
-   sched_destroy_group(tg);
-}
-
-static void cpu_cgroup_css_offline(struct cgroup_subsys_state *css)
-{
-   struct task_group *tg = css_tg(css);
-
-   sched_offline_group(tg);
+   /*
+* Relies on the RCU grace period between css_released() and this.
+*/
+   sched_free_group(tg);
 }
 
 static void cpu_cgroup_fork(struct task_struct *task, void *private)
@@ -8593,9 +8587,8 @@ static struct cftype cpu_files[] = {
 
 struct cgroup_subsys cpu_cgrp_subsys = {
.css_alloc  = cpu_cgroup_css_alloc,
+   .css_released   = cpu_cgroup_css_released,
.css_free   = cpu_cgroup_css_free,
-   .css_online = cpu_cgroup_css_online,
-   .css_offline= cpu_cgroup_css_offline,
.fork   = cpu_cgroup_fork,
.can_attach = cpu_cgroup_can_attach,
.attach = cpu_cgroup_attach,
-- 
2.8.0.rc3

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended

[linux-yocto] [PATCH 0/1] linux-yocto-4.4: backport sched/cgroup fixes

[Mikko Ylinen]

While searching for LKML archives to spot any similar hits to an
oops we've seen when using linux-yocto-4.4, I ran into a thread
about "[BUG] sched: leaf_cfs_rq_list use after free".

The patch proposed in that thread fixes the oops so I'm sending 
a backported version of it to linux-yocto-4.4.

-- 
2.8.0.rc3

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [yocto] [PATCH][meta-selinux] refpolicy-minimum: port changes for prepare_policy_store

[wenzong fan]

On 04/18/2016 05:02 AM, Philip Tricca wrote:

Hello Wenzong,

On 04/08/2016 01:19 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Apply the changes to refpolicy-minimum_2.20151208.bb:

   commit bfaf278116e6c3a04bb82c9f8a4f8629a0a85df8
   Author: Wenzong Fan 
   Date:   Tue Oct 27 06:25:04 2015 -0400

 refpolicy-minimum: update prepare_policy_store

 * update prepare_policy_store() for supporting SELinux 2.4 & CIL, the
   logic is from refpolicy_common.inc but with minimum set of policy
   modules;

 * add extra policy modules that required by sysnetwork, without those
   modules the install process will fail with error:

 | Failed to resolve roletype statement at 62 of \
   .../image/var/lib/selinux/minimum/tmp/modules/100/sysnetwork/cil
 | Failed to resolve ast
 | semodule:  Failed!

 Signed-off-by: Wenzong Fan 
 Signed-off-by: Joe MacDonald 

Signed-off-by: Wenzong Fan 
---


This looks great but in testing it I'm unable to use the 'minimum'
refpolicy recipe in any image. The recipe builds fine but the do_rootfs
fails trying to label the filesystem. I haven't been able to find the
root cause for this yet, but I'm seeing this behavior both before and
after adding this patch so it may be a preexisting issue?

Given all of that, I've merged this patch into master since it doesn't
seem related to the issue I'm seeing. Still, some help in resolving the
issue I'm seeing with the minimum refpolicy recipe would be appreciated.


Hi Philip,

Thanks for getting the change merged.

I did a test and see errors about:


/.../core-image-selinux/1.0-r0/rootfs//etc/selinux/mcs/contexts/files/file_contexts: 
No such file or directory


That should be the SELINUXTYPE in /etc/selinux/config is not correct, 
below patches could fix it:


--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -162,7 +162,8 @@ SELINUX=${DEFAULT_ENFORCING}
 # mls - Multi Level Security protection.
 # targeted - Targeted processes are protected.
 # mcs - Multi Category Security protection.
-SELINUXTYPE=${POLICY_TYPE}
+# minimum - Minimum Security protection.
+SELINUXTYPE=${POLICY_NAME}

It works in my test, please feel free to integrate it if you think it 
makes sense.


Thanks
Wenzong



Thanks,
Philip


  .../refpolicy/refpolicy-minimum_2.20151208.bb  | 41 --
  1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb 
b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
index b275821..47ed558 100644
--- a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
+++ b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
@@ -26,23 +26,42 @@ EXTRA_POLICY_MODULES += "nscd"
  # "login", so "login" process will access to /var/spool/mail.
  EXTRA_POLICY_MODULES += "mta"

+# sysnetwork requires type definitions (insmod_t, consoletype_t,
+# hostname_t, ping_t, netutils_t) from modules:
+EXTRA_POLICY_MODULES += "modutils consoletype hostname netutils"
+
  POLICY_MODULES_MIN = "${CORE_POLICY_MODULES} ${EXTRA_POLICY_MODULES}"

  # re-write the same func from refpolicy_common.inc
  prepare_policy_store () {
oe_runmake 'DESTDIR=${D}' 'prefix=${D}${prefix}' install
+   POL_PRIORITY=100
+   POL_SRC=${D}${datadir}/selinux/${POLICY_NAME}
+   POL_STORE=${D}${localstatedir}/lib/selinux/${POLICY_NAME}
+   POL_ACTIVE_MODS=${POL_STORE}/active/modules/${POL_PRIORITY}

# Prepare to create policy store
-   mkdir -p ${D}${sysconfdir}/selinux/
-   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/policy
-   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/modules
-   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/files
-   touch 
${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/files/file_contexts.local
-   for i in ${D}${datadir}/selinux/${POLICY_NAME}/*.pp; do
-   bzip2 -f $i && mv -f $i.bz2 $i
-   done
-   cp base.pp 
${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/base.pp
-   for i in ${POLICY_MODULES_MIN}; do
-   cp ${i}.pp 
${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/modules/`basename $i.pp`
+   mkdir -p ${POL_STORE}
+   mkdir -p ${POL_ACTIVE_MODS}
+
+   # get hll type from suffix on base policy module
+   HLL_TYPE=$(echo ${POL_SRC}/base.* | awk -F . '{if (NF>1) {print $NF}}')
+   HLL_BIN=${STAGING_DIR_NATIVE}${prefix}/libexec/selinux/hll/${HLL_TYPE}
+
+   for i in base ${POLICY_MODULES_MIN}; do
+   MOD_FILE=${POL_SRC}/${i}.${HLL_TYPE}
+   MOD_DIR=${POL_ACTIVE_MODS}/${i}
+   mkdir -p ${MOD_DIR}
+   echo -n "${HLL_TYPE}" > ${MOD_DIR}/lang_ext
+
+   if ! bzip2 -t 

[yocto] Adding kernel module to rootfs without changing machine's configuration

[Yigal Reiss (yreiss)]

I am able to add a kernel module to the rootfs by appending it to the 
MACHINE_EXTRA_RDEPENDS of the .conf under the machine folder of the 
BSP. E.g. for adding nfq:
MACHINE_EXTRA_RDEPENDS += "kernel-module-xt-multiport ...  
kernel-module-xt-nfqueue"

I would like to make the override (i.e. add my own kernel module, and possibly 
apply kernel patches) from my own layer without touching the provided BSP 
layer. Is this possible?

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