Re: [yocto] Configuring a layer to support multiple targets
On 13 Aug 2011, at 02:22, Bruce Ashfield wrote: What's your yocto release / base kernel ? IF you happen to be using linux-yocto there are several ways to avoid using defconfigs at all, and share your common base of kernel configuration items. Plan is to move to linux-yocto (currently using wrs). How do I configure it without using a defconfig? Also, is it possible to use a .config rather than a defconfig? I've got a lot of stuff turned off to reduce the size of the kernel, but a defconfig doesn't quite do. For example, if I have # CONFIG_USB_SERIAL is not set in a defconfig, then this gets in to the .config at build time. However, this doesn't disable any dependencies that are enabled in linux-wrs. This means that modules for the likes of the ftdi and pl2303 USB serial devices are still included in the kernel image. The use of a complete .config would stop this. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-qt3: qt3-x11-native compile fix on Fedora 15 x86-64
Hi all,
This patch fixes compilation of qt-x11-native_3.3.5 on Fedora 15 x86-64.
The compiler was complainig about unknown type ptrdiff_t. Including the
appropriate header in qvaluelist.h helps.
Can this be integrated into the meta-qt3 git repository?
cheers,
Andre
diff --git a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
index e64256f..526c42f 100644
--- a/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
+++ b/recipes-qt3/qt3/qt-x11-free-native_3.3.5.bb
@@ -4,7 +4,7 @@ PRIORITY = "optional"
LICENSE = "GPL | QPL"
DEPENDS = "xmu-native"
HOMEPAGE = "http://www.trolltech.com";
-PR = "r0"
+PR = "r1"
PROVIDES += "qt-x11-free-native"
FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/qt-x11-free"
@@ -13,7 +13,9 @@ LIC_FILES_CHKSUM =
"file://LICENSE.GPL;md5=629178675a7d49c9fa19dfe9f43ea256 \
file://LICENSE.QPL;md5=fff372435cb41647bc0b3cb940ea5c51"
SRC_URI = "ftp://ftp.trolltech.com/qt/source/qt-x11-free-${PV}.tar.bz2 \
- file://no-examples.patch"
+ file://no-examples.patch \
+ file://qt3-cstddef.patch"
+
S = "${WORKDIR}/qt-x11-free-${PV}"
#
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 11-08-17 03:59 AM, Chris Tapp wrote: On 13 Aug 2011, at 02:22, Bruce Ashfield wrote: What's your yocto release / base kernel ? IF you happen to be using linux-yocto there are several ways to avoid using defconfigs at all, and share your common base of kernel configuration items. Plan is to move to linux-yocto (currently using wrs). How do I configure it without using a defconfig? I depends on how you host your BSP, and the release. In yocto 1.1, there's new functionality that makes it easier to graft a BSP onto the tree without needing to have the BSP merged somewhere. But to configure and work without a defconfig, you simply need a BSP that branches from yocto/standard/base. Even the autogenerated descriptions in 1.0 will automatically include the standard kernel configs and settings and pass them to your BSP. Once this is in place, you simply need a config fragment (a .cfg file) for your board that adds/modifies the base configuration. Also, is it possible to use a .config rather than a defconfig? I've got a lot of stuff turned off to reduce the size of the kernel, but a defconfig doesn't quite do. For example, if I have # CONFIG_USB_SERIAL is not set in a defconfig, then this gets in to the .config at build time. However, this doesn't disable any dependencies that are enabled in linux-wrs. This means that modules for the likes of the ftdi and pl2303 USB serial devices are still included in the kernel image. The use of a complete .config would stop this. In this sense, the defconfig is simply a name to trigger specific processing. Just capture and call your .config 'defconfig' and you'll get a translation of those settings into the build. Bruce 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] linux-yocto: bitbake restarts with do_fetch after a -c configure
I was having some trouble doing some iterative kernel development and noticed that bitbake was restarting with do_fetch no matter what stage I had completed with the previous command. I thought it might be triggering on a source change, but just running the following without any other changes had the same result: $ bitbake linux-yocto -c configure ... $ bitbake linux-yocto $ bitbake linux-yocto Loading cache: 100% |##| ETA: 00:00:00 Loaded 1019 entries from dependency cache. Parsing recipes: 100% || Time: 00:00:01 Parsing of 790 .bb files complete (788 cached, 2 parsed). 1020 targets, 37 skipped, 0 masked, 0 errors. OE Build Configuration: BB_VERSION= "1.13.3" TARGET_ARCH = "powerpc" TARGET_OS = "linux" MACHINE = "qemuppc" DISTRO= "poky" DISTRO_VERSION= "1.0+snapshot-20110817" TUNE_FEATURES = "m32 fpu-hard ppc603e" TARGET_FPU= "" meta meta-yocto= "master:288c947ee69131cc29e9c367523cc71e4df56a76" meta-kernel-dev = "master:5193f2986c82d4c9a3b5e3cffb96877406664151" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Running task 484 of 860 (ID: 6, /home/dvhart/source/poky.git/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb, do_fetch) This prevents any sort of iterative development as the unpack and subsequent steps undue any local changes to the source tree. This appears to be a regression. -- 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] bbappend - Where should my file be?
On Fri, 2011-08-12 at 20:48 +0100, Chris Tapp wrote: > On 12 Aug 2011, at 13:59, Bruce Ashfield wrote: > > >> NOTE: Unpacking > >> /home/chris/yocto/yocto-downloads/git_git.pokylinux.org.linux-2.6- > >> windriver.git.tar.gz > >> to > >> /home/chris/yocto/sjs-build/tmp/work/LX800-poky-linux/linux- > >> wrs > >> -2.6.34 > >> + > >> git0 > >> + > >> b67e060194a38c6331da1532bd06446087a42b3b_0 > >> +0431115c9d720fee5bb105f6a7411efb4f851d26-r12/ > >> > >> NOTE: Unpacking > >> /home/chris/yocto/meta-keylevel-sjs/recipes/linux/linux-wrs/ > >> defconfig to > >> /home/chris/yocto/sjs-build/tmp/work/LX800-poky-linux/linux- > >> wrs > >> -2.6.34 > >> + > >> git0 > >> + > >> b67e060194a38c6331da1532bd06446087a42b3b_0 > >> +0431115c9d720fee5bb105f6a7411efb4f851d26-r12/ > >> > > > > That does look right! > > What are the rules for naming layers? > > I renamed the root for my new layer from 'meta-ebox-3300' to 'meta- > ebox3300', updated this in bblayers.conf and now my defconf file is > found as I was expecting... > > It seems as if having - at the end stops things working. This sounds like a bug so I filed it here: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1379 Regards, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2][KERNEL] bsp/fri2: merge emgd branch
From: Tom Zanussi Add scc commands to merge the yocto/emgd branch into the fri2 BSP. Signed-off-by: Tom Zanussi --- meta/cfg/kernel-cache/bsp/fri2/fri2.scc |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc index 6ac0bfb..a87ce7e 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc @@ -1,5 +1,7 @@ kconf hardware fri2.cfg +git merge yocto/emgd + include features/eg20t/eg20t.scc include features/intel-e1/intel-e1.scc include features/dmaengine/dmaengine.scc -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2][KERNEL] bsp/fri2: use EMGD feature
From: Tom Zanussi Add kernel options needed for enabling EMGD. Signed-off-by: Tom Zanussi --- meta/cfg/kernel-cache/bsp/fri2/fri2.scc |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc index a87ce7e..2d30049 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc @@ -4,6 +4,7 @@ git merge yocto/emgd include features/eg20t/eg20t.scc include features/intel-e1/intel-e1.scc +include features/drm-emgd/drm-emgd.scc include features/dmaengine/dmaengine.scc include features/serial/8250.scc include features/ericsson-3g/f5521gw.scc -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2][KERNEL] meta-/fri2: add EMGD support
From: Tom Zanussi This patchset makes fri2 use emgd. Please pull into linux-yocto-3.0/meta. Thanks, Tom The following changes are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git tzanussi/meta-fri2-emgd-linux-yocto-3.0 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/meta-fri2-emgd-linux-yocto-3.0 Tom Zanussi (2): bsp/fri2: merge emgd branch bsp/fri2: use EMGD feature meta/cfg/kernel-cache/bsp/fri2/fri2.scc |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 01/12] meta-crownbay: switch to linux-yocto 3.0 kernel
From: Tom Zanussi
Switch crownbay and crownbay-noemgd to the 3.0 kernel, lock it down,
and update kernel SRCREVs.
Signed-off-by: Tom Zanussi
---
meta-crownbay/conf/machine/crownbay-noemgd.conf|2 ++
meta-crownbay/conf/machine/crownbay.conf |2 ++
.../recipes-kernel/linux/linux-yocto_3.0.bbappend | 15 +++
3 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf
b/meta-crownbay/conf/machine/crownbay-noemgd.conf
index 0219bd1..0a82b54 100644
--- a/meta-crownbay/conf/machine/crownbay-noemgd.conf
+++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf
@@ -12,6 +12,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2
ext3 x86 \
KERNEL_IMAGETYPE = "bzImage"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_linux-yocto = "3.0+git%"
+
PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index 323c8c1..b4ea4b4 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -12,6 +12,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2
ext3 x86 \
KERNEL_IMAGETYPE = "bzImage"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_linux-yocto = "3.0+git%"
+
PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
new file mode 100644
index 000..c9aef72
--- /dev/null
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -0,0 +1,15 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+COMPATIBLE_MACHINE_crownbay = "crownbay"
+KMACHINE_crownbay = "yocto/standard/crownbay"
+KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
+
+COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
+KMACHINE_crownbay-noemgd = "yocto/standard/crownbay"
+KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
+
+SRCREV_machine_pn-linux-yocto_crownbay ?=
"9a259cf4f6d404db2820642df755a295bbfb7fe7"
+SRCREV_meta_pn-linux-yocto_crownbay ?=
"fe8eac15e144a35a716cd32c9d2b296ecd5202ac"
+
+SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?=
"9a259cf4f6d404db2820642df755a295bbfb7fe7"
+SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?=
"fe8eac15e144a35a716cd32c9d2b296ecd5202ac"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 02/12] meta-crownbay: new recipe for emgd 1.8 driver binaries
From: Tom Zanussi
This adds a new recipe for the emgd 1.8 driver binaries.
Signed-off-by: Tom Zanussi
---
.../xorg-xserver/emgd-driver-bin_1.8.bb| 36
1 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
diff --git a/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
b/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
new file mode 100644
index 000..64578cc
--- /dev/null
+++ b/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
@@ -0,0 +1,36 @@
+SUMMARY = "EMGD 1.8 xserver binaries"
+DESCRIPTION = "EMGD 1.8 includes some userspace binaries that use non-free \
+licensing, which are now available via a non-click-through downloadable \
+tarball, and is what this recipe now uses. Since it is a non-free license, \
+this recipe is marked as 'commercial' and you need to add COMMERCIAL_LICENSE \
+= \"\" in order to enable it in a build."
+LICENSE = "Intel-binary-only"
+PR = "r0"
+
+EMGD_LICDIR = "IEMGD_HEAD_Linux/License"
+EMGD_RPMDIR = "IEMGD_HEAD_Linux/MeeGo1.2"
+
+LIC_FILES_CHKSUM =
"file://${WORKDIR}/${EMGD_LICDIR}/License.txt;md5=b54f01caaf8483b3cb60c0c40f2bf22d"
+
+SRC_URI = "http://edc.intel.com/App_Shared/Downloads/Lin_EMGD_1_8_RC_2032.tgz";
+
+FILES_${PN} += "${libdir}/dri ${libdir}/xorg/modules/drivers"
+FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug ${libdir}/dri/.debug"
+
+S = "${WORKDIR}/${EMGD_RPMDIR}"
+
+do_install () {
+rpm2cpio.sh ${S}/emgd-bin*.rpm | cpio -id
+
+install -d -m 0755${D}/${libdir}/dri
+install -d -m 0755${D}/${libdir}/xorg/modules/drivers
+install -m 0755 ${S}/usr/lib/*.so.* ${D}${libdir}/
+install -m 0755 ${S}/usr/lib/dri/*${D}${libdir}/dri/
+install -m 0755 ${S}/usr/lib/xorg/modules/drivers/*
${D}${libdir}/xorg/modules/drivers/
+
+ln -sf libEGl.so.1${D}${libdir}/libEGl.so
+ln -sf libGLES_CM.so.1${D}${libdir}/libGLES_CM.so
+ln -sf libGLESv2.so.2 ${D}${libdir}/libGLESv2.so
+}
+
+LEAD_SONAME = "libEGL.so"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 03/12] meta-crownbay: select emgd 1.8
From: Tom Zanussi Change preferred version of emgd binaries to 1.8. Signed-off-by: Tom Zanussi --- meta-crownbay/conf/machine/crownbay.conf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-crownbay/conf/machine/crownbay.conf b/meta-crownbay/conf/machine/crownbay.conf index b4ea4b4..28d2902 100644 --- a/meta-crownbay/conf/machine/crownbay.conf +++ b/meta-crownbay/conf/machine/crownbay.conf @@ -28,7 +28,7 @@ XSERVER ?= "xserver-xf86-dri-lite \ xf86-video-vesa" PREFERRED_VERSION_xserver-xf86-dri-lite ?= "1.9.3" -PREFERRED_VERSION_emgd-driver-bin ?= "1.6" +PREFERRED_VERSION_emgd-driver-bin ?= "1.8" SERIAL_CONSOLE = "115200 ttyS0" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 04/12] meta-crownbay: make the use of emgd-driver-bin COMMERCIAL
From: Tom Zanussi
The emgd-driver-bin recipe now automatically downloads and installs
EMGD using the new click-through-free tarball, but since the binaries
still fall under a non-free license, we need to prevent it from being
accidentally installed in an image.
We therefore make sure it's labeled in the crownbay layer with
'COMMERCIAL_LICENSE'. In order to build a crownbay image, the user
now needs to add a 'COMMERCIAL_LICENSE = ""' line to local.conf.
Signed-off-by: Tom Zanussi
---
meta-crownbay/conf/layer.conf |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta-crownbay/conf/layer.conf b/meta-crownbay/conf/layer.conf
index 9b71700..d4877d6 100644
--- a/meta-crownbay/conf/layer.conf
+++ b/meta-crownbay/conf/layer.conf
@@ -10,3 +10,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
BBFILE_COLLECTIONS += "crownbay"
BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
BBFILE_PRIORITY_crownbay = "6"
+
+COMMERCIAL_LICENSE += "emgd-driver-bin"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 05/12] meta-crownbay: xorg.conf changes
From: Tom Zanussi
Update to the ced-generated xorg.conf for 1.8.
Signed-off-by: Tom Zanussi
---
.../xserver-xf86-config/crownbay/xorg.conf |3 ++-
.../xorg-xserver/xserver-xf86-config_0.1.bbappend |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git
a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
index f78a538..fce58f8 100644
---
a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
+++
b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
@@ -26,11 +26,12 @@ Section "Device"
Option "ALL/1/General/PortOrder" "4"
Option "ALL/1/General/DisplayConfig" "1"
Option "ALL/1/General/DisplayDetect" "1"
+Option "ALL/1/General/TuningWA" "1"
Option "ALL/1/Port/4/General/name" "lvds"
Option "ALL/1/Port/4/General/EdidAvail" "3"
Option "ALL/1/Port/4/General/EdidNotAvail" "1"
Option "ALL/1/Port/4/General/Rotation" "0"
-Option "ALL/1/Port/4/General/Edid" "1"
+Option "ALL/1/Port/4/General/Edid" "0"
EndSection
Section "ServerLayout"
diff --git
a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
index 4b8d0e6..1461431 100644
---
a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+++
b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
@@ -1,3 +1,4 @@
THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
+PR := "${PR}.1"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 06/12] meta-crownbay: update README
From: Tom Zanussi With the new emgd-driver-bin recipe, the extensive instructions on how to manually download and set up EMGD for the build are no longer necessary. Those instructions have been replaced with the simpler set of instructions now needed to build crownbay with EMGD. Changes to reflect the new image names and a couple other minor cleanups are also included. Signed-off-by: Tom Zanussi --- meta-crownbay/README | 207 ++ 1 files changed, 42 insertions(+), 165 deletions(-) diff --git a/meta-crownbay/README b/meta-crownbay/README index 89056ed..c82f2c4 100644 --- a/meta-crownbay/README +++ b/meta-crownbay/README @@ -6,7 +6,7 @@ The Crown Bay platform consists of the Intel Atom Z6xx processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). It also supports the E6xx embedded on-chip graphics via the Intel -Embedded Media and Graphics Driver (EMGD) 1.6 Gold Driver. +Embedded Media and Graphics Driver (EMGD) 1.8 Driver. Table of Contents = @@ -33,14 +33,20 @@ bblayers.conf e.g.: The meta-crownbay layer contains support for two different machine configurations. These configurations are identical except for the fact that the one prefixed with 'crownbay' makes use of the -Intel-proprietary EMGD 1.6 graphics driver, while the one prefixed +Intel-proprietary EMGD 1.8 graphics driver, while the one prefixed with 'crownbay-noemgd' does not. -If you want to enable the layer that supports EMGD graphics add +If you want to enable the layer that supports EMGD graphics add the following to the local.conf file: MACHINE ?= "crownbay" +You also need to add the line: + + COMMERCIAL_LICENSE = "" + +to the local.conf file. + If you want to enable the layer that does not support EMGD graphics add the following to the local.conf file: @@ -48,8 +54,8 @@ add the following to the local.conf file: You should then be able to build a crownbay image as such: - $ source poky-init-build-env - $ bitbake poky-image-sato-live + $ source oe-init-build-env + $ bitbake core-image-sato At the end of a successful build, you should have a live image that you can boot from a USB flash drive (see instructions on how to do @@ -59,10 +65,11 @@ As an alternative to downloading the BSP tarball, you can also work directly from the meta-intel git repository. For each BSP in the 'meta-intel' repository, there are multiple branches, one corresponding to each major release starting with 'laverne' (0.90), in -addition to the latest code which tracks the current master. Instead -of extracting a BSP tarball at the top level of your yocto build tree, -you can equivalently check out the appropriate branch from the -meta-intel repository at the same location. +addition to the latest code which tracks the current master (note that +not all BSPs are present in every release). Instead of extracting +a BSP tarball at the top level of your yocto build tree, you can +equivalently check out the appropriate branch from the meta-intel +repository at the same location. II. Special notes for building the meta-crownbay BSP layer @@ -70,182 +77,52 @@ II. Special notes for building the meta-crownbay BSP layer The meta-crownbay layer makes use of the proprietary Intel EMGD userspace drivers when building the "crownbay" machine (but not when -building the "crownbay-noemgd" machine). If you got the BSP from the -'BSP Downloads' section of the Yocto website, the EMGD binaries needed -to perform the build will already be present in the BSP, located in -the recipes-graphics/xorg-xserver/emgd-driver-bin-1.6 directory, and -you can ignore the rest of this section. +building the "crownbay-noemgd" machine). -If you didn't get the BSP from the 'BSP Downloads' section of the -Yocto website, you have two choices: +As mentioned in Section I, you need to add the line: -- You can download a tarball containing an rpm that contains the - binaries and extract the binaries from that, and copy them to the - proper location in the meta-crownbay layer. + COMMERCIAL_LICENSE = "" -- You can download a Windows executable from the official EMGD - website, extract the binaries from it, and copy them to the proper - location in the meta-crownbay layer. +to the local.conf file in order for the build to succeed. -The following subsections describe each option in detail. +The crownbay BSP COMMERCIAL_LICENSE default setting causes the build +to fail in order to prevent users from inadvertently creating and +possibly distributing images containing packages with non-free +licenses. Clearing the COMMERCIAL_LICENSE variable as shown above +essentially tells the build system that you're OK with the fact that +packages with non-free licenses such as EMGD will be installed in the +image. +Once you've done a build, you can examine the EMGD license(s) in the +IEMGD_HEAD_Linux/License directory of the emgd-driver-bin work +directory of the buil
[yocto] [PATCH 00/12] meta-intel: EMGD 1.8 and 3.0 kernel upgrade, v2
From: Tom Zanussi This patchset switches crownbay to the 3.0 kernel and upgrades emgd to 1.8. Both crownbay and crownbay-noemgd were successfully built and boot tested into sato. It also does the same for fri2, after adding a new fri2 machine config and renaming the current one to fri2-noemgd. Both fri2 and fri2-noemgd were successfully built and boot tested into sato. One major change coming out of this patchset is that the emgd binary bits no longer have to be downloaded and extracted manually - the new emgd-driver-bin recipe takes care of that now. However, after these changes the crownbay and fri2 (but not the crownbay-noemgd and fri2-noemgd) recipes will not build successfully unless the user overrides COMMERCIAL_LICENSE as mentioned in the READMEs. Changes since v1: - added another README option for users to override COMMERCIAL_LICENSE - added support for EMGD to fri2 - moved the emgd-driver-bin to common The following changes since commit fa92a44396b16be74f0de10256b0d42e52cf0bb6: Tom Zanussi (1): meta-intel: update linux-yocto 3.0 kernel SRCREVs are available in the git repository at: git://git.yoctoproject.org/meta-intel.git tzanussi/emgd-1.8v2 http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/emgd-1.8v2 Tom Zanussi (12): meta-crownbay: switch to linux-yocto 3.0 kernel meta-crownbay: new recipe for emgd 1.8 driver binaries meta-crownbay: select emgd 1.8 meta-crownbay: make the use of emgd-driver-bin COMMERCIAL meta-crownbay: xorg.conf changes meta-crownbay: update README meta-fri2: add EMGD 1.8 capabilities to fri2 meta-intel: move emgd-driver-bin_1.8 to common meta-fri2: add common/recipes-graphics to BBFILES meta-fri2: make the use of emgd-driver-bin COMMERCIAL meta-fri2: update README meta-intel: crownbay/fri2 README update for COMMERCIAL_LICENSE .../xorg-xserver/emgd-driver-bin_1.8.bb| 36 meta-crownbay/README | 213 +--- meta-crownbay/conf/layer.conf |2 + meta-crownbay/conf/machine/crownbay-noemgd.conf|2 + meta-crownbay/conf/machine/crownbay.conf |4 +- .../xserver-xf86-config/crownbay/xorg.conf |3 +- .../xorg-xserver/xserver-xf86-config_0.1.bbappend |1 + .../recipes-kernel/linux/linux-yocto_3.0.bbappend | 15 ++ meta-fri2/README | 102 +- meta-fri2/conf/layer.conf |6 +- meta-fri2/conf/machine/fri2-noemgd.conf| 36 meta-fri2/conf/machine/fri2.conf |5 +- .../formfactor/formfactor/fri2-noemgd/machconfig |3 + .../recipes-core/tasks/task-core-tools.bbappend|1 + .../xserver-xf86-config/fri2-noemgd/xorg.conf | 26 +++ .../xserver-xf86-config/fri2/xorg.conf | 48 -- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |9 + 17 files changed, 320 insertions(+), 192 deletions(-) create mode 100644 common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend create mode 100644 meta-fri2/conf/machine/fri2-noemgd.conf create mode 100644 meta-fri2/recipes-bsp/formfactor/formfactor/fri2-noemgd/machconfig create mode 100644 meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2-noemgd/xorg.conf ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 09/12] meta-fri2: add common/recipes-graphics to BBFILES
From: Tom Zanussi
Add common/recipes-graphics so fri2 can pick up the EMGD bits in
emgd-driver-bin.
Signed-off-by: Tom Zanussi
---
meta-fri2/conf/layer.conf |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
index b30e776..261 100644
--- a/meta-fri2/conf/layer.conf
+++ b/meta-fri2/conf/layer.conf
@@ -3,7 +3,9 @@ BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a recipes directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
- ${LAYERDIR}/recipes-*/*/*.bbappend"
+ ${LAYERDIR}/recipes-*/*/*.bbappend \
+ ${LAYERDIR}/../common/recipes-graphics/*/*.bb \
+ ${LAYERDIR}/../common/recipes-graphics/*/*.bbappend"
BBFILE_COLLECTIONS += "fri2"
BBFILE_PATTERN_fri2 := "^${LAYERDIR}/"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 10/12] meta-fri2: make the use of emgd-driver-bin COMMERCIAL
From: Tom Zanussi
The emgd-driver-bin recipe now automatically downloads and installs
EMGD using the new click-through-free tarball, but since the binaries
still fall under a non-free license, we need to prevent it from being
accidentally installed in an image.
We therefore make sure it's labeled in the fri2 layer with
'COMMERCIAL_LICENSE'. In order to build an fri2 image, the user
now needs to add a 'COMMERCIAL_LICENSE = ""' line to local.conf.
Signed-off-by: Tom Zanussi
---
meta-fri2/conf/layer.conf |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
index 261..eb17336 100644
--- a/meta-fri2/conf/layer.conf
+++ b/meta-fri2/conf/layer.conf
@@ -10,3 +10,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
BBFILE_COLLECTIONS += "fri2"
BBFILE_PATTERN_fri2 := "^${LAYERDIR}/"
BBFILE_PRIORITY_fri2 = "6"
+
+COMMERCIAL_LICENSE += "emgd-driver-bin"
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 11/12] meta-fri2: update README
From: Tom Zanussi Update the meta-fri2 README to reflect the addtion of the EMGD capabilities and new machine. Changes were also made to reflect the new image names and a couple other minor cleanups. Signed-off-by: Tom Zanussi --- meta-fri2/README | 96 -- 1 files changed, 86 insertions(+), 10 deletions(-) diff --git a/meta-fri2/README b/meta-fri2/README index 7957a7f..e2e7bd0 100644 --- a/meta-fri2/README +++ b/meta-fri2/README @@ -2,12 +2,20 @@ This README file contains information on building the meta-fri2 BSP layer, and booting the images contained in the /binary directory. Please see the corresponding sections below for details. +The Fish River Island II platform consists of the Intel Atom Z6xx +processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek ++ Topcliff), along with a varied assortment of communications options +and various other machine-to-machine (m2m) capabilities. + +It also supports the E6xx embedded on-chip graphics via the Intel +Embedded Media and Graphics Driver (EMGD) 1.8 Driver. + Table of Contents = - I. Special notes on the meta-fri2 BSP layer - II. Building the meta-fri2 BSP layer + I. Building the meta-fri2 BSP layer + II. Special notes for building the meta-fri2 BSP layer III. Booting the images in /binary @@ -24,14 +32,32 @@ by adding the location of the meta-fri2 layer to bblayers.conf e.g.: yocto/meta-intel/meta-fri2 \ -To enable the fri2 layer, add the fri2 MACHINE to local.conf: +The meta-fri2 layer contains support for two different machine +configurations. These configurations are identical except for the fact +that the one prefixed with 'fri2' makes use of the Intel-proprietary +EMGD 1.8 graphics driver, while the one prefixed with 'fri2-noemgd' +does not. + +If you want to enable the layer that supports EMGD graphics add the +following to the local.conf file: MACHINE ?= "fri2" +You also need to add the line: + + COMMERCIAL_LICENSE = "" + +to the local.conf file. + +If you want to enable the layer that does not support EMGD graphics +add the following to the local.conf file: + + MACHINE ?= "fri2-noemgd" + You should then be able to build a fri2 image as such: - $ source poky-init-build-env - $ bitbake poky-image-sato-live + $ source oe-init-build-env + $ bitbake core-image-sato At the end of a successful build, you should have a live image that you can boot from a USB flash drive (see instructions on how to do @@ -41,10 +67,60 @@ As an alternative to downloading the BSP tarball, you can also work directly from the meta-intel git repository. For each BSP in the 'meta-intel' repository, there are multiple branches, one corresponding to each major release starting with 'laverne' (0.90), in -addition to the latest code which tracks the current master. Instead -of extracting a BSP tarball at the top level of your yocto build tree, -you can equivalently check out the appropriate branch from the -meta-intel repository at the same location. +addition to the latest code which tracks the current master (note that +not all BSPs are present in every release). Instead of extracting +a BSP tarball at the top level of your yocto build tree, you can +equivalently check out the appropriate branch from the meta-intel +repository at the same location. + + +II. Special notes for building the meta-fri2 BSP layer +== + +The meta-fri2 layer makes use of the proprietary Intel EMGD userspace +drivers when building the "fri2" machine (but not when building the +"fri2-noemgd" machine). + +As mentioned in Section I, you need to add the line: + + COMMERCIAL_LICENSE = "" + +to the local.conf file in order for the build to succeed. + +The fri2 BSP COMMERCIAL_LICENSE default setting causes the build to +fail in order to prevent users from inadvertently creating and +possibly distributing images containing packages with non-free +licenses. Clearing the COMMERCIAL_LICENSE variable as shown above +essentially tells the build system that you're OK with the fact that +packages with non-free licenses such as EMGD will be installed in the +image. + +Once you've done a build, you can examine the EMGD license(s) in the +IEMGD_HEAD_Linux/License directory of the emgd-driver-bin work +directory of the build. + +Alternatively, you can examine the licenses before building by +downloading the EMGD 1.8 Driver and looking at the licenses in the +downloaded tarball. + +Here is the current link to the URL from which it can be downloaded: + +http://edc.intel.com/Software/Downloads/EMGD/ + +In the Download Now tab, select: + +Intel® architecture-based product: Linux Tar Ball +Operating System: MeeGo* 1.2 IVI Linux* (kernel 2.6.37, X.server 1.9, Mesa 7.9) + +That will give you a large .tgz file: + +Lin_EMGD_1_8_RC_2032.tgz + +Extract the files in the tar file, which will in turn give you a +directory named IEMGD_HEAD_Linux. +
[yocto] [PATCH 07/12] meta-fri2: add EMGD 1.8 capabilities to fri2
From: Tom Zanussi This patch essentially adds a new EMGD-capable 'fri2' machine to meta-fri2. The current version with vesa graphics will become fri2-noemgd; fri2 will become the version with EMGD graphics. This patch does the fri2->fri2-noemgd renaming and adds the new files for fri2, and updates the necessary .bbappends to support both fri2 and fri2-noemgd. Signed-off-by: Tom Zanussi --- meta-fri2/conf/machine/fri2-noemgd.conf| 36 +++ meta-fri2/conf/machine/fri2.conf |5 ++- .../formfactor/formfactor/fri2-noemgd/machconfig |3 + .../recipes-core/tasks/task-core-tools.bbappend|1 + .../xserver-xf86-config/fri2-noemgd/xorg.conf | 26 +++ .../xserver-xf86-config/fri2/xorg.conf | 48 ++- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |9 7 files changed, 114 insertions(+), 14 deletions(-) create mode 100644 meta-fri2/conf/machine/fri2-noemgd.conf create mode 100644 meta-fri2/recipes-bsp/formfactor/formfactor/fri2-noemgd/machconfig create mode 100644 meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2-noemgd/xorg.conf diff --git a/meta-fri2/conf/machine/fri2-noemgd.conf b/meta-fri2/conf/machine/fri2-noemgd.conf new file mode 100644 index 000..fea43a2 --- /dev/null +++ b/meta-fri2/conf/machine/fri2-noemgd.conf @@ -0,0 +1,36 @@ +#@TYPE: Machine +#@NAME: fri2 + +#@DESCRIPTION: Machine configuration for Fish River Island II systems +# i.e. E660 + EG20T + +include conf/machine/include/tune-atom.inc + +MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ +acpi serial usbgadget wifi 3g" + +KERNEL_IMAGETYPE = "bzImage" + +PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" +PREFERRED_VERSION_linux-yocto ?= "3.0+git%" + +PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto" +PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim" +PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri" +PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite" +PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite" +XSERVER ?= "xserver-xf86-dri-lite \ + xf86-input-mouse \ + xf86-input-keyboard \ + xf86-input-evdev \ + xf86-input-synaptics \ + xf86-video-vesa" + +SERIAL_CONSOLE = "115200 ttyS0" + +MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts" + +IMAGE_FSTYPES ?= "ext3 cpio.gz live" + +GLIBC_ADDONS = "nptl" +GLIBC_EXTRA_OECONF = "--with-tls" diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf index fea43a2..97b6a2e 100644 --- a/meta-fri2/conf/machine/fri2.conf +++ b/meta-fri2/conf/machine/fri2.conf @@ -24,7 +24,10 @@ XSERVER ?= "xserver-xf86-dri-lite \ xf86-input-keyboard \ xf86-input-evdev \ xf86-input-synaptics \ - xf86-video-vesa" + emgd-driver-bin" + +PREFERRED_VERSION_xserver-xf86-dri-lite ?= "1.9.3" +PREFERRED_VERSION_emgd-driver-bin ?= "1.8" SERIAL_CONSOLE = "115200 ttyS0" diff --git a/meta-fri2/recipes-bsp/formfactor/formfactor/fri2-noemgd/machconfig b/meta-fri2/recipes-bsp/formfactor/formfactor/fri2-noemgd/machconfig new file mode 100644 index 000..ffce012 --- /dev/null +++ b/meta-fri2/recipes-bsp/formfactor/formfactor/fri2-noemgd/machconfig @@ -0,0 +1,3 @@ +# Assume a USB mouse and keyboard are connected +HAVE_TOUCHSCREEN=0 +HAVE_KEYBOARD=1 diff --git a/meta-fri2/recipes-core/tasks/task-core-tools.bbappend b/meta-fri2/recipes-core/tasks/task-core-tools.bbappend index 5accb2e..aa50c91 100644 --- a/meta-fri2/recipes-core/tasks/task-core-tools.bbappend +++ b/meta-fri2/recipes-core/tasks/task-core-tools.bbappend @@ -1,2 +1,3 @@ RRECOMMENDS_task-core-tools-profile_append_fri2 = " systemtap" +RRECOMMENDS_task-core-tools-profile_append_fri2-noemgd = " systemtap" diff --git a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2-noemgd/xorg.conf b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2-noemgd/xorg.conf new file mode 100644 index 000..da4fc3c --- /dev/null +++ b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2-noemgd/xorg.conf @@ -0,0 +1,26 @@ +Section "Device" +Identifier "Generic VESA" +Driver "vesa" +EndSection + +Section "Monitor" +Identifier"Generic Monitor" +Option"DPMS" +EndSection + +Section "Screen" +Identifier"Default Screen" +Device "Generic VESA" +Monitor "Generic Monitor" +DefaultDepth 24 +EndSection + +Section "ServerLayout" +Identifier "Default Layout" +Screen "Default Screen" +EndSection + +Section "ServerFlags" +Option"DontZap" "0" +Option"AutoAddDevices" "False" +EndSection diff --git a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf index da4fc3c..fce58f8 100644 --- a/meta-fri2/
[yocto] [PATCH 12/12] meta-intel: crownbay/fri2 README update for COMMERCIAL_LICENSE
From: Tom Zanussi Document an alternative mechanism for users to deal with COMMERCIAL_LICENSE in the crownbay and fri2 BSPs. Signed-off-by: Tom Zanussi --- meta-crownbay/README |6 ++ meta-fri2/README |6 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/meta-crownbay/README b/meta-crownbay/README index c82f2c4..c3d2520 100644 --- a/meta-crownbay/README +++ b/meta-crownbay/README @@ -85,6 +85,12 @@ As mentioned in Section I, you need to add the line: to the local.conf file in order for the build to succeed. +Alternatively, if clearing COMMERCIAL_LICENSE is not precise enough +for your needs, you can also simply comment out the following line in +meta-crownbay/conf/layer.conf to achieve the same result: + + COMMERCIAL_LICENSE += "emgd-driver-bin" + The crownbay BSP COMMERCIAL_LICENSE default setting causes the build to fail in order to prevent users from inadvertently creating and possibly distributing images containing packages with non-free diff --git a/meta-fri2/README b/meta-fri2/README index e2e7bd0..81ced36 100644 --- a/meta-fri2/README +++ b/meta-fri2/README @@ -87,6 +87,12 @@ As mentioned in Section I, you need to add the line: to the local.conf file in order for the build to succeed. +Alternatively, if clearing COMMERCIAL_LICENSE is not precise enough +for your needs, you can also simply comment out the following line in +meta-fri/conf/layer.conf to achieve the same result: + + COMMERCIAL_LICENSE += "emgd-driver-bin" + The fri2 BSP COMMERCIAL_LICENSE default setting causes the build to fail in order to prevent users from inadvertently creating and possibly distributing images containing packages with non-free -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 08/12] meta-intel: move emgd-driver-bin_1.8 to common
From: Tom Zanussi
emgd-driver-bin will be shared by multiple BSPs, crownbay and fri2 to
start with, so move them into /common.
Signed-off-by: Tom Zanussi
---
.../xorg-xserver/emgd-driver-bin_1.8.bb|0
1 files changed, 0 insertions(+), 0 deletions(-)
rename {meta-crownbay =>
common}/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb (100%)
diff --git a/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
similarity index 100%
rename from meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
rename to common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2][KERNEL] bsp/fri2: merge emgd branch
On 08/17/2011 09:50 AM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > Add scc commands to merge the yocto/emgd branch into the fri2 BSP. > > Signed-off-by: Tom Zanussi Acked-by: Darren Hart > --- > meta/cfg/kernel-cache/bsp/fri2/fri2.scc |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > index 6ac0bfb..a87ce7e 100644 > --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > @@ -1,5 +1,7 @@ > kconf hardware fri2.cfg > > +git merge yocto/emgd > + > include features/eg20t/eg20t.scc > include features/intel-e1/intel-e1.scc > include features/dmaengine/dmaengine.scc -- 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 2/2][KERNEL] bsp/fri2: use EMGD feature
On 08/17/2011 09:50 AM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > Add kernel options needed for enabling EMGD. > > Signed-off-by: Tom Zanussi Acked-by: Darren Hart > --- > meta/cfg/kernel-cache/bsp/fri2/fri2.scc |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > index a87ce7e..2d30049 100644 > --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc > @@ -4,6 +4,7 @@ git merge yocto/emgd > > include features/eg20t/eg20t.scc > include features/intel-e1/intel-e1.scc > +include features/drm-emgd/drm-emgd.scc > include features/dmaengine/dmaengine.scc > include features/serial/8250.scc > include features/ericsson-3g/f5521gw.scc -- 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 10/12] meta-fri2: make the use of emgd-driver-bin COMMERCIAL
On 08/17/2011 09:51 AM, tom.zanu...@intel.com wrote:
> From: Tom Zanussi
>
> The emgd-driver-bin recipe now automatically downloads and installs
> EMGD using the new click-through-free tarball, but since the binaries
> still fall under a non-free license, we need to prevent it from being
> accidentally installed in an image.
>
> We therefore make sure it's labeled in the fri2 layer with
> 'COMMERCIAL_LICENSE'. In order to build an fri2 image, the user
> now needs to add a 'COMMERCIAL_LICENSE = ""' line to local.conf.
>
> Signed-off-by: Tom Zanussi
> ---
> meta-fri2/conf/layer.conf |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
> index 261..eb17336 100644
> --- a/meta-fri2/conf/layer.conf
> +++ b/meta-fri2/conf/layer.conf
> @@ -10,3 +10,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
> BBFILE_COLLECTIONS += "fri2"
> BBFILE_PATTERN_fri2 := "^${LAYERDIR}/"
> BBFILE_PRIORITY_fri2 = "6"
> +
> +COMMERCIAL_LICENSE += "emgd-driver-bin"
Can't this be done in the common emgd driver recipe? Seems wrong to have
to specify commercial license for recipe in a machine config... A
different machine could just omit it and the user would not have to add
COMMERCIAL_LICENSE = "" to their local.conf and it would be fine?
--
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 0/2][KERNEL] meta-/fri2: add EMGD support
On 11-08-17 12:50 PM, tom.zanu...@intel.com wrote: From: Tom Zanussi This patchset makes fri2 use emgd. Please pull into linux-yocto-3.0/meta. I've tossed this onto the pile. Once some testing completes, I'll push this out with my 3.0.2 update. Bruce Thanks, Tom The following changes are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git tzanussi/meta-fri2-emgd-linux-yocto-3.0 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/meta-fri2-emgd-linux-yocto-3.0 Tom Zanussi (2): bsp/fri2: merge emgd branch bsp/fri2: use EMGD feature meta/cfg/kernel-cache/bsp/fri2/fri2.scc |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 17 Aug 2011, at 16:18, Bruce Ashfield wrote: In this sense, the defconfig is simply a name to trigger specific processing. Just capture and call your .config 'defconfig' and you'll get a translation of those settings into the build. That's what I've done. I used 'make xconfig' to modify the .config file (resulting from bitbake -c compile virtual/kernel). However, turning off CONFIG_USB_SERIAL and saving the result as a defconfig isn't quite what's needed. Consider the .config fragment: CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_FTDI_SIO=y The corresponding defconfig fragment produced when usb serial is disabled in xconfig results is simply: # CONFIG_USB_SERIAL is not set When the defconfig is merged with the .config I get: # CONFIG_USB_SERIAL is not set CONFIG_USB_SERIAL_FTDI_SIO=y This means the FTDI module is still present in the kernel. I can get rid of these by manually adding 'not set' entries in the defconfig, but it would be easier if I could replace the .config rather than patch it. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 11-08-17 03:07 PM, Chris Tapp wrote: On 17 Aug 2011, at 16:18, Bruce Ashfield wrote: In this sense, the defconfig is simply a name to trigger specific processing. Just capture and call your .config 'defconfig' and you'll get a translation of those settings into the build. That's what I've done. I used 'make xconfig' to modify the .config file (resulting from bitbake -c compile virtual/kernel). However, turning off CONFIG_USB_SERIAL and saving the result as a defconfig isn't quite what's needed. Consider the .config fragment: CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_FTDI_SIO=y The corresponding defconfig fragment produced when usb serial is disabled in xconfig results is simply: # CONFIG_USB_SERIAL is not set When the defconfig is merged with the .config I get: # CONFIG_USB_SERIAL is not set CONFIG_USB_SERIAL_FTDI_SIO=y This means the FTDI module is still present in the kernel. I can get rid of these by manually adding 'not set' entries in the defconfig, but it would be easier if I could replace the .config rather than patch it. The model is that you must explicitly chose values to modify them, otherwise, they flow through. Last through the gate wins. If you don't speak, others parts speak for the configuration. In this case, you must be inheriting the common-pc kernel configuration. It's something to configure for the future, but that is working as designed at the moment. The point is to be able to set a policy for options that inheriting BSPs must explicitly disable. The solutions two this are: - inherit from a base branch vs common-pc (assuming that I guessed right) - do the explicit disabling of already set options - convince us that the common-pc shouldn't be turning this on and trickle this option out to the leaf BSPs. Cheers, Bruce 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
Re: [yocto] [PATCH 10/12] meta-fri2: make the use of emgd-driver-bin COMMERCIAL
On Wed, 2011-08-17 at 10:25 -0700, Darren Hart wrote:
>
> On 08/17/2011 09:51 AM, tom.zanu...@intel.com wrote:
> > From: Tom Zanussi
> >
> > The emgd-driver-bin recipe now automatically downloads and installs
> > EMGD using the new click-through-free tarball, but since the binaries
> > still fall under a non-free license, we need to prevent it from being
> > accidentally installed in an image.
> >
> > We therefore make sure it's labeled in the fri2 layer with
> > 'COMMERCIAL_LICENSE'. In order to build an fri2 image, the user
> > now needs to add a 'COMMERCIAL_LICENSE = ""' line to local.conf.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> > meta-fri2/conf/layer.conf |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
> > index 261..eb17336 100644
> > --- a/meta-fri2/conf/layer.conf
> > +++ b/meta-fri2/conf/layer.conf
> > @@ -10,3 +10,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
> > BBFILE_COLLECTIONS += "fri2"
> > BBFILE_PATTERN_fri2 := "^${LAYERDIR}/"
> > BBFILE_PRIORITY_fri2 = "6"
> > +
> > +COMMERCIAL_LICENSE += "emgd-driver-bin"
>
> Can't this be done in the common emgd driver recipe? Seems wrong to have
> to specify commercial license for recipe in a machine config... A
> different machine could just omit it and the user would not have to add
> COMMERCIAL_LICENSE = "" to their local.conf and it would be fine?
>
>
I did try that first, but puting it in the layer.conf was the only thing
that worked. I think the same thing could be said for the other recipes
in the COMMERCIAL_LICENSE list in default-distrovars, as well as the
COMMERCIAL_LICENSE = "" override in local.conf, which is always the
answer on the list given whenever people try to use those recipes (none
of this is documented anywhere that I could find either. Now at least
it is for these layers.)
Tom
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 10/12] meta-fri2: make the use of emgd-driver-bin COMMERCIAL
On 08/17/2011 12:26 PM, Tom Zanussi wrote:
> On Wed, 2011-08-17 at 10:25 -0700, Darren Hart wrote:
>>
>> On 08/17/2011 09:51 AM, tom.zanu...@intel.com wrote:
>>> From: Tom Zanussi
>>>
>>> The emgd-driver-bin recipe now automatically downloads and installs
>>> EMGD using the new click-through-free tarball, but since the binaries
>>> still fall under a non-free license, we need to prevent it from being
>>> accidentally installed in an image.
>>>
>>> We therefore make sure it's labeled in the fri2 layer with
>>> 'COMMERCIAL_LICENSE'. In order to build an fri2 image, the user
>>> now needs to add a 'COMMERCIAL_LICENSE = ""' line to local.conf.
>>>
>>> Signed-off-by: Tom Zanussi
>>> ---
>>> meta-fri2/conf/layer.conf |2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
>>> index 261..eb17336 100644
>>> --- a/meta-fri2/conf/layer.conf
>>> +++ b/meta-fri2/conf/layer.conf
>>> @@ -10,3 +10,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
>>> BBFILE_COLLECTIONS += "fri2"
>>> BBFILE_PATTERN_fri2 := "^${LAYERDIR}/"
>>> BBFILE_PRIORITY_fri2 = "6"
>>> +
>>> +COMMERCIAL_LICENSE += "emgd-driver-bin"
>>
>> Can't this be done in the common emgd driver recipe? Seems wrong to have
>> to specify commercial license for recipe in a machine config... A
>> different machine could just omit it and the user would not have to add
>> COMMERCIAL_LICENSE = "" to their local.conf and it would be fine?
>>
>>
>
> I did try that first, but puting it in the layer.conf was the only thing
> that worked. I think the same thing could be said for the other recipes
> in the COMMERCIAL_LICENSE list in default-distrovars, as well as the
> COMMERCIAL_LICENSE = "" override in local.conf, which is always the
> answer on the list given whenever people try to use those recipes (none
> of this is documented anywhere that I could find either. Now at least
> it is for these layers.)
Alright, sounds like a bigger project to get it out of the layer.conf
and probably something we need to get into the documentation somewhere.
This series looks fine to me otherwise.
--
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] Configuring a layer to support multiple targets
On 17 Aug 2011, at 20:15, Bruce Ashfield wrote: The model is that you must explicitly chose values to modify them, otherwise, they flow through. Last through the gate wins. If you don't speak, others parts speak for the configuration. That's what I was trying to say ;-) In this case, you must be inheriting the common-pc kernel configuration. I am. The solutions two this are: ... - inherit from a base branch vs common-pc (assuming that I guessed right) Sounds like a plan. Where can I find a list of the branches in the 4.0.1 meta data? I'm using the following to select one at the moment: WRMACHINE_Vortex86DX = "common_pc" --- I'm guessing I need something else here. SRCREV_machine_pn-linux-wrs_Vortex86DX ?= "0431115c9d720fee5bb105f6a7411efb4f851d26" - convince us that the common-pc shouldn't be turning this on and trickle this option out to the leaf BSPs. No, it seems perfectly reasonable to have this in 'common-pc'. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 17 Aug 2011, at 21:24, Bruce Ashfield wrote: I have to head out for the day, but I'll loop around on this. Technically I'm out of the office for the next 2 days, but can sneak this in. I just need to double check a couple things in the 2.6.34 support to see if inheriting from 'standard' directly will work for you .. and if it won't, I can give you patch to carry locally for a bit. Thanks, but please don't speed too much time on it if 'standard' isn't going to work. This is only a research project at the moment and I can patch my defconf easily enough for now (especially as it seems I need to re-enable USB_SERIAL with USB_SERIAL_GENERIC to get the CM119 usb audio on the SoC to work, which means a defconf will now do what I want). It would be nice to have a proper (generic) solution going forward, but I plan to switch to linux-yocto-stable in the pending release. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] setting preferred provider for "virtual/libx11"?
with latest poky git pull, did "bitbake -c fetchall world" just for fun and got: NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue ERROR: Multiple .bb files are due to be built which each provide virtual/libx11 (/home/rpjday/yocto/poky.git/meta/recipes-graphics/xorg-lib/libx11-trim_1.3.4.bb /home/rpjday/yocto/poky.git/meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb). This usually means one provides something the other doesn't and should. NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 1359 tasks of which 1359 didn't need to be rerun and 0 failed. i'm *assuming* that, since both of those .bb files pull in libx11.inc, this is the offending line from that libx11.inc file: PROVIDES = "virtual/libx11" and that (as saul just explained to me before his linuxcon talk starts), what is needed is a PREFERRED_PROVIDER for this virtual package to distinguish between them, correct? i can see several directives throughout the tree: PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim" but, obviously(?), there's none being included in my specific example of doing a fetchall for world. feel free to explain why i have no idea what i'm talking about. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] linux-yocto 3.0.1 upgrade broke PREFERRED_VERSION setting in BSPs
We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like: NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel) I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out. -- 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] linux-yocto 3.0.1 upgrade broke PREFERRED_VERSION setting in BSPs
On 11-08-17 11:23 PM, Darren Hart wrote: We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like: NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel) I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out. I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load. I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto 3.0.1 upgrade broke PREFERRED_VERSION setting in BSPs
On 11-08-18 12:11 AM, Bruce Ashfield wrote: On 11-08-17 11:23 PM, Darren Hart wrote: We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like: NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel) I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out. I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load. I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it. Another thought on this is that we follow up on the discussion that we had when I first had to force some boards back to 2.6.37. We drop all the preferred version manipulations and control this via DEFAULT_PREFERENCE. I can just set DEFAULT_PREFERENCE = -1 in the linux-yocto_.bb file, and as machines are tested/validated, they'll just set the DEFAULT_PREFERENCE_$MACHINE in their recipe/bbappend file. That saves us all the PREFERRED version fun. Alternatively, we go back to just setting it to 3.0 and leaving it there and those folks that don't want to check the tags in the kernel I can put a comment in the recipe that lets them know the true version. Cheers, Bruce Cheers, Bruce ___ 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] linux-yocto 3.0.1 upgrade broke PREFERRED_VERSION setting in BSPs
On 08/17/2011 09:40 PM, Bruce Ashfield wrote: > On 11-08-18 12:11 AM, Bruce Ashfield wrote: >> On 11-08-17 11:23 PM, Darren Hart wrote: >>> We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail >>> with messages like: >>> >>> NOTE: preferred version 3.0+git% of linux-yocto not available (for item >>> virtual/kernel) >>> >>> I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was >>> just released and I'd have to do it again tomorrow. For 2.6.37, the and 3.0.3 is out... >>> LINUX_VERSION remained the same across point releases. I recommend we do >>> the same for 3.0. I really don't want to have to go through and update >>> all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a >>> point release comes out. >> >> I made this change due to some other explicit requests about the >> kernel version not being obvious. I don't really see this as a big >> deal, I'm already updating SRCREVs, we are already updating the >> SRCREVs in the meta-* layers .. so I fail to see how this is much >> more load. Don't forget the -rt variant, it is still at 3.0. >> I'd argue that 2.6.37 was a mistake, and you shouldn't even need >> to set the preferred version anymore once the latest kernel works >> for your machines. It will always be selected and you shouldn't >> need to force it. We only needed this during the transition phase, >> and I'm about to change the default in meta-yocto .. so you definitely >> won't need it. > > Another thought on this is that we follow up on the discussion that > we had when I first had to force some boards back to 2.6.37. We drop > all the preferred version manipulations and control this via > DEFAULT_PREFERENCE. > > I can just set DEFAULT_PREFERENCE = -1 in the linux-yocto_.bb > file, and as machines are tested/validated, they'll just set > the DEFAULT_PREFERENCE_$MACHINE in their recipe/bbappend file. That > saves us all the PREFERRED version fun. It makes a lot more sense to me to specify the kernel to use in the machine config and not allow whatever recipe claim DEFAULT_PREFERENCE for the machines. > > Alternatively, we go back to just setting it to 3.0 and leaving it > there and those folks that don't want to check the tags in the kernel > I can put a comment in the recipe that lets them know the true > version. It is a bit odd to have to specify a version that doesn't match the filename itself. But I guess we already have to do that in part with the "+git%" thing. What is the "%" by the way - is it a wildcard? If so, can we use a wildcard to include point releases? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
