I had the same issue on 64-bit fedora R15. This patch fixed it for me:
http://patchwork.openembedded.org/patch/8233/
- Jani Uusi-Rantala
From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on behalf
of ext Andre Haupt
Scott / Bruce,
On 12 Aug 2011, at 00:57, Scott Garman wrote:
cp: cannot stat
`/home/chris/yocto/yocto-versions/laverne-4.0.1/meta/recipes-kernel/
linux/files/defconfig':
No such file or directory
It looks like this is where the file is expected.
I believe also
On Fri, Aug 12, 2011 at 08:32:17AM +, jani.uusi-rant...@nokia.com wrote:
I had the same issue on 64-bit fedora R15. This patch fixed it for me:
http://patchwork.openembedded.org/patch/8233/
for bernard (with MACHINE ??= qemux86 and DISTRO ?= poky) glib-2.0_2.26.1.bb is
pulled in, so the
On 11-08-12 04:20 AM, Chris Tapp wrote:
Scott / Bruce,
On 12 Aug 2011, at 00:57, Scott Garman wrote:
cp: cannot stat
`/home/chris/yocto/yocto-versions/laverne-4.0.1/meta/recipes-kernel/linux/files/defconfig':
No such file or directory
It looks like this is where the file is expected.
I
[rather than rebase, I've added this one to the series, here for review
as well]
As the all the BSPs use the same BSP branch and meta commit ID as the base
recipe, there is no need specify the KBRANCH and SRCREVs. Not doing so
greatly simplifies maintenance. Leaving the syntax in place, but
I have been surprised over the last few days at the number of packages
being built for the core-image-rt target, which for reference is as follows:
#
# Copyright (C) 2010 Intel Corporation.
#
DESCRIPTION = Real-Time Linux Image
DEPENDS = linux-yocto-rt
require
On Fri, 2011-08-12 at 09:27 -0700, Darren Hart wrote:
I have been surprised over the last few days at the number of packages
being built for the core-image-rt target, which for reference is as follows:
#
# Copyright (C) 2010 Intel Corporation.
#
DESCRIPTION = Real-Time Linux Image
From: Tom Zanussi tom.zanu...@intel.com
This patchset adds emgd 1.8 to yocto/emgd. Please pull into
linux-yocto-3.0/yocto/emgd.
Thanks,
Tom
The following changes are available in the git repository at:
git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git
tzanussi/emgd-linux-yocto-3.0
From: Tom Zanussi tom.zanu...@intel.com
The starting-point code that subsequent patches will modify. This is
a straight copy of the code in the emgd 1.8 emgd driver, specifically
IEMGD_HEAD_Linux/common/drm/emgd_drm.tgz from
Lin_EMGD_1_8_RC_2032.tgz, the 'Linux Tar Ball' release downloaded from
From: Tom Zanussi tom.zanu...@intel.com
Add emgd config option (DRM_EGD) and modify Makefiles for in-tree
builds.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
drivers/gpu/drm/Kconfig |9 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/emgd/Makefile | 40
From: Tom Zanussi tom.zanu...@intel.com
Fixes required for migration to Linux 3.0.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
.../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c |2 +-
.../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c |2 +-
From: Tom Zanussi tom.zanu...@intel.com
This enables hpet for crownbay.
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/crownbay-updates-linux-yocto-3.0
From: Tom Zanussi tom.zanu...@intel.com
The crownbay reference board has HPET hardware - enable it.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
From: Tom Zanussi tom.zanu...@intel.com
This patchset switches crownbay to the 3.0 kernel and upgrades emgd
to 1.8. Both crownbay and crownbay-emgd were successfully built and
boot tested.
One major change coming out of this patchset is that the emgd binary
bits no longer have to be downloaded
From: Tom Zanussi tom.zanu...@intel.com
Switch crownbay and crownbay-noemgd to the 3.0 kernel, lock it down,
and update kernel SRCREVs.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
meta-crownbay/conf/machine/crownbay-noemgd.conf|2 ++
meta-crownbay/conf/machine/crownbay.conf
From: Tom Zanussi tom.zanu...@intel.com
This adds a new recipe for the emgd 1.8 driver binaries.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
.../xorg-xserver/emgd-driver-bin_1.8.bb| 36
1 files changed, 36 insertions(+), 0 deletions(-)
create mode
From: Tom Zanussi tom.zanu...@intel.com
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
From: Tom Zanussi tom.zanu...@intel.com
Change preferred version of emgd binaries to 1.8.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
meta-crownbay/conf/machine/crownbay.conf |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
From: Tom Zanussi tom.zanu...@intel.com
Update to the ced-generated xorg.conf for 1.8.
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
.../xserver-xf86-config/crownbay/xorg.conf |3 ++-
.../xorg-xserver/xserver-xf86-config_0.1.bbappend |1 +
2 files changed, 3
I have created a community statistics wiki page at
https://wiki.yoctoproject.org/wiki/Community_Statistics. All feedback is
welcome.
thanks,
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
What is the best way to configure a layer to support multiple targets
that share a common base?
For example, a set of targets that use the Vortex86DX SOC share common
peripherals and also have per-variant peripherals.
I was thinking:
1) Have a conf/machine file for each variant;
2) Make
On 2011-08-12 16:31, Chris Tapp wrote:
What is the best way to configure a layer to support multiple targets that
share a common base?
For example, a set of targets that use the Vortex86DX SOC share common
peripherals and also have per-variant peripherals.
I was thinking:
1) Have a
On 11-08-12 06:31 PM, Chris Tapp wrote:
What is the best way to configure a layer to support multiple targets
that share a common base?
For example, a set of targets that use the Vortex86DX SOC share common
peripherals and also have per-variant peripherals.
I was thinking:
1) Have a
23 matches
Mail list logo
