Re: [meta-intel] New valleyisland support
Hi, Okay, here is a little background and some new issues I've encountered. We have been using Yocto 1.5.1 earlier to create image for our HWs. Now the new HW uses E38xx so I started testing the new Yocto/meta-intel - branches to get (better) support for it. Since the current ValleyIsland support for meta-intel was for Dylan - branch of Yocto and also because I wasn't able to create image with working Intel HD Graphics driver I started looking for newer versions. Graphics worked with VESA-driver, but not with actual Intel HD Graphics driver. Also the kernel was quite old being 3.8.13. I did some digging and noticed that dvhart/bsp-ng had support for the intel-corei7 so that's why I ended up there. I never intended to use it other than testing if I can create working image that has working Intel HD Graphics for Valleyisland. Then I tried latest poky/meta-intel combination since dvhart/bsp-ng was merged there. When trying to create core-image-sato using the intel-corei7-64 bsp I ended up with this: ERROR: Fetcher failure: Unable to find revision 29594404d7fe73cd80eaa4ee8c43dcc53970c60e in branch meta even from upstream ERROR: Function failed: Fetcher failure for URL: 'git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch=standard/base,meta;name=machine,meta'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /opt/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-dev/3.14++gitAUTOINC+29594404d7_29594404d7-r0/temp/log.do_fetch.25380 ERROR: Task 73 (/opt/poky/../poky/meta/recipes-kernel/linux/linux-yocto-dev.bb, do_fetch) failed with exit code '1' I'm not sure if that is a Yocto - bug, Meta-intel bug or my bug. Good to hear that linut-rt - support was not dropped, but merely just changed. Btw. Is it intentional that in intel-corei7-64.conf the PREFERRED_PROVIDER_virtual/kernel is set using = and not ?= which makes it impossible to override it from later scripts? Or am I doing something wrong again? I had to comment out that line to be able to use my own kernel version on later tests. Teemu Keskinarkaus Software system engineer maximatecc - Humans in control -Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: 12. maaliskuuta 2014 17:01 To: Keskinarkaus, Teemu; Meta Intel Cc: rebecca.swee.fun.chang; boon.leong.ong Subject: Re: [meta-intel] New valleyisland support Hi Teemu, Can you explain how you arrived at using the dvhart/bsp-ng branch? This is a development/testing branch, certainly not something meant for productization use. We're merging bits of bsp-ng into master as it's tested, verified, and fixed up. Valleyisland support specifically is available in Dylan under meta-isg/meta- valleyisland. Rebecca and her team are working on adding it to Dora with a 3.10 kernel I believe, but I'll leave it to her to comment on that. If you are just looking for Baytrail SoC support (not specifically valleyisland) then that is now available in meta-intel/master using the intel-corei7-64 BSP. This is a new approach to Intel BSPs which supports multiple boards/CPUs with a single BSP. As to linux-yocto-rt, we have not removed support for it. If you are referring to the removal of the linux-yocto-rt*bbappend files in dvhart/bsp-ng, that is done in favor of a new mechanism called the intel-common kernel, which uses a single kernel build across multiple BSPs, removing the need for the bbappend in each BSP layer - you'll note it is still present under common/recipes-kernel/linux. If you can provide some more context about what you are trying to do, we should be able to help make sure you are working with the right sources, and prioritize any development to fill any gaps. Thanks, Darren On 3/10/14, 21:45, Keskinarkaus, Teemu teemu.keskinark...@maximatecc.com wrote: Hi, I'm bit lost here. I'm looking for support for valleyisland that is for Dora branch of the Yocto. I cloned the dvhart/bsp-ng, but couldn't find any references to valleyisland or bay trail from there so I'm guessing I'm looking from the wrong place. Is there a right place? Or is the support 'coming soon' for Dora? I'm also bit disappointed to see that you chose to drop linux-rt support in favor of non-rt-linux. Mostly because I'm using the linux-rt variant. ;) So now I need to add it back there myself. Teemu Keskinarkaus Software system engineer maximatecc - Humans in control Actuant Corporation Email Notice This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email
[meta-intel] [PATCH 1/1] valleyisland: linux-yocto-3.8: update meta SRCREV
From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com This enables linux-yocto-3.8 to pick-up new valleyisland-io updated by meta branch commit: valleyisland-io: mmc: sdhci: fix continuous warning prints in ISR Signed-off-by: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com --- .../recipes-kernel/linux/linux-yocto_3.8.bbappend |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.8.bbappend b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.8.bbappend index 31309ce..54f66cb 100644 --- a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.8.bbappend +++ b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.8.bbappend @@ -14,7 +14,7 @@ KERNEL_FEATURES_valleyisland-32 = features/valleyisland-io/valleyisland-io \ LINUX_VERSION_valleyisland-32 = 3.8.13 SRCREV_machine_valleyisland-32 ?= 6f3e338aa9496cf68ad03a98f66c2e98975829c7 -SRCREV_meta_valleyisland-32 ?= 14441275c1195a1bd52a6455ecde006c4722d45f +SRCREV_meta_valleyisland-32 ?= 4134410f6467a55ea735c46feefc649ef643650a # # MACHINE = valleyisland-64 # @@ -28,6 +28,6 @@ KERNEL_FEATURES_valleyisland-64 = features/valleyisland-io/valleyisland-io \ LINUX_VERSION_valleyisland-64 = 3.8.13 SRCREV_machine_valleyisland-64 ?= 6f3e338aa9496cf68ad03a98f66c2e98975829c7 -SRCREV_meta_valleyisland-64 ?= 14441275c1195a1bd52a6455ecde006c4722d45f +SRCREV_meta_valleyisland-64 ?= 4134410f6467a55ea735c46feefc649ef643650a module_autoload_i2c-dev = i2c-dev -- 1.7.10.4 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] Not able to install 64bit Qt creator in 64bit yocto image
Hi, We are using poky Dylan version of yocto project. We are not able to install 64 bit Qt creator in the 64 bit yocto image. When we try to install we are getting error as no such file or directory found Our Hardware is Intel baytrail platform. And we have changed MACHINE as byatrail64 in local.conf. Do we need to change any configuration yocto ? Regards, Somasekhar ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] New valleyisland support
On Thu, 2014-03-13 at 06:40 +, Keskinarkaus, Teemu wrote:
Hi,
Okay, here is a little background and some new issues I've encountered.
We have been using Yocto 1.5.1 earlier to create image for our HWs. Now the
new HW uses E38xx so I started testing the new Yocto/meta-intel - branches to
get (better) support for it.
Since the current ValleyIsland support for meta-intel was for Dylan - branch
of Yocto and also because I wasn't able to create image with working Intel HD
Graphics driver I started looking for newer versions. Graphics worked with
VESA-driver, but not with actual Intel HD Graphics driver. Also the kernel
was quite old being 3.8.13.
I did some digging and noticed that dvhart/bsp-ng had support for the
intel-corei7 so that's why I ended up there. I never intended to use it other
than testing if I can create working image that has working Intel HD Graphics
for Valleyisland. Then I tried latest poky/meta-intel combination since
dvhart/bsp-ng was merged there.
When trying to create core-image-sato using the intel-corei7-64 bsp I ended
up with this:
ERROR: Fetcher failure: Unable to find revision
29594404d7fe73cd80eaa4ee8c43dcc53970c60e in branch meta even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch=standard/base,meta;name=machine,meta'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/opt/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-dev/3.14++gitAUTOINC+29594404d7_29594404d7-r0/temp/log.do_fetch.25380
ERROR: Task 73
(/opt/poky/../poky/meta/recipes-kernel/linux/linux-yocto-dev.bb, do_fetch)
failed with exit code '1'
I'm not sure if that is a Yocto - bug, Meta-intel bug or my bug.
I ran into this too and got around it by the hack below. Not sure why
it's not working, how it's actually supposed to work or if there's
something we need to be doing in meta-intel layers, adding Bruce..
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-
index 5e09720..917714d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -28,8 +28,8 @@ SRC_URI =
git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch
# linux-yocto-dev is the preferred provider, they will be overridden to
# AUTOREV in following anonymous python routine and resolved when the
# variables are finalized.
-SRCREV_machine ?= 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
-SRCREV_meta ?= 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
+SRCREV_machine ?= ${AUTOREV}
+SRCREV_meta ?= ${AUTOREV}
python () {
if d.getVar(PREFERRED_PROVIDER_virtual/kernel, True) !=
linux-yocto-dev:
Good to hear that linut-rt - support was not dropped, but merely just changed.
Btw. Is it intentional that in intel-corei7-64.conf the
PREFERRED_PROVIDER_virtual/kernel is set using = and not ?= which makes it
impossible to override it from later scripts? Or am I doing something wrong
again? I had to comment out that line to be able to use my own kernel version
on later tests.
Teemu Keskinarkaus
Software system engineer
maximatecc - Humans in control
-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: 12. maaliskuuta 2014 17:01
To: Keskinarkaus, Teemu; Meta Intel
Cc: rebecca.swee.fun.chang; boon.leong.ong
Subject: Re: [meta-intel] New valleyisland support
Hi Teemu,
Can you explain how you arrived at using the dvhart/bsp-ng branch? This is a
development/testing branch, certainly not something meant for productization
use. We're merging bits of bsp-ng into master as it's tested, verified, and
fixed
up.
Valleyisland support specifically is available in Dylan under meta-isg/meta-
valleyisland. Rebecca and her team are working on adding it to Dora with a
3.10
kernel I believe, but I'll leave it to her to comment on that.
If you are just looking for Baytrail SoC support (not specifically
valleyisland) then that is now available in meta-intel/master using the
intel-corei7-64 BSP. This is a new approach to Intel BSPs which supports
multiple
boards/CPUs with a single BSP.
As to linux-yocto-rt, we have not removed support for it. If you are
referring to
the removal of the linux-yocto-rt*bbappend files in dvhart/bsp-ng, that is
done in
favor of a new mechanism called the intel-common kernel, which uses a single
kernel build across multiple BSPs, removing the need for the bbappend in
each
BSP layer - you'll note it is still present under
common/recipes-kernel/linux.
If you can provide some more context about what you are trying to do, we
should
be able to help make sure you are working with the right sources, and
prioritize
any development to fill any gaps.
Thanks,
Darren
On 3/10/14, 21:45, Keskinarkaus, Teemu
teemu.keskinark...@maximatecc.com
Re: [meta-intel] New valleyisland support
On 14-03-13 09:43 AM, Tom Zanussi wrote:
On Thu, 2014-03-13 at 06:40 +, Keskinarkaus, Teemu wrote:
Hi,
Okay, here is a little background and some new issues I've encountered.
We have been using Yocto 1.5.1 earlier to create image for our HWs. Now the new
HW uses E38xx so I started testing the new Yocto/meta-intel - branches to get
(better) support for it.
Since the current ValleyIsland support for meta-intel was for Dylan - branch of
Yocto and also because I wasn't able to create image with working Intel HD
Graphics driver I started looking for newer versions. Graphics worked with
VESA-driver, but not with actual Intel HD Graphics driver. Also the kernel was
quite old being 3.8.13.
I did some digging and noticed that dvhart/bsp-ng had support for the
intel-corei7 so that's why I ended up there. I never intended to use it other
than testing if I can create working image that has working Intel HD Graphics
for Valleyisland. Then I tried latest poky/meta-intel combination since
dvhart/bsp-ng was merged there.
When trying to create core-image-sato using the intel-corei7-64 bsp I ended up
with this:
ERROR: Fetcher failure: Unable to find revision
29594404d7fe73cd80eaa4ee8c43dcc53970c60e in branch meta even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch=standard/base,meta;name=machine,meta'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/opt/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-dev/3.14++gitAUTOINC+29594404d7_29594404d7-r0/temp/log.do_fetch.25380
ERROR: Task 73 (/opt/poky/../poky/meta/recipes-kernel/linux/linux-yocto-dev.bb,
do_fetch) failed with exit code '1'
I'm not sure if that is a Yocto - bug, Meta-intel bug or my bug.
I ran into this too and got around it by the hack below. Not sure why
it's not working, how it's actually supposed to work or if there's
something we need to be doing in meta-intel layers, adding Bruce..
ok, this is report #2 of this. I'm firing up some tests here to see
if I can reproduce it.
You shouldn't need your mod to make it work .. so I'll dig out what
is happening.
Bruce
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-
index 5e09720..917714d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -28,8 +28,8 @@ SRC_URI =
git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch
# linux-yocto-dev is the preferred provider, they will be overridden to
# AUTOREV in following anonymous python routine and resolved when the
# variables are finalized.
-SRCREV_machine ?= 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
-SRCREV_meta ?= 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
+SRCREV_machine ?= ${AUTOREV}
+SRCREV_meta ?= ${AUTOREV}
python () {
if d.getVar(PREFERRED_PROVIDER_virtual/kernel, True) !=
linux-yocto-dev:
Good to hear that linut-rt - support was not dropped, but merely just changed.
Btw. Is it intentional that in intel-corei7-64.conf the
PREFERRED_PROVIDER_virtual/kernel is set using = and not ?= which makes it
impossible to override it from later scripts? Or am I doing something wrong
again? I had to comment out that line to be able to use my own kernel version
on later tests.
Teemu Keskinarkaus
Software system engineer
maximatecc - Humans in control
-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: 12. maaliskuuta 2014 17:01
To: Keskinarkaus, Teemu; Meta Intel
Cc: rebecca.swee.fun.chang; boon.leong.ong
Subject: Re: [meta-intel] New valleyisland support
Hi Teemu,
Can you explain how you arrived at using the dvhart/bsp-ng branch? This is a
development/testing branch, certainly not something meant for productization
use. We're merging bits of bsp-ng into master as it's tested, verified, and
fixed
up.
Valleyisland support specifically is available in Dylan under meta-isg/meta-
valleyisland. Rebecca and her team are working on adding it to Dora with a 3.10
kernel I believe, but I'll leave it to her to comment on that.
If you are just looking for Baytrail SoC support (not specifically
valleyisland) then that is now available in meta-intel/master using the
intel-corei7-64 BSP. This is a new approach to Intel BSPs which supports
multiple
boards/CPUs with a single BSP.
As to linux-yocto-rt, we have not removed support for it. If you are referring
to
the removal of the linux-yocto-rt*bbappend files in dvhart/bsp-ng, that is done
in
favor of a new mechanism called the intel-common kernel, which uses a single
kernel build across multiple BSPs, removing the need for the bbappend in each
BSP layer - you'll note it is still present under common/recipes-kernel/linux.
If you can provide some more context about what you are trying to do, we should
be able to help make sure you are working with the right sources, and prioritize
any development to fill any
Re: [meta-intel] [PATCH] common/recipes-bsp: remove gnu-efi and gummiboot recipes
On Wed, 2014-03-12 at 13:53 +0200, Stefan Stanacar wrote:
Nothing in meta-intel requires these and now
they are in OE-core anyway.
Pulled into meta-intel/master.
Thanks,
Tom
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
.../gnu-efi/gnu-efi/parallel-make-archives.patch | 48
--
.../gnu-efi/gnu-efi/parallel-make.patch| 22 --
common/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb | 35
common/recipes-bsp/gummiboot/gummiboot_git.bb | 26
4 files changed, 131 deletions(-)
delete mode 100644
common/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch
delete mode 100644 common/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch
delete mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb
delete mode 100644 common/recipes-bsp/gummiboot/gummiboot_git.bb
diff --git a/common/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch
b/common/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch
deleted file mode 100644
index e5b47c1..000
--- a/common/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-Fix parallel make failure for archives
-
-Upstream-Status: Pending
-
-The lib and gnuefi makefiles were using the lib.a() form which compiles
-and ar's as a pair instead of compiling all and then ar'ing which can
-parallelize better. This was resulting in build failures on larger values
-of -j.
-
-See http://www.chemie.fu-berlin.de/chemnet/use/info/make/make_toc.html#TOC105
-for details.
-
-Signed-off-by: Saul Wold s...@linux.intel.com
-Signed-off-by: Darren Hart dvh...@linux.intel.com
- gnuefi/Makefile |3 ++-
- lib/Makefile|3 ++-
- 2 files changed, 4 insertions(+), 2 deletions(-)
-
-Index: gnu-efi-3.0/lib/Makefile
-===
gnu-efi-3.0.orig/lib/Makefile
-+++ gnu-efi-3.0/lib/Makefile
-@@ -66,7 +66,8 @@ all: libsubdirs libefi.a
- libsubdirs:
- for sdir in $(SUBDIRS); do mkdir -p $$sdir; done
-
--libefi.a: $(patsubst %,libefi.a(%),$(OBJS))
-+libefi.a: $(OBJS)
-+$(AR) rv $@ $(OBJS)
-
- clean:
- rm -f libefi.a *~ $(OBJS) */*.o
-Index: gnu-efi-3.0/gnuefi/Makefile
-===
gnu-efi-3.0.orig/gnuefi/Makefile
-+++ gnu-efi-3.0/gnuefi/Makefile
-@@ -51,7 +51,8 @@ TARGETS= crt0-efi-$(ARCH).o libgnuefi.a
-
- all:$(TARGETS)
-
--libgnuefi.a: $(patsubst %,libgnuefi.a(%),$(OBJS))
-+libgnuefi.a: $(OBJS)
-+$(AR) rv $@ $(OBJS)
-
- clean:
- rm -f $(TARGETS) *~ *.o $(OBJS)
diff --git a/common/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch
b/common/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch
deleted file mode 100644
index 27c94e8..000
--- a/common/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-Fix parallel make failure
-
-Upstream-Status: Submitted [Maintainer directly]
-
-Add a missing dependency which resulted in a race leading to failure
-on larger values of -j.
-
-Signed-off-by: Darren Hart dvh...@linux.intel.com
-
-Index: gnu-efi-3.0/Makefile
-===
gnu-efi-3.0.orig/Makefile
-+++ gnu-efi-3.0/Makefile
-@@ -42,6 +42,8 @@ include $(SRCDIR)/Make.defaults
-
- SUBDIRS = lib gnuefi inc apps
-
-+gnuefi: lib
-+
- all:check_gcc $(SUBDIRS)
-
- $(SUBDIRS):
diff --git a/common/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb
b/common/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb
deleted file mode 100644
index 505c488..000
--- a/common/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb
+++ /dev/null
@@ -1,35 +0,0 @@
-SUMMARY = Libraries for producing EFI binaries
-HOMEPAGE = http://sourceforge.net/projects/gnu-efi/;
-SECTION = devel
-LICENSE = GPLv2+
-LIC_FILES_CHKSUM =
file://debian/copyright;md5=5fb358a180f484b285b0d99acdc29666
-
-PR = r0
-
-SRC_URI = http://downloads.sourceforge.net/gnu-efi/gnu-efi_3.0u.orig.tar.gz
\
- file://parallel-make.patch \
- file://parallel-make-archives.patch \
-
-SRC_URI[md5sum] = d15d3c700e79a1e2938544d73edc572d
-SRC_URI[sha256sum] =
3c0d450d5829204ca05dcb3b2aae772e52c379b7c7e09146759c6315606f934e
-
-COMPATIBLE_HOST = (x86_64.*|i.86.*)-linux
-
-S = ${WORKDIR}/gnu-efi-3.0
-
-def gnu_efi_arch(d):
-import re
-tarch = d.getVar(TARGET_ARCH, True)
-if re.match(i[3456789]86, tarch):
-return ia32
-return tarch
-
-EXTRA_OEMAKE = 'ARCH=${@gnu_efi_arch(d)}' 'CC=${CC}' 'AS=${AS}' 'LD=${LD}'
'AR=${AR}' \
-'RANLIB=${RANLIB}' 'OBJCOPY=${OBJCOPY}' 'PREFIX=${prefix}'\
-
-
-do_install() {
- oe_runmake install INSTALLROOT=${D}
-}
-
-FILES_${PN} += ${libdir}/*.lds
diff --git a/common/recipes-bsp/gummiboot/gummiboot_git.bb
b/common/recipes-bsp/gummiboot/gummiboot_git.bb
deleted file mode
Re: [meta-intel] [PATCH 0/1] [PATCH] valleyisland: update linux-yocto 3.8 meta branch SRCREV
On Thu, 2014-03-13 at 23:31 +0800, rebecca.swee.fun.ch...@intel.com wrote: From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Hi all, This is a SRCREV update for Valley Island BSP to take the latest commit ID refreshed in linux-yocto-3.8 meta branch. Please pull this patch into meta-intel Dylan branch. Pulled into meta-intel/dylan. Thanks, Tom Thank you. Rebecca The following changes since commit 4e38b3bc8616950e2b8b67ef134fb6d0439edd37: mohonpeak: linux-yocto-3.4: up-rev to v3.4.82 (2014-03-10 19:47:00 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib rebeccas/valleyisland-update-rev http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=rebeccas/valleyisland-update-rev Chang Rebecca Swee Fun (1): valleyisland: linux-yocto-3.8: update meta SRCREV .../recipes-kernel/linux/linux-yocto_3.8.bbappend |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.7.10.4 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] BSP retirements from meta-intel layer
Following on from the chiefriver BSP retirement thread, what is the general policy for BSP life-cycles within meta-intel? For example, we committed to using the Cedartrail BSP a couple of years back as if offered support for what was then a new platform with a reasonable forward buy-time. However, support for that has been dropped even though boards are still available using the chipset (e.g. ASRock DN2800MT) and these are going to be available for a few years yet. From our point of view it is a pity not to be able to make use of the improvements and enhancements that have gone into later Yocto versions, especially as we're continually updating our software. Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] BSP retirements from meta-intel layer
From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel- boun...@yoctoproject.org] On Behalf Of Chris Tapp Following on from the chiefriver BSP retirement thread, what is the general policy for BSP life-cycles within meta-intel? For example, we committed to using the Cedartrail BSP a couple of years back as if offered support for what was then a new platform with a reasonable forward buy-time. However, support for that has been dropped even though boards are still available using the chipset (e.g. ASRock DN2800MT) and these are going to be available for a few years yet. From our point of view it is a pity not to be able to make use of the improvements and enhancements that have gone into later Yocto versions, especially as we're continually updating our software. This interests me as well since we have been planning on using Yocto on our HW for a long time. We also noticed the drop of Cedartrail BSP and we ended up on porting it to newer Yocto ourselves which of course wasn't what we were hoping to get when switching to Yocto. Teemu Keskinarkaus Software system engineer maximatecc - Humans in control Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel Actuant Corporation Email Notice This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return mail and permanently delete the copy you received. Thank you. -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
