Re: [yocto] Per-machine DEPENDS
On 17 May 2012, at 22:22, Paul Eggleton wrote:
> On Thursday 17 May 2012 22:07:50 Chris Tapp wrote:
>> On 17 May 2012, at 21:27, Paul Eggleton wrote:
>>> On Thursday 17 May 2012 21:10:10 Chris Tapp wrote:
Is it possible to have the (R)DEPENDS list vary depending on the machine
being built?
For example, I want 'this-bit' to be included for a 'machine-1' build,
but
not 'machine-2'.
Something like:
DEPENDS = "common-stuff"
DEPENDS_machine-1 = "${DEPENDS} this-stuff"
>>>
>>> Yes, that will work. If the DEPENDS change implies some different
>>> configuration I'd recommend being explicit about it as well e.g. via
>>> EXTRA_OECONF or whatever is appropriate; this is particularly important
>>> for the case where the extra dependency is not included and the configure
>>> script for the application would auto-detect the presence of the
>>> additional dependency in the absence of an explicit configure option.
>>
>> Thanks. Is there some documentation that explains how the suffixes are build
>> up, when they are used, etc. ?
>
> These "suffixes" are called overrides in BitBake parlance. If an override
> appears in the OVERRIDES variable then it is applied, and the OVERRIDES
> variable is built up out of the values of various other variables (including
> MACHINE, DISTRO, etc - see 'bitbake -e | grep OVERRIDES'). I'm pretty sure
> this is covered in the BitBake manual, although unfortunately that is only
> available in source format right now.
Do overrides work with any variable? The RPi layer is using BBMASK to filter
out some recipes when building against Yocto. This has to be manually added to
local.conf. Would it be possible to do this automatically in the layer using an
override based on the distro name/version? e.g. could something like the
following be added to the layer.conf file?
BBMASK_poky_7.0? += " ${LAYERDIR}/stuff-i-dont-want"
Or would it be better to have distro-specific recipe trees and then (somehow)
apply overrides to BBFILES:
BBFILES := "${BBFILES} ${LAYERDIR}/recipes*/*/*.bb \
${LAYERDIR}/recipes*/*/*.bbappend"
BBFILES "${LAYERDIR}/poky-7.0/*/*.bbappend"
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Per-machine DEPENDS
On 23/05/12 08:55, Chris Tapp wrote:
> Do overrides work with any variable? The RPi layer is using BBMASK to
> filter out some recipes when building against Yocto. This has to be
> manually added to local.conf.
It does not have to be local.conf; if you are adding meta-raspberrypi,
you have to set up the layer configuration at minimum, and probably
other things, so you can set it up somewhere more appropriate.
local.conf is really just for changes when testing things, etc.
> Would it be possible to do this
> automatically in the layer using an override based on the distro
> name/version? e.g. could something like the following be added to the
> layer.conf file?
>
> BBMASK_poky_7.0? += " ${LAYERDIR}/stuff-i-dont-want"
I don't know if the overrides work with this variable in particular, but
even if they did, it is not a good idea for a layer of any kind to be
changing the BBMASK value, because the layer cannot make any assumptions
about what might or might not be appropriate to mask out.
(Also note that BBMASK is pyton regex, so BBMASK += "
${LAYERDIR}/stuff-i-dont-want" will not work, it would need, e.g., to
include the '|' operator)
>
> Or would it be better to have distro-specific recipe trees
Specifically to the m-rpi, there are only two problematic recipes, the
libav.bbappend, but you only know on the distro level whether you need
to mask this out or now (i.e., someone's poky-derrived distro might well
include libav).
The second is the rpi-zram-service which needs systemd.
This recipe needs to be reworked so it produces both -systemd and -initd
packages, from which the distro can then pull in the appropriate one;
one of the packages can even be a dummy (which for poky could be
achieved by adding systemd.bbclass stub).
Tomas
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] bitbake failure on meta-cedartrail using master branch
FYI, I just pulled the lasted patches into my system and ran a bitbake of cedartrail with the PVR driver. I got a failure on the kernel build. log below: ERROR: Logfile of failure stored in: /build/cdv-master/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.24+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+81fd8c307997aff37916828dc8b4ef72f5d35a94-r4/temp/log.do_patch.29202 Log data follows: | Branch meta-temp set up to track remote branch meta from origin. | git reset --mixed 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc | Deleted branch meta-temp (was 620917d). | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 434: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 436: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 437: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 438: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 441: yocto/standard/cedartrail-standard.scc: No such file or directory | readlink: missing operand | Try `readlink --help' for more information. | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/staERROR: Function failed: do_patch (see /build/cdv-master/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.24+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+81fd8c307997aff37916828dc8b4ef72f5d35a94-r4/temp/log.do_patch.29202 for further information) | ndard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-
Re: [yocto] Porting of specific Kernel/Driver into yocto.
Hi Bruce,
[ I am using "poky-edison-6.0" ]
I am able to create my rootfs and uImage but when I flashed these on my board,
while booting I am getting below Error and console get blocked.
=
[3.575805] EXT3-fs (mmcblk0p1): using internal journal
[3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
[3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
[3.594268] Freeing init memory: 312K
INIT: version 2.88 booting
Please wait: booting...
Starting udev
Starting Bootlog daemon: bootlogd: cannot deduce real console device
bootlogd.
Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
done.
Fri May 11 11:29:00 UTC 2012
Running postinst /etc/rpm-postinsts/*.sh...
ERROR: postinst /etc/rpm-postinsts/*.sh failed.
INIT: Entering runlevel: 5
Starting syslogd/klogd: done
Stopping Bootlog daemon: bootlogd.
[9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
=
and after that it got stuck, I am not getting console.
I am building rootfs/uImage with default toolchain used in yocto.
Is it problem of toolchain?.
Should I build with our toolchain( we use CodeSourcery)?.
Best Regards,
Om Prakash Pal
From: Bruce Ashfield [bruce.ashfi...@windriver.com]
Sent: Sunday, May 06, 2012 6:00 PM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
On 12-05-06 5:43 AM, Om Prakash PAL wrote:
> Hi Bruce,
> I am getting some problem in do_install:
>
> NOTE: Running task 1535 of 1710 (ID: 517,
> /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb,
> do_install)
> NOTE: package
> linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task
> do_install: Started
>
> and I waited for ~15hr to complete task do_install: but not completed and i
> am not getting any Errors/warnings.
> Is there any problem?.
> I have checked that my vmlinux/uImage/zImage has been created successfully
> but rootfs has not been created till now.
>
> here is my .bb file that is building my local_kernel.
>
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> KMACHINE = "dev"
> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>
> KBRANCH = "${KMACHINE}"
> KMETA = "meta"
>
> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>
> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
> SRC_URI +="file://defconfig"
>
> SRCREV="${AUTOREV}"
> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>
> LINUX_VERSION ?= "3.2"
> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
> PR = "r10"
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>
> # Functionality flags
> KERNEL_REVISION_CHECKING=""
> YOCTO_KERNEL_META_DATA=""
>
> require recipes-kernel/linux/linux-tools.inc
>
> what should be the problem?.
Anything using linux-yocto has exactly the same packaging semantics as
other kernels, since they all inherit kernel.bbclass.
Maybe your description sounds familiar to others, and others that might
have better ideas about what's happening in the packaging backend ?
You don't have any special partitions configured ? You are building
on a local filesystem ? Is rpm or ipkg being used ? .. these are all
things that could impact performance (but not really 15 hours worth of
issues).
Are there any hints in the host system logs, or in the kernels do_install
log ?
Bruce
>
> Best Regards,
> Om Prakash Pal
>
> From: Bruce Ashfield [bruce.ashfi...@windriver.com]
> Sent: Thursday, May 03, 2012 5:59 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks a lot for your help.
>> Now I am able to build the local kernel.
>
> Great!
>
>> I have one doublt:
>> when I do
>> bitbake -c mencuconfig virtual/kernel
>>
>> then from which location it will take the config file?.
>> and if I want to buiild my own specific defconfig file then How can do it?.
>
> It will use the .config in the build directory ${B}, which if you
> are using a linux-yocto recipe would be your
> linux-$MACHINE-$KERNELTYPE-build
> directory.
>
> The dependencies of menuconfig will ensure that the kernel has been fetched,
> unpacked and configured before it runs. Which means a defconfig will
> have already been used (if specified) to construct the .config.
>
> Any changes you make will be saved in the .config, and you'll need to
> preserve that for future builds.
>
> Cheers,
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> From: Bruce Ashfield [bruce.ashfi...@windriver.com]
>> Sent: Monday, April 30, 2012 7:42 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; y
Re: [yocto] Porting of specific Kernel/Driver into yocto.
On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
> Hi Bruce,
>
> [ I am using "poky-edison-6.0" ]
> I am able to create my rootfs and uImage but when I flashed these on my board,
> while booting I am getting below Error and console get blocked.
>
> =
> [3.575805] EXT3-fs (mmcblk0p1): using internal journal
> [3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data
> mode
> [3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
> [3.594268] Freeing init memory: 312K
> INIT: version 2.88 booting
>
> Please wait: booting...
> Starting udev
> Starting Bootlog daemon: bootlogd: cannot deduce real console device
> bootlogd.
> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
> done.
> Fri May 11 11:29:00 UTC 2012
> Running postinst /etc/rpm-postinsts/*.sh...
> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
Does this error repeat if you reboot?
> INIT: Entering runlevel: 5
> Starting syslogd/klogd: done
> Stopping Bootlog daemon: bootlogd.
> [9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>
> =
> and after that it got stuck, I am not getting console.
How long do you let it sit?
>
> I am building rootfs/uImage with default toolchain used in yocto.
> Is it problem of toolchain?.
> Should I build with our toolchain( we use CodeSourcery)?.
Nothing above suggests a toolchain problem. You have an error running
the postinst scripts from the various rpm packages. Some instrumentation
in those scripts (and the parent script) would help narrow down where it
is failing.
--
Darren
>
> Best Regards,
> Om Prakash Pal
>
> From: Bruce Ashfield [bruce.ashfi...@windriver.com]
> Sent: Sunday, May 06, 2012 6:00 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> I am getting some problem in do_install:
>>
>> NOTE: Running task 1535 of 1710 (ID: 517,
>> /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb,
>> do_install)
>> NOTE: package
>> linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task
>> do_install: Started
>>
>> and I waited for ~15hr to complete task do_install: but not completed and i
>> am not getting any Errors/warnings.
>> Is there any problem?.
>> I have checked that my vmlinux/uImage/zImage has been created successfully
>> but rootfs has not been created till now.
>>
>> here is my .bb file that is building my local_kernel.
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> KMACHINE = "dev"
>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>
>> KBRANCH = "${KMACHINE}"
>> KMETA = "meta"
>>
>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>
>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>> SRC_URI +="file://defconfig"
>>
>> SRCREV="${AUTOREV}"
>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>
>> LINUX_VERSION ?= "3.2"
>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>> PR = "r10"
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>
>> # Functionality flags
>> KERNEL_REVISION_CHECKING=""
>> YOCTO_KERNEL_META_DATA=""
>>
>> require recipes-kernel/linux/linux-tools.inc
>>
>> what should be the problem?.
>
> Anything using linux-yocto has exactly the same packaging semantics as
> other kernels, since they all inherit kernel.bbclass.
>
> Maybe your description sounds familiar to others, and others that might
> have better ideas about what's happening in the packaging backend ?
>
> You don't have any special partitions configured ? You are building
> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
> things that could impact performance (but not really 15 hours worth of
> issues).
>
> Are there any hints in the host system logs, or in the kernels do_install
> log ?
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> From: Bruce Ashfield [bruce.ashfi...@windriver.com]
>> Sent: Thursday, May 03, 2012 5:59 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks a lot for your help.
>>> Now I am able to build the local kernel.
>>
>> Great!
>>
>>> I have one doublt:
>>> when I do
>>> bitbake -c mencuconfig virtual/kernel
>>>
>>> then from which location it will take the config file?.
>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>
>> It will use the .config in the build directory ${B}, which if you
>> are using a linux-yocto recipe would be your
>> linux-$MACHINE-$KERNELTYPE-build
>> directory.
>>
>> The depen
Re: [yocto] bitbake failure on meta-cedartrail using master branch
On 05/23/2012 04:59 AM, jfabernathy wrote: > FYI, > > I just pulled the lasted patches into my system and ran a bitbake of > cedartrail with the PVR driver. I have a fix for this, was waiting for an Ack and got side tracked. Please pull meta-intel again and try again with the master branch. You should have the following commit now: commit a62c485edffed30ea95658760948fd50925adfb0 Author: Darren Hart Date: Fri May 18 09:19:31 2012 -0700 linux-yocto_3.0: Update KMACHINE and KBRANCH to play nice with new kerntools Thanks, Darren > > I got a failure on the kernel build. log below: > ERROR: Logfile of failure stored in: > /build/cdv-master/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.24+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+81fd8c307997aff37916828dc8b4ef72f5d35a94-r4/temp/log.do_patch.29202 > Log data follows: > | Branch meta-temp set up to track remote branch meta from origin. > | git reset --mixed 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc > | Deleted branch meta-temp (was 620917d). > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line > 434: yocto/standard/cedartrail-standard.scc: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line > 436: yocto/standard/cedartrail-standard.scc: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line > 437: yocto/standard/cedartrail-standard.scc: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line > 438: yocto/standard/cedartrail-standard.scc: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line > 441: yocto/standard/cedartrail-standard.scc: No such file or directory > | readlink: missing operand > | Try `readlink --help' for more information. > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: > yocto/standard/cedartrail-standard: No such file or directory > | /build/cdv-master/tmp/sysroots/x86_64-lin
Re: [yocto] [ANNOUNCEMENT] Cedar Trail with PowerVR for Edison 6.0.1
On 05/22/2012 10:44 PM, Wolfgang Denk wrote: > Dear Elizabeth, > > In message > you > wrote: >> >> This release enables the BSP to use the latest available kernel >> patches for Intel's PowerVR graphics driver. The BSP image includes >> time limited kernel images for testing purposes. > > This is probaby a stupid question, so I apologize in advance: > > What is a time limited kernel image? In short: the time limited kernel limits uptime and warns the user via the system log. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] linux-yocto_3.0: Update KMACHINE and KBRANCH to play nice with new kerntools
On 05/18/2012 01:25 PM, Darren Hart wrote: > The 3.0 based boards are lazy compared to our new modern ones. > > Without this patch, the linux-yocto-3.0 kernel do_patch() task would fail > with: > > /srv/home/pokybuild/yocto-autobuilder/yocto-slave/cedartrail/build/build/tmp/sysroots/x86_64-linux/usr/bin/updateme: > line 434: yocto/standard/cedartrail-standard.scc: No such file or directory > > Setting the KBRANCH explicitly avoids this issue. This brings the following > recipes inline with the fri2 and sys940x BSPs. > > Fix proposed by Bruce Ashfield. > > Testing: I build linux-yocto_3.0 for all machines involved, including the > nopvr, > noemgd variants. All built linux-yocto_3.0 successfully. > > Signed-off-by: Darren Hart > CC: Tom Zanussi > CC: Bruce Ashfield > CC: Kishore Bodke Merged to meta-intel master -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Per-machine DEPENDS
Firstly, I should have said I was using the m-rpi as an example only ;-)
On 23 May 2012, at 09:31, Tomas Frydrych wrote:
> On 23/05/12 08:55, Chris Tapp wrote:
>> Do overrides work with any variable? The RPi layer is using BBMASK to
>> filter out some recipes when building against Yocto. This has to be
>> manually added to local.conf.
>
> It does not have to be local.conf; if you are adding meta-raspberrypi,
> you have to set up the layer configuration at minimum, and probably
> other things, so you can set it up somewhere more appropriate.
> local.conf is really just for changes when testing things, etc.
>
>> Would it be possible to do this
>> automatically in the layer using an override based on the distro
>> name/version? e.g. could something like the following be added to the
>> layer.conf file?
>>
>> BBMASK_poky_7.0? += " ${LAYERDIR}/stuff-i-dont-want"
>
> I don't know if the overrides work with this variable in particular, but
> even if they did, it is not a good idea for a layer of any kind to be
> changing the BBMASK value, because the layer cannot make any assumptions
> about what might or might not be appropriate to mask out.
Ok. Is there some other way that the addition of a layer can be 'intelligent'
so that it adapts itself to the build? For example, I have a layer that was
designed to work with 4.x. It needed some minor changes to make it work with
5.x, some more for 6.x, etc. I would like to have a single meta-layer that will
work with them all so that I only have to maintain a single version and not
have branches for the different poky versions.
I can probably do what needs to be done using BBMASK, but it would be nice if
DISTRO and DISTRO_VERSION could be used to automate this. Would it not be
appropriate for the layer to decide what it offers to a distro? i.e. not offer
things it knows aren't compatible.
> (Also note that BBMASK is pyton regex, so BBMASK += "
> ${LAYERDIR}/stuff-i-dont-want" will not work, it would need, e.g., to
> include the '|' operator)
>
>>
>> Or would it be better to have distro-specific recipe trees
>
> Specifically to the m-rpi, there are only two problematic recipes, the
> libav.bbappend, but you only know on the distro level whether you need
> to mask this out or now (i.e., someone's poky-derrived distro might well
> include libav).
>
> The second is the rpi-zram-service which needs systemd.
> This recipe needs to be reworked so it produces both -systemd and -initd
> packages, from which the distro can then pull in the appropriate one;
> one of the packages can even be a dummy (which for poky could be
> achieved by adding systemd.bbclass stub).
>
> Tomas
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Per-machine DEPENDS
Why not using branches? For example meta-ivi maintains two branches: denzil
and master.
On May 23, 2012 10:03 PM, "Chris Tapp" wrote:
> Firstly, I should have said I was using the m-rpi as an example only ;-)
>
> On 23 May 2012, at 09:31, Tomas Frydrych wrote:
>
> > On 23/05/12 08:55, Chris Tapp wrote:
> >> Do overrides work with any variable? The RPi layer is using BBMASK to
> >> filter out some recipes when building against Yocto. This has to be
> >> manually added to local.conf.
> >
> > It does not have to be local.conf; if you are adding meta-raspberrypi,
> > you have to set up the layer configuration at minimum, and probably
> > other things, so you can set it up somewhere more appropriate.
> > local.conf is really just for changes when testing things, etc.
> >
> >> Would it be possible to do this
> >> automatically in the layer using an override based on the distro
> >> name/version? e.g. could something like the following be added to the
> >> layer.conf file?
> >>
> >> BBMASK_poky_7.0? += " ${LAYERDIR}/stuff-i-dont-want"
> >
> > I don't know if the overrides work with this variable in particular, but
> > even if they did, it is not a good idea for a layer of any kind to be
> > changing the BBMASK value, because the layer cannot make any assumptions
> > about what might or might not be appropriate to mask out.
>
> Ok. Is there some other way that the addition of a layer can be
> 'intelligent' so that it adapts itself to the build? For example, I have a
> layer that was designed to work with 4.x. It needed some minor changes to
> make it work with 5.x, some more for 6.x, etc. I would like to have a
> single meta-layer that will work with them all so that I only have to
> maintain a single version and not have branches for the different poky
> versions.
>
> I can probably do what needs to be done using BBMASK, but it would be nice
> if DISTRO and DISTRO_VERSION could be used to automate this. Would it not
> be appropriate for the layer to decide what it offers to a distro? i.e. not
> offer things it knows aren't compatible.
>
> > (Also note that BBMASK is pyton regex, so BBMASK += "
> > ${LAYERDIR}/stuff-i-dont-want" will not work, it would need, e.g., to
> > include the '|' operator)
> >
> >>
> >> Or would it be better to have distro-specific recipe trees
> >
> > Specifically to the m-rpi, there are only two problematic recipes, the
> > libav.bbappend, but you only know on the distro level whether you need
> > to mask this out or now (i.e., someone's poky-derrived distro might well
> > include libav).
> >
> > The second is the rpi-zram-service which needs systemd.
> > This recipe needs to be reworked so it produces both -systemd and -initd
> > packages, from which the distro can then pull in the appropriate one;
> > one of the packages can even be a dummy (which for poky could be
> > achieved by adding systemd.bbclass stub).
> >
> > Tomas
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
> Chris Tapp
>
> opensou...@keylevel.com
> www.keylevel.com
>
>
>
> ___
> 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] [PATCH 00/20] meta-intel: new chiefriver BSP and supporting recipes
From: Tom Zanussi This patchset implements a new BSP for the 'Chief River' platform, which consists of the Intel Ivy Bridge processor and Panther Point PCH. It assumes that the Ivy Bridge integrated graphics are being used. It also adds a few new recipes related to video acceleration which are modified versions of oe-core or yocto meta-demo recipes (ffmpeg, yasm-native, gstreamer-vaapi), along with tweaks needed to work with intel video acceleration components. There are also some new intel-specific video acceleration components (libva-1.0.15, intel-driver-1.0.15, va-intel) either needed for video acceleration on Intel platforms, or allowing for easier integration with the existing meta-intel BSPs. These finally allow the chiefriver, sugarbay, and crownbay BSPs to share a common set of video components, and have been tested with all three. Finally, there's a new recipe for the Intel Local Manageability Service (LMS), which allows Intel BSPs to access the Intel Active Management Technology (AMT) firmware via the Intel Management Engine Interface (MEI), which is used by the Chief River BSP. The following changes since commit a62c485edffed30ea95658760948fd50925adfb0: Darren Hart (1): linux-yocto_3.0: Update KMACHINE and KBRANCH to play nice with new kerntools are available in the git repository at: git://git.yoctoproject.org/meta-intel.git tzanussi/chiefriver.v1 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/chiefriver.v1 Tom Zanussi (20): meta-chiefriver: new layer for Chief River (Ivy Bridge/Panther Point) systems meta-intel: add gstreamer-vaapi_git recipe meta-intel: new libva-1.0.15 recipe meta-intel: new intel-driver-1.0.15 recipe ffmpeg: new recipe ffmpeg: add --enable-vaapi ffmpeg: add --enable-gpl yasm: new recipe ffmpeg: add --enable-yasm gst-ffmpeg: add bbappend for external ffmpeg gst-va-intel: add conditional vaapi implementation va-intel: new package gst-va-intel: clarify DESCRIPTION meta-intel: remove video acceleration from emgd XSERVER meta-chiefriver: use gst-va-intel and va-intel meta-sugarbay: use gst-va-intel and va-intel meta-crownbay: use gst-va-intel and va-intel and gst-va-mixvideo lms: new recipe meta-chiefriver: use lms meta-chiefriver: use the mei kernel feature .../amt/lms/atnetworktool-printf-fix.patch | 14 +++ common/recipes-bsp/amt/lms_7.1.20.bb | 42 common/recipes-multimedia/ffmpeg/ffmpeg.inc| 108 common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb | 44 .../gstreamer/gst-ffmpeg_0.10.13.bbappend |2 + .../recipes-multimedia/gstreamer/gst-va-intel.bb | 15 +++- .../gstreamer/gstreamer-vaapi_git.bb | 26 + .../libva/libva-intel-driver.inc | 24 + .../libva/libva-intel-driver_1.0.15.bb |8 ++ common/recipes-multimedia/libva/libva_1.0.15.bb|8 ++ common/recipes-multimedia/libva/va-intel.bb| 20 common/recipes-support/yasm/yasm_1.1.0.bb | 17 +++ conf/machine/include/ia32-base.inc |4 - meta-chiefriver/COPYING.MIT| 17 +++ meta-chiefriver/README | 107 +++ meta-chiefriver/README.sources | 17 +++ meta-chiefriver/conf/layer.conf| 10 ++ meta-chiefriver/conf/machine/chiefriver.conf | 19 .../formfactor/formfactor/chiefriver/machconfig|3 + .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 + .../tasks/task-core-tools-profile.bbappend |2 + .../xserver-xf86-config/chiefriver/xorg.conf | 26 + .../xorg-xserver/xserver-xf86-config_0.1.bbappend |3 + .../linux/linux-yocto-rt_3.2.bbappend |8 ++ .../recipes-kernel/linux/linux-yocto_3.2.bbappend | 10 ++ meta-crownbay/conf/machine/crownbay.conf |6 +- meta-sugarbay/conf/machine/sugarbay.conf |4 + 27 files changed, 561 insertions(+), 6 deletions(-) create mode 100644 common/recipes-bsp/amt/lms/atnetworktool-printf-fix.patch create mode 100644 common/recipes-bsp/amt/lms_7.1.20.bb create mode 100644 common/recipes-multimedia/ffmpeg/ffmpeg.inc create mode 100644 common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb create mode 100644 common/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend create mode 100644 common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb create mode 100644 common/recipes-multimedia/libva/libva-intel-driver.inc create mode 100644 common/recipes-multimedia/libva/libva-intel-driver_1.0.15.bb create mode 100644 common/recipes-multimedia/libva/libva_1.0.15.bb create mode 100644 common/recipes-multimedia/libva/va-intel.bb create mode 100644 common/recipes-support/yasm/yasm_1.1.0.bb create mode 100644 meta-chiefriver/COPYING.MIT create mode 100644 meta-chiefriver/README create mode 100644
[yocto] [PATCH 02/20] meta-intel: add gstreamer-vaapi_git recipe
From: Tom Zanussi
Based on the gstreamer-vaapi_0.2.5.bb recipe from the Yocto Project
meta-demo layer (git://git.yoctoproject.org/meta-demo):
commit a33dd433b629f08bc6517ef2ad3bdd36814ebe85
Author: Joshua Lock
Date: Tue Mar 22 12:11:42 2011 +
gstreamer-vaapi: new recipe
currently untested but will likely be useful in future so commiting it
so
that it doesn't get lost
Signed-off-by: Joshua Lock
Additional changes made by Tom Zanussi in
order to work with the other multimedia recipes in meta-intel/common:
- summary and description
- correct license
- changed into a _git recipe in order to pick up post-0.2.5 versions
- additional inherits
- tested
Signed-off-by: Tom Zanussi
---
.../gstreamer/gstreamer-vaapi_git.bb | 26
1 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb
diff --git a/common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb
b/common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb
new file mode 100644
index 000..8ffbb51
--- /dev/null
+++ b/common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb
@@ -0,0 +1,26 @@
+SUMMARY = "VA-API support to GStreamer"
+DESCRIPTION = "gstreamer-vaapi consists of a collection of VA-API \
+based plugins for GStreamer and helper libraries: `vaapidecode', \
+`vaapiconvert', and `vaapisink'."
+
+LICENSE = "LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
+
+DEPENDS = "gstreamer libva ffmpeg"
+
+# 0.2.9 tag
+SRCREV = "c98c14bd32855467a5a0ff21b6c703e9e3461467"
+PV = "0.2.9+git${SRCPV}"
+PR = "r0"
+
+SRC_URI = "git://gitorious.org/vaapi/gstreamer-vaapi.git"
+SRC_URI[md5sum] = "729d75f21df79114a8c81d896489e5ad"
+SRC_URI[sha256sum] =
"f1770c4537f1615701dbc845eee5732fbb1036b3acafbc7488e551fab334a31d"
+
+S = "${WORKDIR}/git"
+
+inherit autotools pkgconfig gtk-doc
+
+FILES_${PN} += "${libdir}/gstreamer-0.10/*.so"
+FILES_${PN}-dbg += "${libdir}/gstreamer-0.10/.debug"
+FILES_${PN}-dev += "${libdir}/gstreamer-0.10/*.la ${libdir}/gstreamer-0.10/*.a"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 05/20] ffmpeg: new recipe
From: Tom Zanussi
This is a modified version of the ffmpeg recipe from oe-classic
(git://git.openembedded.org/openembedded), updated to ffmpeg-0.7.12,
along with some changes take from meta-demo
(git://git.yoctoproject.org/meta-demo).
The starting point ffmpeg recipe taken from oe-classic version was
ffmpeg_0.6.1.bb:
commit 5316c5b1416391f15277ce867489e525b7eccd6e
Author: Andreas Oberritter
Date: Wed Dec 8 22:08:40 2010 +
ffmpeg: add recipe for 0.6.1 (LGPLv2.1+)
Signed-off-by: Andreas Oberritter
Signed-off-by: Khem Raj
The starting point ffmpeg.inc taken from oe-classic corresponds to the
starting commit:
commit 709c4d66e0b107ca606941b988bad717c0b45d9b
Author: Denys Dmytriyenko
Date: Tue Mar 17 14:32:59 2009 -0400
rename packages/ to recipes/ per earlier agreement
See links below for more details:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/21326
http://thread.gmane.org/gmane.comp.handhelds.openembedded/21816
Signed-off-by: Denys Dmytriyenko
Acked-by: Mike Westerhof
Acked-by: Philip Balister
Acked-by: Khem Raj
Acked-by: Marcin Juszkiewicz
Acked-by: Koen Kooi
Acked-by: Frans Meulenbroeks
up to the following commit:
commit 18d59f5fad41e4ea05b5d5a8c1588a0bdbdbf815
Author: Andreas Oberritter
Date: Wed Dec 8 22:08:39 2010 +
ffmpeg: set default license to GPLv2+, because --enable-gpl is used.
* See http://www.ffmpeg.org/legal.html
Signed-off-by: Andreas Oberritter
The following changes were taken from meta-demo for ffmpeg.inc:
commit 33513db7658b9c72bb8c6d477c57b2ab62dab669
Author: Joshua Lock
Date: Tue Jan 25 18:00:00 2011 +
ffmpeg: Fix some path references that broke with latest master of poky
Signed-off-by: Joshua Lock
commit ef61afc110eea1c893290079f11c96e0d560
Author: Joshua Lock
Date: Tue Mar 1 17:10:20 2011 +
ffmpeg: fix header installation
Change merged from OpenEmbedded
Signed-off-by: Joshua Lock
commit cae78e5c49423e9ce967f05a5a7c46920ca0cd6b
Author: Darren Hart
Date: Wed Nov 10 14:41:24 2010 -0800
License audit for meta-demo layer
Correct .bb and .inc files to include the proper LICENSE and
LIC_FILES_CHKSUM
variables. Note that in most cases the "(at your option) a later
version" clause
to the L?GPL is contained in a source file, not COPYING. In those case,
add a
more or less core source file to the LIC_FILES_CHKSUM list.
Signed-off-by: Darren Hart
Acked-by: Saul Wold
To get the latest bug and security fixes:
- updated to ffmpeg-0.7.12
Some additional changes were made to simplify and remove components
that weren't strictly necessary for current needs:
- removed shroedinger and libgsm dependencies
- removed faac faad2 lame dependencies
- removed --libgsm, --libmp3lame, --libschroedinger
- removed RSUGGESTS mplayer
Signed-off-by: Tom Zanussi
---
common/recipes-multimedia/ffmpeg/ffmpeg.inc | 108 +
common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb | 41
2 files changed, 149 insertions(+), 0 deletions(-)
create mode 100644 common/recipes-multimedia/ffmpeg/ffmpeg.inc
create mode 100644 common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
new file mode 100644
index 000..fc8b854
--- /dev/null
+++ b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
@@ -0,0 +1,108 @@
+DESCRIPTION = "FFmpeg is a complete solution to record, convert and stream
audio and video"
+HOMEPAGE = "http://ffmpeg.mplayerhq.hu/";
+AUTHOR = "Fabrice Bellard ffmpeg-de...@mplayerhq.hu"
+SECTION = "libs"
+PRIORITY = "optional"
+LICENSE = "GPLv2+ & LGPLv2.1+"
+
+ARM_INSTRUCTION_SET = "arm"
+
+DEPENDS = "zlib libogg libvorbis libtheora liba52"
+
+INC_PR = "r0"
+
+inherit autotools pkgconfig
+
+LEAD_SONAME = "libavcodec.so"
+
+EXTRA_OECONF = "\
+\
+--enable-pp \
+--enable-shared \
+--enable-pthreads \
+--enable-gpl \
+\
+--cross-prefix=${TARGET_PREFIX} \
+--disable-debug \
+--disable-ffserver \
+--disable-ffplay \
+\
+"
+
+EXTRA_OECONF_append_powerpc +=
"--${@['disable-altivec','enable-altivec'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1)
in ['ppce600']]}"
+
+FFMPEG_LIBS = "libavcodec libavdevice libavformat \
+ libavutil libpostproc libswscale libavfilter"
+
+SYSROOT_PREPROCESS_FUNCS = " \
+ ffmpeg_stage_cleanup \
+ ffmpeg_create_compat_links"
+
+ffmpeg_create_compat_links() {
+rm -rf ${SYSROOT_DESTDIR}${includedir}/ffmpeg
+mkdir -m 0755 ${SYSROOT_DESTDIR}${includedir}/ffmpeg
+cd ${SYSROOT_DESTDIR}${includedir}/ffmpeg
+
+for lib in ${FFMPEG_LIBS}; do
+ln -s .
[yocto] [PATCH 08/20] yasm: new recipe
From: Tom Zanussi
x86 (SSE) assembler supporting NASM and GAS-syntaxes, needed by
ffmpeg.
Taken from oe-classic (git://git.openembedded.org/openembedded):
commit 22f72e1751108cf5092332a952fcbadec5cd1a0d
Author: Khem Raj
Date: Tue Mar 22 12:21:50 2011 -0700
yasm: Upgrade yasm_0.7.2.bb -> yasm_1.1.0.bb
Signed-off-by: Khem Raj
Signed-off-by: Tom Zanussi
---
common/recipes-support/yasm/yasm_1.1.0.bb | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
create mode 100644 common/recipes-support/yasm/yasm_1.1.0.bb
diff --git a/common/recipes-support/yasm/yasm_1.1.0.bb
b/common/recipes-support/yasm/yasm_1.1.0.bb
new file mode 100644
index 000..7c3fc86
--- /dev/null
+++ b/common/recipes-support/yasm/yasm_1.1.0.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "x86 (SSE) assembler supporting NASM and GAS-syntaxes"
+LICENSE = "BSD"
+HOMEPAGE = "http://www.tortall.net/projects/yasm/";
+PR = "r0"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=26c9f3d11f88911950f9ff62189d3d4f"
+
+SRC_URI = "http://www.tortall.net/projects/yasm/releases/yasm-${PV}.tar.gz";
+
+SRC_URI[md5sum] = "8392e5f2235c2c2a981e1a633f2698cb"
+SRC_URI[sha256sum] =
"e5d56b582f3d0c30ed5c4fc221063e4175602307ea645520889458133671c232"
+
+S = "${WORKDIR}/yasm-${PV}"
+
+inherit autotools gettext
+
+BBCLASSEXTEND = "native"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 09/20] ffmpeg: add --enable-yasm
From: Tom Zanussi
Enable yasm for the ffmpeg build - we don't want a 'crippled build' or
lipsync problems.
Signed-off-by: Tom Zanussi
---
common/recipes-multimedia/ffmpeg/ffmpeg.inc |2 +-
common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
index aa11ee9..96da7c2 100644
--- a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
+++ b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
@@ -7,7 +7,7 @@ LICENSE = "GPLv2+ & LGPLv2.1+"
ARM_INSTRUCTION_SET = "arm"
-DEPENDS = "zlib libogg libvorbis libtheora liba52 libva"
+DEPENDS = "zlib libogg libvorbis libtheora liba52 libva yasm-native"
INC_PR = "r0"
diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
b/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
index 0d316d0..31442cc 100644
--- a/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
+++ b/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
@@ -27,6 +27,7 @@ EXTRA_OECONF = " \
--enable-swscale \
--enable-vaapi \
--enable-gpl \
+--enable-yasm \
--extra-cflags="${TARGET_CFLAGS} ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" \
--extra-ldflags="${TARGET_LDFLAGS}" \
--sysroot="${STAGING_DIR_TARGET}" \
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 10/20] gst-ffmpeg: add bbappend for external ffmpeg
From: Tom Zanussi We don't want gst-ffmpeg to use its own internal copy of ffmpeg, but rather an updated external version with security updates and bugfixes. So add a .bbappend that allows us to make use of --with-system-ffmpeg for that purpose. Signed-off-by: Tom Zanussi --- .../gstreamer/gst-ffmpeg_0.10.13.bbappend |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 common/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend diff --git a/common/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend b/common/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend new file mode 100644 index 000..f17a3bc --- /dev/null +++ b/common/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend @@ -0,0 +1,2 @@ +DEPENDS += "ffmpeg" +EXTRA_OECONF += "--with-system-ffmpeg" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 04/20] meta-intel: new intel-driver-1.0.15 recipe
From: Tom Zanussi
libva was split in 1.0.15 into general and Intel-specific parts. This
recipe addresses the intel-specific part. The general part is
addressed in the separate libva_1.0.15.bb recipe.
Signed-off-by: Tom Zanussi
---
.../libva/libva-intel-driver.inc | 24
.../libva/libva-intel-driver_1.0.15.bb |8 ++
2 files changed, 32 insertions(+), 0 deletions(-)
create mode 100644 common/recipes-multimedia/libva/libva-intel-driver.inc
create mode 100644 common/recipes-multimedia/libva/libva-intel-driver_1.0.15.bb
diff --git a/common/recipes-multimedia/libva/libva-intel-driver.inc
b/common/recipes-multimedia/libva/libva-intel-driver.inc
new file mode 100644
index 000..f0c6b9a
--- /dev/null
+++ b/common/recipes-multimedia/libva/libva-intel-driver.inc
@@ -0,0 +1,24 @@
+SUMMARY = "VA driver for Intel G45 & HD Graphics family"
+DESCRIPTION = "libva-driver-intel is the VA-API implementation \
+for Intel G45 chipsets and Intel HD Graphics for Intel Core \
+processor family."
+
+HOMEPAGE = "http://www.freedesktop.org/wiki/Software/vaapi";
+BUGTRACKER = "https://bugs.freedesktop.org";
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
+
+COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
+
+INC_PR = "r0"
+
+DEPENDS = "libva"
+
+S = "${WORKDIR}/intel-driver-${PV}"
+
+inherit autotools pkgconfig
+
+FILES_${PN} += "${libdir}/dri/*.so"
+FILES_${PN}-dev += "${libdir}/dri/*.la"
+FILES_${PN}-dbg += "${libdir}/dri/.debug"
diff --git a/common/recipes-multimedia/libva/libva-intel-driver_1.0.15.bb
b/common/recipes-multimedia/libva/libva-intel-driver_1.0.15.bb
new file mode 100644
index 000..6fdd6a9
--- /dev/null
+++ b/common/recipes-multimedia/libva/libva-intel-driver_1.0.15.bb
@@ -0,0 +1,8 @@
+require libva-intel-driver.inc
+
+PR = "${INC_PR}.0"
+
+SRC_URI =
"http://cgit.freedesktop.org/vaapi/intel-driver/snapshot/intel-driver-${PV}.tar.bz2";
+
+SRC_URI[md5sum] = "9dbd642f18993335146480a3a2987874"
+SRC_URI[sha256sum] =
"52f16f78129af00ec40afc6a1b8fb07c7b6c6c0da7f43a54e19afd2a41791098"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 07/20] ffmpeg: add --enable-gpl
From: Tom Zanussi
libpostproc needs --enable-gpl in order to be built. This essentially
changes ffmpeg's license to GPL v2+ as per the ffmpeg LICENSE file.
Signed-off-by: Tom Zanussi
---
common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
b/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
index 5442b0d..0d316d0 100644
--- a/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
+++ b/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
@@ -26,6 +26,7 @@ EXTRA_OECONF = " \
--enable-shared \
--enable-swscale \
--enable-vaapi \
+--enable-gpl \
--extra-cflags="${TARGET_CFLAGS} ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" \
--extra-ldflags="${TARGET_LDFLAGS}" \
--sysroot="${STAGING_DIR_TARGET}" \
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 06/20] ffmpeg: add --enable-vaapi
From: Tom Zanussi
Turn on vaapi support in ffmpeg to allow video acceleration via vaapi.
Signed-off-by: Tom Zanussi
---
common/recipes-multimedia/ffmpeg/ffmpeg.inc |2 +-
common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
index fc8b854..aa11ee9 100644
--- a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
+++ b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
@@ -7,7 +7,7 @@ LICENSE = "GPLv2+ & LGPLv2.1+"
ARM_INSTRUCTION_SET = "arm"
-DEPENDS = "zlib libogg libvorbis libtheora liba52"
+DEPENDS = "zlib libogg libvorbis libtheora liba52 libva"
INC_PR = "r0"
diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
b/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
index 023c25f..5442b0d 100644
--- a/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
+++ b/common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
@@ -25,6 +25,7 @@ EXTRA_OECONF = " \
--enable-pthreads \
--enable-shared \
--enable-swscale \
+--enable-vaapi \
--extra-cflags="${TARGET_CFLAGS} ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" \
--extra-ldflags="${TARGET_LDFLAGS}" \
--sysroot="${STAGING_DIR_TARGET}" \
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 11/20] gst-va-intel: add conditional vaapi implementation
From: Tom Zanussi
Use different versions of vaapi interface implementaion depending on
what a machine specifies. The default if no MACHINE_FEATURE is
specified is gstreamer-vaapi. Other machines may need a different
implementation e.g. a machine using emgd would specify
'gst-va-mixvideo' in its MACHINE_FEATURES in order to have the
implementation satisfied by emgd instead of gstreamer-vaapi, which
this also implements.
Signed-off-by: Tom Zanussi
---
.../recipes-multimedia/gstreamer/gst-va-intel.bb | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/common/recipes-multimedia/gstreamer/gst-va-intel.bb
b/common/recipes-multimedia/gstreamer/gst-va-intel.bb
index 31bde4e..4f7fe9f 100644
--- a/common/recipes-multimedia/gstreamer/gst-va-intel.bb
+++ b/common/recipes-multimedia/gstreamer/gst-va-intel.bb
@@ -6,10 +6,14 @@ LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3
PR = "r0"
+VAAPI_IMPL = "${@base_contains('MACHINE_FEATURES', 'gst-va-mixvideo',
'gst-va-mixvideo-vaapi', \
+ 'gst-va-intel-vaapi', d)}"
+
PACKAGES = "\
gst-va-intel \
gst-va-intel-general \
gst-va-intel-video \
+${VAAPI_IMPL} \
"
ALLOW_EMPTY = "1"
@@ -17,6 +21,7 @@ ALLOW_EMPTY = "1"
RDEPENDS_gst-va-intel = "\
gst-va-intel-general \
gst-va-intel-video \
+${VAAPI_IMPL} \
"
RDEPENDS_gst-va-intel-general = "\
@@ -26,3 +31,11 @@ RDEPENDS_gst-va-intel-general = "\
RDEPENDS_gst-va-intel-video = "\
gst-plugins-good-isomp4 \
"
+
+RDEPENDS_gst-va-intel-vaapi = "\
+gstreamer-vaapi \
+"
+
+RDEPENDS_gst-va-mixvideo-vaapi = "\
+emgd-driver-bin \
+"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 01/20] meta-chiefriver: new layer for Chief River (Ivy Bridge/Panther Point) systems
From: Tom Zanussi This layer provides support for Ivy Bridge + Panther Point Intel systems. Signed-off-by: Tom Zanussi --- meta-chiefriver/COPYING.MIT| 17 +++ meta-chiefriver/README | 107 meta-chiefriver/README.sources | 17 +++ meta-chiefriver/conf/layer.conf| 10 ++ meta-chiefriver/conf/machine/chiefriver.conf | 15 +++ .../formfactor/formfactor/chiefriver/machconfig|3 + .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 + .../tasks/task-core-tools-profile.bbappend |2 + .../xserver-xf86-config/chiefriver/xorg.conf | 26 + .../xorg-xserver/xserver-xf86-config_0.1.bbappend |3 + .../linux/linux-yocto-rt_3.2.bbappend |8 ++ .../recipes-kernel/linux/linux-yocto_3.2.bbappend |8 ++ 12 files changed, 219 insertions(+), 0 deletions(-) create mode 100644 meta-chiefriver/COPYING.MIT create mode 100644 meta-chiefriver/README create mode 100644 meta-chiefriver/README.sources create mode 100644 meta-chiefriver/conf/layer.conf create mode 100644 meta-chiefriver/conf/machine/chiefriver.conf create mode 100644 meta-chiefriver/recipes-bsp/formfactor/formfactor/chiefriver/machconfig create mode 100644 meta-chiefriver/recipes-bsp/formfactor/formfactor_0.0.bbappend create mode 100644 meta-chiefriver/recipes-core/tasks/task-core-tools-profile.bbappend create mode 100644 meta-chiefriver/recipes-graphics/xorg-xserver/xserver-xf86-config/chiefriver/xorg.conf create mode 100644 meta-chiefriver/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend create mode 100644 meta-chiefriver/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend create mode 100644 meta-chiefriver/recipes-kernel/linux/linux-yocto_3.2.bbappend diff --git a/meta-chiefriver/COPYING.MIT b/meta-chiefriver/COPYING.MIT new file mode 100644 index 000..fb950dc --- /dev/null +++ b/meta-chiefriver/COPYING.MIT @@ -0,0 +1,17 @@ +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +THE SOFTWARE. diff --git a/meta-chiefriver/README b/meta-chiefriver/README new file mode 100644 index 000..49e4461 --- /dev/null +++ b/meta-chiefriver/README @@ -0,0 +1,107 @@ +This README file contains information on building the meta-chiefriver +BSP layer, and booting the images contained in the /binary directory. +Please see the corresponding sections below for details. + +The 'Chief River' platform consists of the Intel Ivy Bridge processor, +plus the Panther Point PCH. This BSP assumes that the Ivy Bridge +integrated graphics are being used. + + +Dependencies + + +This layer depends on: + + URI: git://git.openembedded.org/bitbake + branch: master + + URI: git://git.openembedded.org/openembedded-core + layers: meta + branch: master + + URI: git://git.yoctoproject.org/meta-intel + layers: intel + branch: master + + +Table of Contents += + + I. Building the meta-chiefriver BSP layer + II. Booting the images in /binary + + +I. Building the meta-chiefriver BSP layer += + +In order to build an image with BSP support for a given release, you +need to download the corresponding BSP tarball from the 'Board Support +Package (BSP) Downloads' page of the Yocto Project website. + +Having done that, and assuming you extracted the BSP tarball contents +at the top-level of your yocto build tree, you can build a chiefriver +image by adding the location of the meta-chiefriver layer to +bblayers.conf, along with the meta-intel layer itself (to access +common metadata shared between BSPs) e.g.: + + yocto/meta-intel \ + yocto/meta-intel/meta-chiefriver \ + +To enable the chiefriver layer, add the chiefriver MACHINE to local.conf: + + MACHINE ?= "chiefriver" + +You should then be able to build a chiefriver image as such: + + $ source oe-init-build-env + $ bitbake core-image-sato + +At the end of a successful build, you should have a
[yocto] [PATCH 12/20] va-intel: new package
From: Tom Zanussi
We need some libraries for video acceleration which depend on the
video implementation being used e.g. vanilla intel vs emgd, so create
a new 'va-intel' package group for them.
Signed-off-by: Tom Zanussi
---
common/recipes-multimedia/libva/va-intel.bb | 20
1 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 common/recipes-multimedia/libva/va-intel.bb
diff --git a/common/recipes-multimedia/libva/va-intel.bb
b/common/recipes-multimedia/libva/va-intel.bb
new file mode 100644
index 000..3ce857a
--- /dev/null
+++ b/common/recipes-multimedia/libva/va-intel.bb
@@ -0,0 +1,20 @@
+DESCRIPTION = "Video Acceleration Add-ons for Intel BSPs"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+PR = "r0"
+
+VA_IMPL = "${@base_contains('MACHINE_FEATURES', 'gst-va-mixvideo', \
+ 'libva libva-x11 libva-tpi libva-glx libva-egl', \
+ 'libva libva-intel-driver', d)}"
+
+PACKAGES = "\
+va-intel \
+"
+
+ALLOW_EMPTY = "1"
+
+RDEPENDS_va-intel = " \
+${VA_IMPL} \
+"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 03/20] meta-intel: new libva-1.0.15 recipe
From: Tom Zanussi
This upgrades libva to libva-1.0.15. Intel-specific changes have been
split out into intel-driver-1.0.15, contained in a separate recipe.
Signed-off-by: Tom Zanussi
---
common/recipes-multimedia/libva/libva_1.0.15.bb |8
1 files changed, 8 insertions(+), 0 deletions(-)
create mode 100644 common/recipes-multimedia/libva/libva_1.0.15.bb
diff --git a/common/recipes-multimedia/libva/libva_1.0.15.bb
b/common/recipes-multimedia/libva/libva_1.0.15.bb
new file mode 100644
index 000..e60a4b6
--- /dev/null
+++ b/common/recipes-multimedia/libva/libva_1.0.15.bb
@@ -0,0 +1,8 @@
+require libva.inc
+
+PR = "${INC_PR}.0"
+
+SRC_URI =
"http://cgit.freedesktop.org/vaapi/libva/snapshot/libva-${PV}.tar.bz2";
+
+SRC_URI[md5sum] = "ad8a94ba87ff0563a533c3c142816794"
+SRC_URI[sha256sum] =
"7cc24ae9c947aa13904255244810d3637b03d41e2b6f4b643db3b97412cacd37"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 13/20] gst-va-intel: clarify DESCRIPTION
From: Tom Zanussi
Modify the description to clarify that these are gstreamer addons.
Signed-off-by: Tom Zanussi
---
.../recipes-multimedia/gstreamer/gst-va-intel.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/recipes-multimedia/gstreamer/gst-va-intel.bb
b/common/recipes-multimedia/gstreamer/gst-va-intel.bb
index 4f7fe9f..17cb7c8 100644
--- a/common/recipes-multimedia/gstreamer/gst-va-intel.bb
+++ b/common/recipes-multimedia/gstreamer/gst-va-intel.bb
@@ -1,4 +1,4 @@
-DESCRIPTION = "Video Acceleration Add-ons for Intel BSPs"
+DESCRIPTION = "GStreamer Video Acceleration Add-ons for Intel BSPs"
LICENSE = "MIT"
DEPENDS = "gst-meta-base"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 14/20] meta-intel: remove video acceleration from emgd XSERVER
From: Tom Zanussi Video acceleration dependencies really don't belong in the XSERVER variable - remove them; we'll add them back later via va-intel. Signed-off-by: Tom Zanussi --- conf/machine/include/ia32-base.inc |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/conf/machine/include/ia32-base.inc b/conf/machine/include/ia32-base.inc index be1c8e0..99ac352 100644 --- a/conf/machine/include/ia32-base.inc +++ b/conf/machine/include/ia32-base.inc @@ -57,10 +57,6 @@ XSERVER_IA32_I965 = "xf86-video-intel \ " XSERVER_IA32_EMGD = "emgd-driver-bin \ - libva-x11 \ - libva-tpi \ - libva-glx \ - libva-egl \ " XSERVER_IA32_VESA = "xf86-video-vesa" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 15/20] meta-chiefriver: use gst-va-intel and va-intel
From: Tom Zanussi
Have chiefriver use gst-va-intel and va-intel so we can easily test
and make use of the video acceleration capabilities of this machine.
Signed-off-by: Tom Zanussi
---
meta-chiefriver/conf/machine/chiefriver.conf |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta-chiefriver/conf/machine/chiefriver.conf
b/meta-chiefriver/conf/machine/chiefriver.conf
index c9237f4..a78e4fd 100644
--- a/meta-chiefriver/conf/machine/chiefriver.conf
+++ b/meta-chiefriver/conf/machine/chiefriver.conf
@@ -13,3 +13,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
${XSERVER_IA32_I965} \
"
+
+VA_FEATURES ?= "gst-va-intel va-intel"
+
+MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 16/20] meta-sugarbay: use gst-va-intel and va-intel
From: Tom Zanussi
Have sugarbay use gst-va-intel and va-intel so we can easily test and
make use of the video acceleration capabilities of this machine.
Signed-off-by: Tom Zanussi
---
meta-sugarbay/conf/machine/sugarbay.conf |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta-sugarbay/conf/machine/sugarbay.conf
b/meta-sugarbay/conf/machine/sugarbay.conf
index a44f918..adb1fa7 100644
--- a/meta-sugarbay/conf/machine/sugarbay.conf
+++ b/meta-sugarbay/conf/machine/sugarbay.conf
@@ -13,3 +13,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
${XSERVER_IA32_I965} \
"
+
+VA_FEATURES ?= "gst-va-intel va-intel"
+
+MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 17/20] meta-crownbay: use gst-va-intel and va-intel and gst-va-mixvideo
From: Tom Zanussi
Have crownbay use gst-va-intel and va-intel so we can easily test and
make use of the video acceleration capabilities of this machine.
Also have it use the gst-va-mixvideo so the emgd mixvideo components
get selected.
Signed-off-by: Tom Zanussi
---
meta-crownbay/conf/machine/crownbay.conf |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index 0d432ca..a39d037 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -9,6 +9,8 @@ PREFERRED_VERSION_linux-yocto ?= "3.2%"
require conf/machine/include/tune-atom.inc
require conf/machine/include/ia32-base.inc
+MACHINE_FEATURES += "gst-va-mixvideo"
+
XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
${XSERVER_IA32_EMGD} \
@@ -20,4 +22,6 @@ PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
APPEND += "video=vesafb vga=0x318"
-MACHINE_EXTRA_RRECOMMENDS += "gst-va-intel"
+VA_FEATURES ?= "gst-va-intel va-intel"
+
+MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 18/20] lms: new recipe
From: Tom Zanussi
Add support for the Intel Active Management Technology (AMT) Local
Manageability Service (LMS) daemon.
The Intel LMS daemon allows applications to access the Intel AMT
firmware via the Intel Management Engine Interface (MEI).
Signed-off-by: Tom Zanussi
---
.../amt/lms/atnetworktool-printf-fix.patch | 14 +++
common/recipes-bsp/amt/lms_7.1.20.bb | 42
2 files changed, 56 insertions(+), 0 deletions(-)
create mode 100644 common/recipes-bsp/amt/lms/atnetworktool-printf-fix.patch
create mode 100644 common/recipes-bsp/amt/lms_7.1.20.bb
diff --git a/common/recipes-bsp/amt/lms/atnetworktool-printf-fix.patch
b/common/recipes-bsp/amt/lms/atnetworktool-printf-fix.patch
new file mode 100644
index 000..d3a6284
--- /dev/null
+++ b/common/recipes-bsp/amt/lms/atnetworktool-printf-fix.patch
@@ -0,0 +1,14 @@
+Index: lms-7.1.20/src/tools/ATNetworkTool.cpp
+===
+--- lms-7.1.20.orig/src/tools/ATNetworkTool.cpp2012-04-30
23:24:56.693879920 -0500
lms-7.1.20/src/tools/ATNetworkTool.cpp 2012-04-30 23:25:32.363473948
-0500
+@@ -302,7 +302,9 @@
+ close(s);
+ return -1;
+ }
++#ifdef LMS_NET_DEBUG
+ printf("successfully binded local\n");
++#endif
+
+ }
+ if (bind(s, addr, addrlen) == -1) {
diff --git a/common/recipes-bsp/amt/lms_7.1.20.bb
b/common/recipes-bsp/amt/lms_7.1.20.bb
new file mode 100644
index 000..fb1aaec
--- /dev/null
+++ b/common/recipes-bsp/amt/lms_7.1.20.bb
@@ -0,0 +1,42 @@
+DESCRIPTION = "Intel Local Manageability Service allows applications \
+to access the Intel Active Management Technology (AMT) firmware via \
+the Intel Management Engine Interface (MEI)."
+HOMEPAGE =
"http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers";
+
+LICENSE = "Modified BSD"
+
+PR = "r0"
+SRC_URI = "http://software.intel.com/file/37962 \
+ file://atnetworktool-printf-fix.patch"
+
+COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=7264184cf88d9f27b719a9656255b47b"
+
+SRC_URI[md5sum] = "687b76e78bfdbcf567c0e842c1fe240a"
+SRC_URI[sha256sum] =
"cc0457f0044e924794bb1aeae9a72c28666a525cd8a963d0d92970222946e75b"
+
+inherit autotools update-rc.d
+
+INITSCRIPT_NAME = "lms"
+INITSCRIPT_PARAMS = "defaults"
+
+PV_SUB = "25"
+
+do_unpack2() {
+# The downloaded 37962 filename is actually lms+7.1.20.25.zip.
+# It contains lms-7.1.20-25.tar.gz.
+# It contains lms-7.1.20-25.tar.gz untars to lms-7.1.20
+mv ${WORKDIR}/37962 ${WORKDIR}/${PN}+${PV}.${PV_SUB}.zip
+unzip -o ${WORKDIR}/${PN}+${PV}.${PV_SUB}.zip
+mv ${WORKDIR}/${PN}-${PV}/outputdir/${PN}-${PV}-${PV_SUB}.tar.gz
${WORKDIR}/
+cd ${WORKDIR}
+tar -xvzf ${PN}-${PV}-${PV_SUB}.tar.gz
+}
+
+addtask unpack2 after do_unpack before do_patch
+
+do_install_append () {
+ install -d ${D}${sysconfdir}/init.d
+ install -m 0755 ${WORKDIR}/${PN}-${PV}/scripts/lms
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
+}
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 19/20] meta-chiefriver: use lms
From: Tom Zanussi
Chiefriver needs lms support for AMT, add it.
Signed-off-by: Tom Zanussi
---
meta-chiefriver/conf/machine/chiefriver.conf |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta-chiefriver/conf/machine/chiefriver.conf
b/meta-chiefriver/conf/machine/chiefriver.conf
index a78e4fd..4a35913 100644
--- a/meta-chiefriver/conf/machine/chiefriver.conf
+++ b/meta-chiefriver/conf/machine/chiefriver.conf
@@ -16,4 +16,4 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
VA_FEATURES ?= "gst-va-intel va-intel"
-MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
+MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES} lms"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 20/20] meta-chiefriver: use the mei kernel feature
From: Tom Zanussi Add AMT/mei support as a kernel feature here instead of in the linux-yocto metadata - mei support is currently a feature in staging, and not everyone might want a tainted kernel. Signed-off-by: Tom Zanussi --- .../recipes-kernel/linux/linux-yocto_3.2.bbappend |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta-chiefriver/recipes-kernel/linux/linux-yocto_3.2.bbappend b/meta-chiefriver/recipes-kernel/linux/linux-yocto_3.2.bbappend index 0b707be..083ddfb 100644 --- a/meta-chiefriver/recipes-kernel/linux/linux-yocto_3.2.bbappend +++ b/meta-chiefriver/recipes-kernel/linux/linux-yocto_3.2.bbappend @@ -4,5 +4,7 @@ COMPATIBLE_MACHINE_chiefriver = "chiefriver" KMACHINE_chiefriver = "chiefriver" KBRANCH_chiefriver = "standard/default/common-pc-64/chiefriver" +KERNEL_FEATURES_append_chiefriver = " features/amt/mei" + SRCREV_machine_pn-linux-yocto_chiefriver ?= "dbe820c277dfa6cbc249d410e8b083286ec484b7" SRCREV_meta_pn-linux-yocto_chiefriver ?= "353d43d340e87996b4be4c5f6ddb4447e050b65c" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 00/20] meta-intel: new chiefriver BSP and supporting recipes
On Wed, May 23, 2012 at 4:52 PM, wrote: > From: Tom Zanussi > > This patchset implements a new BSP for the 'Chief River' platform, which > consists of the Intel Ivy Bridge processor and Panther Point PCH. It > assumes that the Ivy Bridge integrated graphics are being used. > > It also adds a few new recipes related to video acceleration which are > modified versions of oe-core or yocto meta-demo recipes (ffmpeg, > yasm-native, gstreamer-vaapi), along with tweaks needed to work with > intel video acceleration components. > > There are also some new intel-specific video acceleration components > (libva-1.0.15, intel-driver-1.0.15, va-intel) either needed for video > acceleration on Intel platforms, or allowing for easier integration > with the existing meta-intel BSPs. These finally allow the chiefriver, > sugarbay, and crownbay BSPs to share a common set of video components, > and have been tested with all three. > > Finally, there's a new recipe for the Intel Local Manageability Service > (LMS), which allows Intel BSPs to access the Intel Active Management > Technology (AMT) firmware via the Intel Management Engine Interface (MEI), > which is used by the Chief River BSP. For some reason gmail dropped most of this series on me. Just so I'm sure, is there a board description as part of this series for the kernel tree ? Or is that still pending ? Cheers, Bruce > > The following changes since commit a62c485edffed30ea95658760948fd50925adfb0: > Darren Hart (1): > linux-yocto_3.0: Update KMACHINE and KBRANCH to play nice with new > kerntools > > are available in the git repository at: > > git://git.yoctoproject.org/meta-intel.git tzanussi/chiefriver.v1 > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/chiefriver.v1 > > Tom Zanussi (20): > meta-chiefriver: new layer for Chief River (Ivy Bridge/Panther Point) > systems > meta-intel: add gstreamer-vaapi_git recipe > meta-intel: new libva-1.0.15 recipe > meta-intel: new intel-driver-1.0.15 recipe > ffmpeg: new recipe > ffmpeg: add --enable-vaapi > ffmpeg: add --enable-gpl > yasm: new recipe > ffmpeg: add --enable-yasm > gst-ffmpeg: add bbappend for external ffmpeg > gst-va-intel: add conditional vaapi implementation > va-intel: new package > gst-va-intel: clarify DESCRIPTION > meta-intel: remove video acceleration from emgd XSERVER > meta-chiefriver: use gst-va-intel and va-intel > meta-sugarbay: use gst-va-intel and va-intel > meta-crownbay: use gst-va-intel and va-intel and gst-va-mixvideo > lms: new recipe > meta-chiefriver: use lms > meta-chiefriver: use the mei kernel feature > > .../amt/lms/atnetworktool-printf-fix.patch | 14 +++ > common/recipes-bsp/amt/lms_7.1.20.bb | 42 > common/recipes-multimedia/ffmpeg/ffmpeg.inc | 108 > > common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb | 44 > .../gstreamer/gst-ffmpeg_0.10.13.bbappend | 2 + > .../recipes-multimedia/gstreamer/gst-va-intel.bb | 15 +++- > .../gstreamer/gstreamer-vaapi_git.bb | 26 + > .../libva/libva-intel-driver.inc | 24 + > .../libva/libva-intel-driver_1.0.15.bb | 8 ++ > common/recipes-multimedia/libva/libva_1.0.15.bb | 8 ++ > common/recipes-multimedia/libva/va-intel.bb | 20 > common/recipes-support/yasm/yasm_1.1.0.bb | 17 +++ > conf/machine/include/ia32-base.inc | 4 - > meta-chiefriver/COPYING.MIT | 17 +++ > meta-chiefriver/README | 107 +++ > meta-chiefriver/README.sources | 17 +++ > meta-chiefriver/conf/layer.conf | 10 ++ > meta-chiefriver/conf/machine/chiefriver.conf | 19 > .../formfactor/formfactor/chiefriver/machconfig | 3 + > .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 3 + > .../tasks/task-core-tools-profile.bbappend | 2 + > .../xserver-xf86-config/chiefriver/xorg.conf | 26 + > .../xorg-xserver/xserver-xf86-config_0.1.bbappend | 3 + > .../linux/linux-yocto-rt_3.2.bbappend | 8 ++ > .../recipes-kernel/linux/linux-yocto_3.2.bbappend | 10 ++ > meta-crownbay/conf/machine/crownbay.conf | 6 +- > meta-sugarbay/conf/machine/sugarbay.conf | 4 + > 27 files changed, 561 insertions(+), 6 deletions(-) > create mode 100644 common/recipes-bsp/amt/lms/atnetworktool-printf-fix.patch > create mode 100644 common/recipes-bsp/amt/lms_7.1.20.bb > create mode 100644 common/recipes-multimedia/ffmpeg/ffmpeg.inc > create mode 100644 common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb > create mode 100644 > common/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend > create mode 100644 common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb > create mode 100644 common/recipes-multimedia/libva/libva-intel-driver.in
Re: [yocto] [PATCH 00/20] meta-intel: new chiefriver BSP and supporting recipes
On Wed, 2012-05-23 at 17:26 -0300, Bruce Ashfield wrote: > On Wed, May 23, 2012 at 4:52 PM, wrote: > > From: Tom Zanussi > > > > This patchset implements a new BSP for the 'Chief River' platform, which > > consists of the Intel Ivy Bridge processor and Panther Point PCH. It > > assumes that the Ivy Bridge integrated graphics are being used. > > > > It also adds a few new recipes related to video acceleration which are > > modified versions of oe-core or yocto meta-demo recipes (ffmpeg, > > yasm-native, gstreamer-vaapi), along with tweaks needed to work with > > intel video acceleration components. > > > > There are also some new intel-specific video acceleration components > > (libva-1.0.15, intel-driver-1.0.15, va-intel) either needed for video > > acceleration on Intel platforms, or allowing for easier integration > > with the existing meta-intel BSPs. These finally allow the chiefriver, > > sugarbay, and crownbay BSPs to share a common set of video components, > > and have been tested with all three. > > > > Finally, there's a new recipe for the Intel Local Manageability Service > > (LMS), which allows Intel BSPs to access the Intel Active Management > > Technology (AMT) firmware via the Intel Management Engine Interface (MEI), > > which is used by the Chief River BSP. > > For some reason gmail dropped most of this series on me. Just so I'm sure, > is there a board description as part of this series for the kernel > tree ? Or is that > still pending ? > Yeah, still forthcoming - I didn't post it because you're on vacation (I assume that's still correct). I think Darren and I wanted to consolidate the kernel stuff anyway, so it'll come with that... I also may have some further tweaks as well, so for all those reasons, don't worry about it quite yet. ;-) Tom > Cheers, > > Bruce > > > > > The following changes since commit a62c485edffed30ea95658760948fd50925adfb0: > > Darren Hart (1): > >linux-yocto_3.0: Update KMACHINE and KBRANCH to play nice with new > > kerntools > > > > are available in the git repository at: > > > > git://git.yoctoproject.org/meta-intel.git tzanussi/chiefriver.v1 > > > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/chiefriver.v1 > > > > Tom Zanussi (20): > > meta-chiefriver: new layer for Chief River (Ivy Bridge/Panther Point) > >systems > > meta-intel: add gstreamer-vaapi_git recipe > > meta-intel: new libva-1.0.15 recipe > > meta-intel: new intel-driver-1.0.15 recipe > > ffmpeg: new recipe > > ffmpeg: add --enable-vaapi > > ffmpeg: add --enable-gpl > > yasm: new recipe > > ffmpeg: add --enable-yasm > > gst-ffmpeg: add bbappend for external ffmpeg > > gst-va-intel: add conditional vaapi implementation > > va-intel: new package > > gst-va-intel: clarify DESCRIPTION > > meta-intel: remove video acceleration from emgd XSERVER > > meta-chiefriver: use gst-va-intel and va-intel > > meta-sugarbay: use gst-va-intel and va-intel > > meta-crownbay: use gst-va-intel and va-intel and gst-va-mixvideo > > lms: new recipe > > meta-chiefriver: use lms > > meta-chiefriver: use the mei kernel feature > > > > .../amt/lms/atnetworktool-printf-fix.patch | 14 +++ > > common/recipes-bsp/amt/lms_7.1.20.bb | 42 > > common/recipes-multimedia/ffmpeg/ffmpeg.inc| 108 > > > > common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb | 44 > > .../gstreamer/gst-ffmpeg_0.10.13.bbappend |2 + > > .../recipes-multimedia/gstreamer/gst-va-intel.bb | 15 +++- > > .../gstreamer/gstreamer-vaapi_git.bb | 26 + > > .../libva/libva-intel-driver.inc | 24 + > > .../libva/libva-intel-driver_1.0.15.bb |8 ++ > > common/recipes-multimedia/libva/libva_1.0.15.bb|8 ++ > > common/recipes-multimedia/libva/va-intel.bb| 20 > > common/recipes-support/yasm/yasm_1.1.0.bb | 17 +++ > > conf/machine/include/ia32-base.inc |4 - > > meta-chiefriver/COPYING.MIT| 17 +++ > > meta-chiefriver/README | 107 > > +++ > > meta-chiefriver/README.sources | 17 +++ > > meta-chiefriver/conf/layer.conf| 10 ++ > > meta-chiefriver/conf/machine/chiefriver.conf | 19 > > .../formfactor/formfactor/chiefriver/machconfig|3 + > > .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 + > > .../tasks/task-core-tools-profile.bbappend |2 + > > .../xserver-xf86-config/chiefriver/xorg.conf | 26 + > > .../xorg-xserver/xserver-xf86-config_0.1.bbappend |3 + > > .../linux/linux-yocto-rt_3.2.bbappend |8 ++ > > .../recipes-kernel/linux/linux-yocto_3.2.bbappend | 10 ++ > > meta-crownbay/conf/machine/crownbay.conf |6 +- > > meta-sugarbay/conf/machine/sugarbay.conf |4 + > > 2
Re: [yocto] [ANNOUNCEMENT] Cedar Trail with PowerVR for Edison 6.0.1
Please see section 1.4 of the bsp-guide (http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html) including the following text: " Note Pre-compiled images are bundled with a time-limited kernel that runs for a predetermined amount of time (10 days) before it forces the system to reboot. This limitation is meant to discourage direct redistribution of the image. You must eventually rebuild the image if you want to remove this restriction." Thanks Rahul -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Wolfgang Denk Sent: Tuesday, May 22, 2012 10:45 PM To: Flanagan, Elizabeth Cc: yocto-annou...@yoctoproject.org; yocto@yoctoproject.org Subject: Re: [yocto] [ANNOUNCEMENT] Cedar Trail with PowerVR for Edison 6.0.1 Dear Elizabeth, In message you wrote: > > This release enables the BSP to use the latest available kernel > patches for Intel's PowerVR graphics driver. The BSP image includes > time limited kernel images for testing purposes. This is probaby a stupid question, so I apologize in advance: What is a time limited kernel image? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You have the capacity to learn from mistakes. You'll learn a lot today. ___ 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] [PATCH 00/20] meta-intel: new chiefriver BSP and supporting recipes
On Wed, May 23, 2012 at 5:31 PM, Tom Zanussi wrote: > On Wed, 2012-05-23 at 17:26 -0300, Bruce Ashfield wrote: >> On Wed, May 23, 2012 at 4:52 PM, wrote: >> > From: Tom Zanussi >> > >> > This patchset implements a new BSP for the 'Chief River' platform, which >> > consists of the Intel Ivy Bridge processor and Panther Point PCH. It >> > assumes that the Ivy Bridge integrated graphics are being used. >> > >> > It also adds a few new recipes related to video acceleration which are >> > modified versions of oe-core or yocto meta-demo recipes (ffmpeg, >> > yasm-native, gstreamer-vaapi), along with tweaks needed to work with >> > intel video acceleration components. >> > >> > There are also some new intel-specific video acceleration components >> > (libva-1.0.15, intel-driver-1.0.15, va-intel) either needed for video >> > acceleration on Intel platforms, or allowing for easier integration >> > with the existing meta-intel BSPs. These finally allow the chiefriver, >> > sugarbay, and crownbay BSPs to share a common set of video components, >> > and have been tested with all three. >> > >> > Finally, there's a new recipe for the Intel Local Manageability Service >> > (LMS), which allows Intel BSPs to access the Intel Active Management >> > Technology (AMT) firmware via the Intel Management Engine Interface (MEI), >> > which is used by the Chief River BSP. >> >> For some reason gmail dropped most of this series on me. Just so I'm sure, >> is there a board description as part of this series for the kernel >> tree ? Or is that >> still pending ? >> > > Yeah, still forthcoming - I didn't post it because you're on vacation (I > assume that's still correct). I think Darren and I wanted to > consolidate the kernel stuff anyway, so it'll come with that... Perfect. Yes, I'm still on vacation .. but my gmail follows me around, so I peeked in after a couple of days and wondered what it had done with those missing email .. one less thing to hunt down out of the thousands of email when I get back to my inbox. It is most appreciated that a few less email splashed down while I was out :) Cheers, Bruce > > I also may have some further tweaks as well, so for all those reasons, > don't worry about it quite yet. ;-) > > Tom > >> Cheers, >> >> Bruce >> >> > >> > The following changes since commit >> > a62c485edffed30ea95658760948fd50925adfb0: >> > Darren Hart (1): >> > linux-yocto_3.0: Update KMACHINE and KBRANCH to play nice with new >> > kerntools >> > >> > are available in the git repository at: >> > >> > git://git.yoctoproject.org/meta-intel.git tzanussi/chiefriver.v1 >> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/chiefriver.v1 >> > >> > Tom Zanussi (20): >> > meta-chiefriver: new layer for Chief River (Ivy Bridge/Panther Point) >> > systems >> > meta-intel: add gstreamer-vaapi_git recipe >> > meta-intel: new libva-1.0.15 recipe >> > meta-intel: new intel-driver-1.0.15 recipe >> > ffmpeg: new recipe >> > ffmpeg: add --enable-vaapi >> > ffmpeg: add --enable-gpl >> > yasm: new recipe >> > ffmpeg: add --enable-yasm >> > gst-ffmpeg: add bbappend for external ffmpeg >> > gst-va-intel: add conditional vaapi implementation >> > va-intel: new package >> > gst-va-intel: clarify DESCRIPTION >> > meta-intel: remove video acceleration from emgd XSERVER >> > meta-chiefriver: use gst-va-intel and va-intel >> > meta-sugarbay: use gst-va-intel and va-intel >> > meta-crownbay: use gst-va-intel and va-intel and gst-va-mixvideo >> > lms: new recipe >> > meta-chiefriver: use lms >> > meta-chiefriver: use the mei kernel feature >> > >> > .../amt/lms/atnetworktool-printf-fix.patch | 14 +++ >> > common/recipes-bsp/amt/lms_7.1.20.bb | 42 >> > common/recipes-multimedia/ffmpeg/ffmpeg.inc | 108 >> > >> > common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb | 44 >> > .../gstreamer/gst-ffmpeg_0.10.13.bbappend | 2 + >> > .../recipes-multimedia/gstreamer/gst-va-intel.bb | 15 +++- >> > .../gstreamer/gstreamer-vaapi_git.bb | 26 + >> > .../libva/libva-intel-driver.inc | 24 + >> > .../libva/libva-intel-driver_1.0.15.bb | 8 ++ >> > common/recipes-multimedia/libva/libva_1.0.15.bb | 8 ++ >> > common/recipes-multimedia/libva/va-intel.bb | 20 >> > common/recipes-support/yasm/yasm_1.1.0.bb | 17 +++ >> > conf/machine/include/ia32-base.inc | 4 - >> > meta-chiefriver/COPYING.MIT | 17 +++ >> > meta-chiefriver/README | 107 >> > +++ >> > meta-chiefriver/README.sources | 17 +++ >> > meta-chiefriver/conf/layer.conf | 10 ++ >> > meta-chiefriver/conf/machine/chiefriver.conf | 19 >> > .../formfactor/formfactor/chiefriver/machconfig | 3 + >> > .../recipes-bsp/form
Re: [yocto] bitbake failure on meta-cedartrail using master branch
On 05/23/2012 02:24 PM, Darren Hart wrote: On 05/23/2012 04:59 AM, jfabernathy wrote: FYI, I just pulled the lasted patches into my system and ran a bitbake of cedartrail with the PVR driver. I have a fix for this, was waiting for an Ack and got side tracked. Please pull meta-intel again and try again with the master branch. You should have the following commit now: commit a62c485edffed30ea95658760948fd50925adfb0 Author: Darren Hart Date: Fri May 18 09:19:31 2012 -0700 linux-yocto_3.0: Update KMACHINE and KBRANCH to play nice with new kerntools Thanks, Darren Thanks, that got past it. Jim A I got a failure on the kernel build. log below: ERROR: Logfile of failure stored in: /build/cdv-master/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.24+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+81fd8c307997aff37916828dc8b4ef72f5d35a94-r4/temp/log.do_patch.29202 Log data follows: | Branch meta-temp set up to track remote branch meta from origin. | git reset --mixed 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc | Deleted branch meta-temp (was 620917d). | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 434: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 436: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 437: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 438: yocto/standard/cedartrail-standard.scc: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/updateme: line 441: yocto/standard/cedartrail-standard.scc: No such file or directory | readlink: missing operand | Try `readlink --help' for more information. | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /build/cdv-master/tmp/sysroots/x86_64-linux/usr/bin/scc: line 399: yocto/standard/cedartrail-standard: No such file or directory | /
[yocto] RFC: Merging commits from into the main denzil branch
Hello all, As most of you know, I've been pulling commits into a pair of sgarman/denzil-next branches which are intended to eventually become the next Denzil point-release, 1.2.1. oe-core based branch: http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next poky based branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next So far I haven't merged or requested to merge any of these commits into the main denzil branches of oe-core and poky, for two main reasons: 1. I've only performed the most basic build testing of these branches on a desktop system, building core-image-minimal and core-image-sato for our 5 qemu machines. 2. To date, we haven't had a clear process on how to transition from the maintainer's personal branch into the official repo branch. I'd like to develop a clear and documented process on doing this that involves community feedback on the commits. Just this week I've been able to start using the Yocto autobuilder to do more comprehensive testing of my denzil-next branch, so issue #1 is finally resolved, and I've got a green build to raise my confidence level: http://autobuilder.yoctoproject.org:8010/builders/nightly/builds/462 So now to address issue #2. The goal is to incorporate community feedback, so I'm looking to get ACKs or NAKs for these commits before they go into the main denzil branch. My proposal is to send denzil pull requests to the appropriate mailing lists, and Richard can merge them into the main repo denzil branches once they've received review by the community. My goal is to send these pull requests about once per week, once I've managed to get a green build out of the Yocto autobuilder for my contrib branch. What do folks think about this? Now's your opportunity to offer feedback and influence this process. Thanks! Scott Yocto 1.2.1 release maintainer -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Autobuilder] M1_w3 and 1.2.1 builds.
As the autobuilder has been getting a bit of exercise this week I wanted to let people know of some recent buildouts of interest to QA The weekly build for the milestone 1, week 3 of 1.3 will be available very shortly at : http://autobuilder.yoctoproject.org/pub/nightly/20120523-2 An issue with sanity testing of SSTATE_DIR has been noticed and Joshua Lock has already submitted a patch for it. A test build of 1.2.1 was built last night. It is available at: http://autobuilder.yoctoproject.org/pub/nightly/20120523-1 It was all green, with the exception of a known issue in the AB with grabbing poky-contrib git archives. It was built from: Repo: git://git.yoctoproject.org/poky-contrib Branch: sgarman/denzil-next -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Planned Autobuilder Downtime
All, I'll be upgrading the autobuilder servers on Friday afternoon, US west coast time and conducting a test build of master and edison over the weekend to verify that everything is working correctly. This will not effect downloads, however the autobuilders will not be available for builds for about 24 hours while final testing is completed. This upgrade is mostly configuration related and has been delayed for some time now due to autobuilder lockout periods. This upgrade will be fixing the following bugs: 2029 Add a core-image-rt DISTRO target 2028 Add a poky-tiny DISTRO target 1850 Add new nightly-misc target to test other combinations 2191 i686-x86_64 toolchain is copied to the incorrect sharing directory This upgrade also will allow for the autobuilder software to be more flexible. The code has been cleaned up a bit more and some new features added. One of the things I've wanted to add for a while now is the ability to due pure OE-Core builds. The basic support for that is in this upgrade. Also, this upgrade handles BSP builds more smoothly than before, allowing us to utilize multiple bsp providers (meta-ti, meta-intel, meta-fsl for example) in creating bblayers.conf. And finally, this will also bring the production autobuilder entirely in line with the git tree, something that has been planned for some time. As the config file is now entirely controlled via the autobuilder.conf file, it allows us to have a single generic yoctoABConfig.py. Lastly, I'll be updating credentials on the server. If you have build permission on the server and have not sent me updated credentials, please do so before Friday, as all prior credentials will be revoked Friday afternoon. Thanks, -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ANNOUNCEMENT] Cedar Trail with PowerVR for Edison 6.0.1
This should actually read as optional for compliance with the BSP Guide. I've already asked Scott to work on an explicit list of "required" vs "optional" items to conform with the guide to make this clearer. The Intel silicon guys do this for their BSPs for a variety of reasons. I wouldn't necessarily expect anyone else to do this. >From: yocto-boun...@yoctoproject.org [mailto:yocto- >boun...@yoctoproject.org] On Behalf Of Saxena, Rahul >Sent: Wednesday, May 23, 2012 1:47 PM >To: Wolfgang Denk; Flanagan, Elizabeth >Cc: yocto-annou...@yoctoproject.org; yocto@yoctoproject.org >Subject: Re: [yocto] [ANNOUNCEMENT] Cedar Trail with PowerVR for Edison >6.0.1 > >Please see section 1.4 of the bsp-guide >(http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html) >including the following text: > >" Note >Pre-compiled images are bundled with a time-limited kernel that runs for a >predetermined amount of time (10 days) before it forces the system to >reboot. This limitation is meant to discourage direct redistribution of the >image. You must eventually rebuild the image if you want to remove this >restriction." > > >Thanks >Rahul > > >-Original Message- >From: yocto-boun...@yoctoproject.org [mailto:yocto- >boun...@yoctoproject.org] On Behalf Of Wolfgang Denk >Sent: Tuesday, May 22, 2012 10:45 PM >To: Flanagan, Elizabeth >Cc: yocto-annou...@yoctoproject.org; yocto@yoctoproject.org >Subject: Re: [yocto] [ANNOUNCEMENT] Cedar Trail with PowerVR for Edison >6.0.1 > >Dear Elizabeth, > >In message mhwbxoiu9qxchawjkvtgvavsr1goyh_8t...@mail.gmail.com> you wrote: >> >> This release enables the BSP to use the latest available kernel >> patches for Intel's PowerVR graphics driver. The BSP image includes >> time limited kernel images for testing purposes. > >This is probaby a stupid question, so I apologize in advance: > >What is a time limited kernel image? > >Best regards, > >Wolfgang Denk > >-- >DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de >You have the capacity to learn from mistakes. You'll learn a lot today. >___ >yocto mailing list >yocto@yoctoproject.org >https://lists.yoctoproject.org/listinfo/yocto >___ >yocto mailing list >yocto@yoctoproject.org >https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
