Re: [meta-intel] [dizzy][PATCH 0/3] qat fixes for highland forest and crystal forest
On 7/23/15 9:38 AM, Anuj Mittal wrote: Dear Maintainer(s), The aim of this patch series is to allow switching between qat16 and qat15 packages for supported platforms on dizzy (highland forest supports qat16 and crystal forest supports qat15). Where is the highland forest PREFERRED_VERSION of 16 change going to be made? -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] bsps: update meta SRCREVs
On 2015-07-23 6:44 PM, Darren Hart wrote: On 7/23/15 3:38 PM, Bruce Ashfield wrote: On 2015-07-23 6:35 PM, Darren Hart wrote: Hrm, What does this apply against? You need the patches that I sent to oe-core that split the meta data from the kernel repository (see zedd/kernel in poky-contrib). The revs must exist in the yocto-kernel-cache repository. It's a chicken and egg situation. This broke under test when my series is applied, but can't merge until that series goes into oe-core. Thanks, somehow I had no idea this was happening. This will need to be updated in the kernel-dev manual. Does this also impact previous releases? fido, dizzy, dora, ... ? Nope. Only master. I'm not removing the meta branch from those trees, or updating the tools. This is only master, and the first tree with no meta branch is the 4.1 kernel tree. Existing branches, with their kernel trees, and tools continue to work as they were. Bruce -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [dizzy][PATCH 2/3] meta-crystalforest: add qat preferred provider
On 7/23/15, 4:31 PM, Ong, Boon Leong boon.leong@intel.com wrote: Your cover letter said crystal forest depends on qat15. Why are we setting it to qat16 here? Crystal-forest depends on qat15 Highland-forest depends on qat16 Qat16 is chosen as default because that is to support coleto creek which is newer chipset. Thanks for the context. These have now been merged to dizzy. -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [fido][PATCH 00/16] DPDK v1.8.0 v2.0.0 for CID platforms
On 7/9/15 4:49 PM, Ong, Boon Leong wrote: -Original Message- From: Saul Wold [mailto:s...@linux.intel.com] Sent: Thursday, July 9, 2015 11:54 PM To: Ong, Boon Leong Cc: meta-intel@yoctoproject.org; chia.chuah...@intel.com Subject: Re: [meta-intel][fido][PATCH 00/16] DPDK v1.8.0 v2.0.0 for CID platforms On 07/07/2015 04:20 PM, Ong Boon Leong wrote: Dear maintainers, Firstly, the patch add a layer for meta-isg just like dizzy branch. Then, the patchseries add the capabillity of DPDKv1.8.0 and DPDKv2.0.0 on meta-intel fido branch. It reuses DPDK ingredients from dizzy branch as base and further customizes dpdk.inc to handle several build change across DPDK v1.8.0 v2.0.0. Wu, Chia Chuan has contributed the enhancement for DPDK v2.0.0 and I have checked and signed-off his contributions. I have validated both versions are building fine and the ingredients under packages-split look healthy to my best knowledge. Chia Chuan has helped in testing the ingredients on CID platforms. Although it is a long series, but a lot of the commits are incrementally small for review. Hope that is fine with you. Appreciate your help and effort in reviewing this patchseries. If you find them good, please kindly help to merge them into fido branch. Something I realized would make things much better, can these patches and along with the QAT and zlib patches actually go into master and then be backported into fido? This will then keep master current and allow easier update/upgrade pathes for dpdk, qat and associated work. This is the get stuff in master upstream first and then backport? Would this be possible? Saul, ok. We will make sure that the patches are sent to be master then considered to be back-ported Into Fido. We were doing catch-up and with this that will safe effort in keeping upgrading. I've reviewed all patches on the list, this is the last one to be processed from my perspective. Based on the above, I'm ignoring this series and awaiting a new series applied to master with a request to apply to fido. If it's a minor backport, we can do that automatically, if there are conflicts, please follow Saul's advice on use cherry-pick -x, noting the changes after the upstream commit id and adding your signed-off-by. -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [dizzy][PATCH 2/3] meta-crystalforest: add qat preferred provider
-Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Friday, July 24, 2015 5:44 AM To: Mittal, AnujX; meta-intel@yoctoproject.org; Ong, Boon Leong Subject: Re: [meta-intel] [dizzy][PATCH 2/3] meta-crystalforest: add qat preferred provider On 7/23/15 9:38 AM, Anuj Mittal wrote: Added the qat preferred provider to be qat16. Signed-off-by: Anuj Mittal anujx.mit...@intel.com --- meta-crystalforest/conf/machine/crystalforest.conf |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-crystalforest/conf/machine/crystalforest.conf b/meta- crystalforest/conf/machine/crystalforest.conf index 44b9bb2..84a6df2 100644 --- a/meta-crystalforest/conf/machine/crystalforest.conf +++ b/meta-crystalforest/conf/machine/crystalforest.conf @@ -18,6 +18,8 @@ PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto PREFERRED_VERSION_linux-yocto ?= 3.10% +PREFERRED_PROVIDER_virtual/qat ?= qat16 Your cover letter said crystal forest depends on qat15. Why are we setting it to qat16 here? Default is going to remain qat16 for highland forest platforms. crystal forest highland forest platforms use the same machine - crystalforest. Is there a reason we are doing this as qat15 and qat16 instead of just having two qat recipes with different versions and setting the PREFERRED_VERSION_qat in the machine config? e.g. qat_15-1.7.0-30.bb qat_16-2.2.0-30.bb PREFERRED_VERSION_qat ?= 15-% There shouldn't be a need for a virtual/qat at all. Both qat15 qat16 come from the same package. So PV remains the same between these two. I think it was decided to keep separate names like this to avoid any problems with the upgrade path because of same PV. -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [dizzy][PATCH 0/3] qat fixes for highland forest and crystal forest
-Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Friday, July 24, 2015 5:37 AM To: Mittal, AnujX; meta-intel@yoctoproject.org Subject: Re: [meta-intel] [dizzy][PATCH 0/3] qat fixes for highland forest and crystal forest On 7/23/15 9:38 AM, Anuj Mittal wrote: Dear Maintainer(s), The aim of this patch series is to allow switching between qat16 and qat15 packages for supported platforms on dizzy (highland forest supports qat16 and crystal forest supports qat15). Where is the highland forest PREFERRED_VERSION of 16 change going to be made? The default is going to be highland forest qat16. We're going to provide instructions on how to switch to qat15 for crystal forest. -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [fido master][PATCH 0/2] crystalforest maintainer and readme update
On 7/23/15 3:08 AM, Ong Boon Leong wrote: Darren, This two patches do the following: 1) update the maintainer list for crystalforest and romley to Wu Chia Chuan the resource funded by Intel Comms group to focus on those product lines. 2) Add clarity on how crystal forest, highland forest and river forest platforms are supported within meta-intel as requested by Intel Comms group. Queued, thanks. If you don't have concern, please help apply these 2 patches onto to fido and master. I will be sending another series just to be applied on dizzy branch because this series does not apply neatly onto dizzy branch. Will address those in that thread then. -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] bsps: update meta SRCREVs
On 2015-07-23 6:35 PM, Darren Hart wrote:
Hrm,
What does this apply against?
You need the patches that I sent to oe-core that split the meta data
from the kernel repository (see zedd/kernel in poky-contrib).
The revs must exist in the yocto-kernel-cache repository. It's a
chicken and egg situation. This broke under test when my series is
applied, but can't merge until that series goes into oe-core.
Bruce
WARNING: Failed to fetch URL
git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=standard/base,meta;name=machine,meta,
attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find revision
7a562420b2061216ca7e2dd2195238d51851b9fe in branch meta even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=standard/base,meta;name=machine,meta'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.19.5+gitAUTOINC+7a562420b2_e152349de5-r0/temp/log.do_fetch.32282
ERROR: Task 6
(/build/yocto/master/intel-corei7-64_20141008094748/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb,
do_fetch) failed with exit code '1'
On 7/23/15 3:00 PM, Ross Burton wrote:
From: Bruce Ashfield bruce.ashfi...@windriver.com
Now that the BSP meta data comes from a separate git repository, we
need to update the meta SRCREVs to ones that are valid in that tree
(the previous REVs are only valid in a linux-yocto meta branch).
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend| 4 ++--
common/recipes-kernel/linux/linux-yocto_3.14.bbappend | 4 ++--
common/recipes-kernel/linux/linux-yocto_3.19.bbappend | 4 ++--
meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
index a0b4315..dbf6841 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
LINUX_VERSION_core2-32-intel-common = 3.14.36
COMPATIBLE_MACHINE_core2-32-intel-common = ${MACHINE}
-SRCREV_meta_core2-32-intel-common = 162dfe3bb092c1a792e5ed224fe09672e9814b24
+SRCREV_meta_core2-32-intel-common = c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_core2-32-intel-common =
3fb54cf8f4c3254f628e6c4720fe3c731a9de0b2
KMACHINE_core2-32-intel-common = intel-core2-32
KBRANCH_core2-32-intel-common = standard/preempt-rt/base
@@ -10,7 +10,7 @@ KERNEL_FEATURES_append_core2-32-intel-common =
${KERNEL_FEATURES_INTEL_COMMON}
LINUX_VERSION_corei7-64-intel-common = 3.14.36
COMPATIBLE_MACHINE_corei7-64-intel-common = ${MACHINE}
-SRCREV_meta_corei7-64-intel-common = 162dfe3bb092c1a792e5ed224fe09672e9814b24
+SRCREV_meta_corei7-64-intel-common = c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_corei7-64-intel-common =
3fb54cf8f4c3254f628e6c4720fe3c731a9de0b2
KMACHINE_corei7-64-intel-common = intel-corei7-64
KBRANCH_corei7-64-intel-common = standard/preempt-rt/base
diff --git a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
index 01775b7..2407e86 100644
--- a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
@@ -5,7 +5,7 @@ KERNEL_FEATURES_INTEL_COMMON += features/amt/mei/mei.scc
LINUX_VERSION_core2-32-intel-common = 3.14.39
COMPATIBLE_MACHINE_core2-32-intel-common = ${MACHINE}
-SRCREV_meta_core2-32-intel-common = a996d95104b72c422a56e7d9bc8615ec4219ac74
+SRCREV_meta_core2-32-intel-common = c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_core2-32-intel-common =
bda175966009d5a94103559e6e6ae51279952f39
KMACHINE_core2-32-intel-common = intel-core2-32
KBRANCH_core2-32-intel-common = standard/base
@@ -13,7 +13,7 @@ KERNEL_FEATURES_append_core2-32-intel-common =
${KERNEL_FEATURES_INTEL_COMMON}
LINUX_VERSION_corei7-64-intel-common = 3.14.39
COMPATIBLE_MACHINE_corei7-64-intel-common = ${MACHINE}
-SRCREV_meta_corei7-64-intel-common = a996d95104b72c422a56e7d9bc8615ec4219ac74
+SRCREV_meta_corei7-64-intel-common = c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_corei7-64-intel-common =
bda175966009d5a94103559e6e6ae51279952f39
KMACHINE_corei7-64-intel-common = intel-corei7-64
KBRANCH_corei7-64-intel-common = standard/base
diff --git a/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
b/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
index a0f0e34..a074be0 100644
--- a/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
@@ -5,7 +5,7 @@ KERNEL_FEATURES_INTEL_COMMON +=
Re: [meta-intel] [dizzy][PATCH 0/2] meta-crystalforest readme and maintainer update
On 7/23/15 3:14 AM, Ong Boon Leong wrote: Darren, This patch-series is meant for dizzy branch ONLY. These two patches do the following: 1) update the maintainer list for crystalforest and romley to Wu Chia Chuan the resource funded by Intel Comms group to focus on those product lines. 2) Add clarity on how crystal forest, highland forest and river forest platforms are supported within meta-intel as requested by Intel Comms group. If you don't have concern, please help apply these 2 patches onto to DIZZY. These should be done with cherry-pick -x. I performed the cherry pick manually using your master/fido version, the MATINERS was a one line conflict fix, the README applied cleanly. The log reads as follows: $ git log -2 commit d7c2305f2b6b1025985e1f71110ffa4b094de63b (HEAD, refs/heads/dizzy) Author: Ong Boon Leong boon.leong@intel.com Date: 2015-07-23 meta-crystalforest: update README to include support for River Forest This adds further clarification on how various Intel Communication platforms that are supported across different branches within meta-crystalforest layer. Signed-off-by: Ong Boon Leong boon.leong@intel.com Signed-off-by: Darren Hart dvh...@linux.intel.com (cherry picked from commit 9aa6c066ebf44aecef40caec333772cd970f6842) commit 2d731523cc0130c0e12c70957ff1fa048f179a6d Author: Ong Boon Leong boon.leong@intel.com Date: 2015-07-23 MAINTAINERS: update name for romley and crystal forest BSP This patch updates the maintainer for these two platforms to Wu Chia Chuan. Signed-off-by: Ong Boon Leong boon.leong@intel.com (cherry picked from commit a2b4e15a181728692b1da5808e1690cee9912ce6) [dvh...@linux.intel.com: Applied to dizzy] Signed-off-by: Darren Hart dvh...@linux.intel.com You can do this and submit the patches in this way to dizzy and it preserves the cherry-pick meta-data. I will apply these to dizzy from my cherry-pick this time. Thanks, -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] bsps: update meta SRCREVs
On 7/23/15 3:38 PM, Bruce Ashfield wrote: On 2015-07-23 6:35 PM, Darren Hart wrote: Hrm, What does this apply against? You need the patches that I sent to oe-core that split the meta data from the kernel repository (see zedd/kernel in poky-contrib). The revs must exist in the yocto-kernel-cache repository. It's a chicken and egg situation. This broke under test when my series is applied, but can't merge until that series goes into oe-core. Thanks, somehow I had no idea this was happening. This will need to be updated in the kernel-dev manual. Does this also impact previous releases? fido, dizzy, dora, ... ? -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] bsps: update meta SRCREVs
On 23 July 2015 at 23:38, Bruce Ashfield bruce.ashfi...@windriver.com wrote: You need the patches that I sent to oe-core that split the meta data from the kernel repository (see zedd/kernel in poky-contrib). The revs must exist in the yocto-kernel-cache repository. It's a chicken and egg situation. This broke under test when my series is applied, but can't merge until that series goes into oe-core. For now, I pushed a branch to meta-intel-contrib (ross/kernel) that has this patch for testing with oe-core master-next. Obviously the actual merge to oe-core and meta-intel needs to be orchestrated somehow so there's not a several day lag between the commits. Ross -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [dizzy][PATCH 0/2] meta-crystalforest readme and maintainer update
$ git log -2 commit d7c2305f2b6b1025985e1f71110ffa4b094de63b (HEAD, refs/heads/dizzy) Author: Ong Boon Leong boon.leong@intel.com Date: 2015-07-23 meta-crystalforest: update README to include support for River Forest This adds further clarification on how various Intel Communication platforms that are supported across different branches within meta-crystalforest layer. Signed-off-by: Ong Boon Leong boon.leong@intel.com Signed-off-by: Darren Hart dvh...@linux.intel.com (cherry picked from commit 9aa6c066ebf44aecef40caec333772cd970f6842) commit 2d731523cc0130c0e12c70957ff1fa048f179a6d Author: Ong Boon Leong boon.leong@intel.com Date: 2015-07-23 MAINTAINERS: update name for romley and crystal forest BSP This patch updates the maintainer for these two platforms to Wu Chia Chuan. Signed-off-by: Ong Boon Leong boon.leong@intel.com (cherry picked from commit a2b4e15a181728692b1da5808e1690cee9912ce6) [dvh...@linux.intel.com: Applied to dizzy] Signed-off-by: Darren Hart dvh...@linux.intel.com You can do this and submit the patches in this way to dizzy and it preserves the cherry-pick meta-data. I will apply these to dizzy from my cherry-pick this time. Sure since now it is merged into master. I could resend. -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] bsps: update meta SRCREVs
On 2015-07-23 6:56 PM, Burton, Ross wrote: On 23 July 2015 at 23:45, Bruce Ashfield bruce.ashfi...@windriver.com mailto:bruce.ashfi...@windriver.com wrote: This is only master, and the first tree with no meta branch is the 4.1 kernel tree. Existing branches, with their kernel trees, and tools continue to work as they were. Either it's late (it is) or I'm being dumb (quite likely), but why did we need to fix the 3.19 srvrevs if it only impacts 4.1 kernels? Because the SRC_URI of the main recipe in master now points the meta name at yocto-kernel-cache (as does 3.14). I needed to do that, so I could remove the dead code from the tools and put that into master. Some of the main goals here was to reduce complexity, and promote the sharing of the fragments. So the old stuff goes to the bin :) Bruce Ross -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [master, fido, dizzy][PATCH] meta-crystalforest: add in clarity around how to pick the right QAT version
Add explanation on how to override the default setting under crystalforest.conf on PREFERRED_PROVIDER_virtual/qat. Signed-off-by: Ong Boon Leong boon.leong@intel.com --- meta-crystalforest/README | 25 + 1 file changed, 25 insertions(+) diff --git a/meta-crystalforest/README b/meta-crystalforest/README index 2053a3c..f549f90 100644 --- a/meta-crystalforest/README +++ b/meta-crystalforest/README @@ -204,12 +204,37 @@ Note: qat16 recipe is meant for platform with Coleto Creek chipset. qat15 recipe is meant for platform with Cave Creek chipset. +conf/machine/crystalforest.conf is the common machine configuration +to support Crystal Forest/server, Crystal Forest/gladden, Highland Forest and +River Forest. In order to generate the right binary for these platforms which +have different QAT technology, user could change the default config accordingly +within crystalforest.conf as below: + +For Coleto Creek chipset: +PREFERRED_PROVIDER_virtual/qat ?= qat16 + +For Cave Creek chipset: +PREFERRED_PROVIDER_virtual/qat ?= qat15 + +Another option and preferred approach for above setting is to override +configuration under build/conf/local.conf as follow: + +For Coleto Creek chipset: +PREFERRED_PROVIDER_virtual/qat = qat16 + +For Cave Creek chipset: +PREFERRED_PROVIDER_virtual/qat = qat15 + By default, the machine configuration does not assume that the above ingredients are pre-installed onto the BSP. Developers are required to either use smart tool to install those software packages or configure IMAGE_INSTALL under build/conf/local.conf, for example. +For Coleto Creek chipset: IMAGE_INSTALL += dpdk qat16 zlib-qat +For Cavecreek Creek chipset: +IMAGE_INSTALL += dpdk qat15 zlib-qat + The list of packages can be searched under tmp/deploy/package-type folder. -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [master, fido, dizzy][PATCH] add clarity for QAT selection under crystalforest
Darren, This patch add better clarity about how to pick the right 'qat15' or 'qat16' for various platforms (crystalforest, highlandforest river forest) that shares the common crystalforest.conf machine definition. Please help merge the patch into master, fido and dizzy. Many thanks for the quick turn-around! Boon Leong Ong Boon Leong (1): meta-crystalforest: add in clarity around how to pick the right QAT version meta-crystalforest/README | 25 + 1 file changed, 25 insertions(+) -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] bsps: update meta SRCREVs
Hrm,
What does this apply against?
WARNING: Failed to fetch URL
git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=standard/base,meta;name=machine,meta,
attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find revision
7a562420b2061216ca7e2dd2195238d51851b9fe in branch meta even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=standard/base,meta;name=machine,meta'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.19.5+gitAUTOINC+7a562420b2_e152349de5-r0/temp/log.do_fetch.32282
ERROR: Task 6
(/build/yocto/master/intel-corei7-64_20141008094748/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb,
do_fetch) failed with exit code '1'
On 7/23/15 3:00 PM, Ross Burton wrote:
From: Bruce Ashfield bruce.ashfi...@windriver.com
Now that the BSP meta data comes from a separate git repository, we
need to update the meta SRCREVs to ones that are valid in that tree
(the previous REVs are only valid in a linux-yocto meta branch).
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend| 4 ++--
common/recipes-kernel/linux/linux-yocto_3.14.bbappend | 4 ++--
common/recipes-kernel/linux/linux-yocto_3.19.bbappend | 4 ++--
meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
index a0b4315..dbf6841 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
LINUX_VERSION_core2-32-intel-common = 3.14.36
COMPATIBLE_MACHINE_core2-32-intel-common = ${MACHINE}
-SRCREV_meta_core2-32-intel-common =
162dfe3bb092c1a792e5ed224fe09672e9814b24
+SRCREV_meta_core2-32-intel-common =
c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_core2-32-intel-common =
3fb54cf8f4c3254f628e6c4720fe3c731a9de0b2
KMACHINE_core2-32-intel-common = intel-core2-32
KBRANCH_core2-32-intel-common = standard/preempt-rt/base
@@ -10,7 +10,7 @@ KERNEL_FEATURES_append_core2-32-intel-common =
${KERNEL_FEATURES_INTEL_COMMON}
LINUX_VERSION_corei7-64-intel-common = 3.14.36
COMPATIBLE_MACHINE_corei7-64-intel-common = ${MACHINE}
-SRCREV_meta_corei7-64-intel-common =
162dfe3bb092c1a792e5ed224fe09672e9814b24
+SRCREV_meta_corei7-64-intel-common =
c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_corei7-64-intel-common =
3fb54cf8f4c3254f628e6c4720fe3c731a9de0b2
KMACHINE_corei7-64-intel-common = intel-corei7-64
KBRANCH_corei7-64-intel-common = standard/preempt-rt/base
diff --git a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
index 01775b7..2407e86 100644
--- a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
@@ -5,7 +5,7 @@ KERNEL_FEATURES_INTEL_COMMON += features/amt/mei/mei.scc
LINUX_VERSION_core2-32-intel-common = 3.14.39
COMPATIBLE_MACHINE_core2-32-intel-common = ${MACHINE}
-SRCREV_meta_core2-32-intel-common =
a996d95104b72c422a56e7d9bc8615ec4219ac74
+SRCREV_meta_core2-32-intel-common =
c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_core2-32-intel-common =
bda175966009d5a94103559e6e6ae51279952f39
KMACHINE_core2-32-intel-common = intel-core2-32
KBRANCH_core2-32-intel-common = standard/base
@@ -13,7 +13,7 @@ KERNEL_FEATURES_append_core2-32-intel-common =
${KERNEL_FEATURES_INTEL_COMMON}
LINUX_VERSION_corei7-64-intel-common = 3.14.39
COMPATIBLE_MACHINE_corei7-64-intel-common = ${MACHINE}
-SRCREV_meta_corei7-64-intel-common =
a996d95104b72c422a56e7d9bc8615ec4219ac74
+SRCREV_meta_corei7-64-intel-common =
c33d39561807e1073ca412f1c771f43e4da75994
SRCREV_machine_corei7-64-intel-common =
bda175966009d5a94103559e6e6ae51279952f39
KMACHINE_corei7-64-intel-common = intel-corei7-64
KBRANCH_corei7-64-intel-common = standard/base
diff --git a/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
b/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
index a0f0e34..a074be0 100644
--- a/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_3.19.bbappend
@@ -5,7 +5,7 @@ KERNEL_FEATURES_INTEL_COMMON += features/amt/mei/mei.scc
LINUX_VERSION_core2-32-intel-common = 3.19.5
COMPATIBLE_MACHINE_core2-32-intel-common = ${MACHINE}
-SRCREV_meta_core2-32-intel-common =
913358acd0e27f274c96da7d699e2d18b2c9ee27
+SRCREV_meta_core2-32-intel-common =
7a562420b2061216ca7e2dd2195238d51851b9fe
SRCREV_machine_core2-32-intel-common =
[meta-intel] [dizzy][PATCH 3/3] meta-crystalforest: zlib-qat depends on virtual/qat
Made zlib-qat DEPENDS on virtual/qat. This allows
us to switch between highland forest and crystal
forest platforms.
Signed-off-by: Anuj Mittal anujx.mit...@intel.com
---
.../zlib-qat/zlib-qat_0.4.7-002.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
b/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
index 4400696..1869f32 100644
--- a/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
+++ b/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM =
file://${WORKDIR}/zlib-${ZLIB_VERSION}/zlib.h;beginline=4;en
# For target side versions of openssl enable support for OCF Linux driver
# if they are available.
-DEPENDS += cryptodev-linux pkgconfig qat16
+DEPENDS += cryptodev-linux pkgconfig virtual/qat
SRC_URI = http://www.zlib.net/zlib-${ZLIB_VERSION}.tar.gz;name=zlib \
https://01.org/sites/default/files/page/zlib_shim_0.4.7-002_withdocumentation.zip;name=zlibqat
\
--
1.7.9.5
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [dizzy][PATCH 2/3] meta-crystalforest: add qat preferred provider
Added the qat preferred provider to be qat16. Signed-off-by: Anuj Mittal anujx.mit...@intel.com --- meta-crystalforest/conf/machine/crystalforest.conf |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-crystalforest/conf/machine/crystalforest.conf b/meta-crystalforest/conf/machine/crystalforest.conf index 44b9bb2..84a6df2 100644 --- a/meta-crystalforest/conf/machine/crystalforest.conf +++ b/meta-crystalforest/conf/machine/crystalforest.conf @@ -18,6 +18,8 @@ PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto PREFERRED_VERSION_linux-yocto ?= 3.10% +PREFERRED_PROVIDER_virtual/qat ?= qat16 + require conf/machine/include/intel-corei7-64-common.inc require conf/machine/include/intel-common-pkgarch.inc require conf/machine/include/meta-intel.inc -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [dizzy][PATCH 1/3] meta-crystalforest: add virtual/qat provider
Changed qat to PROVIDES virtual/qat so we can switch
between qat15 and qat16 for highland forest and
crystalforest.
Signed-off-by: Anuj Mittal anujx.mit...@intel.com
---
meta-crystalforest/recipes-extended/qat/qat.inc |1 +
1 file changed, 1 insertion(+)
diff --git a/meta-crystalforest/recipes-extended/qat/qat.inc
b/meta-crystalforest/recipes-extended/qat/qat.inc
index 0053204..6a2ceff 100644
--- a/meta-crystalforest/recipes-extended/qat/qat.inc
+++ b/meta-crystalforest/recipes-extended/qat/qat.inc
@@ -6,6 +6,7 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
COMPATIBLE_MACHINE = crystalforest
DEPENDS += cryptodev-linux pkgconfig zlib
+PROVIDES += virtual/qat
MODULE_DIR = ${D}${base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers
ICP_TOOLS = accelcomp
--
1.7.9.5
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [dizzy][PATCH 0/3] qat fixes for highland forest and crystal forest
Dear Maintainer(s), The aim of this patch series is to allow switching between qat16 and qat15 packages for supported platforms on dizzy (highland forest supports qat16 and crystal forest supports qat15). zlib-qat now depends on virtual/qat instead of qat16. qat15 is not supported in fido master as of now. Only dizzy supports qat15 on crystal forest platforms with Intel 8900-8920 Series chipsets (Cave Creek). Please merge these commits only in dizzy if these look okay. Thank you. Anuj Mittal (3): meta-crystalforest: add virtual/qat provider meta-crystalforest: add qat preferred provider meta-crystalforest: zlib-qat depends on virtual/qat meta-crystalforest/conf/machine/crystalforest.conf |2 ++ meta-crystalforest/recipes-extended/qat/qat.inc|1 + .../zlib-qat/zlib-qat_0.4.7-002.bb |2 +- 3 files changed, 4 insertions(+), 1 deletion(-) -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [dizzy][PATCH 3/3] meta-crystalforest: zlib-qat depends on virtual/qat
-Original Message-
From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
boun...@yoctoproject.org] On Behalf Of Anuj Mittal
Sent: Friday, July 24, 2015 12:39 AM
To: meta-intel@yoctoproject.org
Subject: [meta-intel] [dizzy][PATCH 3/3] meta-crystalforest: zlib-qat depends
on
virtual/qat
Made zlib-qat DEPENDS on virtual/qat. This allows us to switch between
highland forest and crystal forest platforms.
Signed-off-by: Anuj Mittal anujx.mit...@intel.com
Acked-by: Ong Boon Leong boon.leong@intel.com
---
.../zlib-qat/zlib-qat_0.4.7-002.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
b/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
index 4400696..1869f32 100644
--- a/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
+++ b/meta-crystalforest/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = file://${WORKDIR}/zlib-
${ZLIB_VERSION}/zlib.h;beginline=4;en
# For target side versions of openssl enable support for OCF Linux driver #
if
they are available.
-DEPENDS += cryptodev-linux pkgconfig qat16
+DEPENDS += cryptodev-linux pkgconfig virtual/qat
SRC_URI = http://www.zlib.net/zlib-${ZLIB_VERSION}.tar.gz;name=zlib \
https://01.org/sites/default/files/page/zlib_shim_0.4.7-
002_withdocumentation.zip;name=zlibqat \
--
1.7.9.5
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [fido master][PATCH 2/2] meta-crystalforest: update README to include support for River Forest
This adds further clarification on how various Intel Communication platforms that are supported across different branches within meta-crystalforest layer. Signed-off-by: Ong Boon Leong boon.leong@intel.com --- meta-crystalforest/README | 100 - 1 file changed, 62 insertions(+), 38 deletions(-) diff --git a/meta-crystalforest/README b/meta-crystalforest/README index 210df56..2053a3c 100644 --- a/meta-crystalforest/README +++ b/meta-crystalforest/README @@ -2,34 +2,38 @@ This README file contains information on building the meta-crystalforest BSP layer, and booting the images contained in the /binary directory. Please see the corresponding sections below for details. -The 'Crystal Forest' platform consists of two versions. -1. GLADDEN -2. SERVER +Overview of Intel Communication Product Offering + -The Gladden Platform consists of Intel Xeon E3-1125C/E3-1105C Processor, -plus the Intel Communication Chipset 89xx for Smaller Form Factor -Communication Infrastructure. -(Gladden + Cave Creek) also known as CrystalForest-Gladden +The following platforms are supported on meta-intel dizzy branch ONLY: -The Server Platform consists of Intel Xeon E5-2600 and E5-2400 Processors, -plus the Intel Communication Chipset 89xx for Large-Scale Communications -Infrastructure. -(Ivy Bridge-EP/EN + Coleto Creek) also known as HighlandForest -(Sandy Bridge-EP/EN + Cave Creek) also known as CrystalForest-Server +Crystal Forest/Server - Shumway reference platform configurations: +processor: Intel Xeon E5-2600/E5-2400 (Sandy Bridge-based) or + Intel Xeon E5-2600v2/E5-2400v2 (Ivy Bridge-based) +chipset: Intel Communication Chipset 8900-8920 Series (Cave Creek) +url: http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-e5-89xx/overview -Both Platforms use Matrox graphics Card. +Crystal Forest/Gladden - Stargo reference platform configurations: +processor: Intel Xeon E3-1125C/E3-1105C (Sandy Bridge-based) or + Intel Xeon E3-1125v2/E3-1105v2 (Ivy Bridge-based) +chipset: Intel Communication Chipset 8900-8920 Series (Cave Creek) +url: http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-core-pentium-celeron-89xx/overview -Further information about the Crystal Forest Gladden platform supported -by this BSP can be found here: +Highland Forest (Crystal Forest/Server Refresh) - Shumway reference platform configurations: +processor: Intel Xeon E5-2600v2/E5-2400v2 (Ivy Bridge-based) +chipset: Intel Communication Chipset 8925-8955 Series (Coleto Creek) +url: https://www-ssl.intel.com/content/www/us/en/intelligent-systems/crystal-forest-server/xeon-e5-v2-89xx-chipset-ibd.html - http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-core-pentium-celeron-89xx/overview +The following platform is supported on meta-intel fido branch and beyond. -Further information about the Crystal Forest server platform supported -by this BSP can be found here: +River Forest - Long Brook reference platform configurations: +processor: Intel Xeon E5-2600v3/E5-2400v3 (Haswell EP-based) +chipset: Intel Communication Chipset 8925-8955 Series (Coleto Creek) +url: https://www-ssl.intel.com/content/www/my/en/embedded/products/river-forest/overview.html?wapkw=coleto - http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-e5-89xx/overview +All above four platforms use PCIe-based Matrox graphics card for display. -Information on all Intel® embedded platforms can be found here: +More Information on all Intel® embedded platforms can be found here: http://www.intel.com/p/en_US/embedded/hwsw/hardware @@ -65,7 +69,7 @@ Patches Please submit any patches against this BSP to the meta-intel mailing list (meta-intel@yoctoproject.org) and cc: the maintainer: -Maintainer: Chan Wei Sern wei.sern.c...@intel.com +Maintainer: Wu Chia Chuan chia.chuan...@intel.com Please see the meta-intel/MAINTAINERS file for more details. @@ -114,6 +118,8 @@ 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 that below, in the section 'Booting the images from /binary'). +The live image is located within build/tmp/deploy/images/machine folder. + 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 @@ -131,15 +137,26 @@ II. Booting the images in /binary This BSP contains bootable live images, which can be used to directly boot Yocto off of a USB flash drive. -Under Linux, insert a USB flash drive. Assuming the USB flash drive -takes device /dev/sdf, use dd to copy the live image to it. For -example: +You can deploy the hddimg image to a USB or SATA device. You will +need to know the device name on your host as well as the device name on +the target. Be careful with this step
[meta-intel] [fido master][PATCH 0/2] crystalforest maintainer and readme update
Darren, This two patches do the following: 1) update the maintainer list for crystalforest and romley to Wu Chia Chuan the resource funded by Intel Comms group to focus on those product lines. 2) Add clarity on how crystal forest, highland forest and river forest platforms are supported within meta-intel as requested by Intel Comms group. If you don't have concern, please help apply these 2 patches onto to fido and master. I will be sending another series just to be applied on dizzy branch because this series does not apply neatly onto dizzy branch. Many thanks Boon Leong Ong Boon Leong (2): MAINTAINERS: update name for romley and crystal forest BSP meta-crystalforest: update README to include support for River Forest MAINTAINERS |4 +- meta-crystalforest/README | 100 - 2 files changed, 64 insertions(+), 40 deletions(-) -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [fido master][PATCH 1/2] MAINTAINERS: update name for romley and crystal forest BSP
This patch updates the maintainer for these two platforms to Wu Chia Chuan. Signed-off-by: Ong Boon Leong boon.leong@intel.com --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9c3b3af..6401963 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -36,7 +36,7 @@ M:Saul Wold s...@linux.intel.com F: meta-crownbay/ CRYSTALFOREST -M: Saul Wold s...@linux.intel.com +M: Wu Chia Chuan chia.chuan...@intel.com F: meta-crystalforest/ EMENLOW @@ -52,7 +52,7 @@ M:Saul Wold s...@linux.intel.com F: meta-jasperforest/ ROMLEY -M: Haw Foo Chien foo.chien@intel.com +M: Wu Chia Chuan chia.chuan...@intel.com F: meta-romley/ SUGARBAY -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] Partprobe hang at boot for edison builds
Hello guys, I'm facing a very strange bug on Edison board using the Intel Edison Breakout board: sometimes, partprobe hangs at boot. In order to reproduce the behavior I compiled a new vanilla Intel build using source code and instructions from git:// git.yoctoproject.org/meta-intel-edison (0c8a23e linux: fix the do_kernel_checkout error in src building). After this I added a service as it follows to catch a hang: $ cat /lib/systemd/system/test.service [Unit] Description=Test service Requires=resin-init.service After=resin-init.service [Service] ExecStart=/usr/sbin/partprobe ; /sbin/reboot Type=oneshot RemainAfterExit=yes [Install] WantedBy=basic.target When partprobe hangs, the service shows the hang: root@edison:~# systemctl status test ��● test.service - Test service Loaded: loaded (/lib/systemd/system/test.service; enabled) Active: activating (start) since Thu 2015-07-23 00:49:36 UTC; 19min ago Main PID: 186 (partprobe) CGroup: /system.slice/test.service ��└��─186 /usr/sbin/partprobe As well, after a while on serial kernel dumps these messages: [ 240.632138] INFO: task mmcqd/0boot0:70 blocked for more than 120 seconds. [ 240.632233] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.632982] INFO: task partprobe:186 blocked for more than 120 seconds. Relevant or not, when the board doesn't hang, if I run partprobe manually it throws errors as it follows: root@edison:~# partprobe [ 1196.432197] end_request: I/O error, dev mmcblk0rpmb, sector 0 [ 1196.496034] end_request: I/O error, dev mmcblk0rpmb, sector 0 Warning: Error fsyncing/closing /dev/mmcblk0rpmb: Input/output error This is a blocking issue for us (at resin.io) because we suspect that the underlying cause of this issue is affecting us in another bug that is way harder to explain or to reproduce. Have you ever seen something like this? I would gladly help in any way possible for debugging and fixing this bug. Right now the only lead I had was to use a patch similar to: http://permalink.gmane.org/gmane.linux.kernel.mmc/24260 . I booted a kernel with this patch and nothing changes regarding to this bug. As well I'd like to mention that these behaviors are reproducible on multiple boards - just to rule out the hardware issue possibility. Regards, -- Andrei Gherzan -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [dizzy][PATCH 0/2] meta-crystalforest readme and maintainer update
Darren, This patch-series is meant for dizzy branch ONLY. These two patches do the following: 1) update the maintainer list for crystalforest and romley to Wu Chia Chuan the resource funded by Intel Comms group to focus on those product lines. 2) Add clarity on how crystal forest, highland forest and river forest platforms are supported within meta-intel as requested by Intel Comms group. If you don't have concern, please help apply these 2 patches onto to DIZZY. Many thanks Boon Leong Ong Boon Leong (2): MAINTAINERS: update name for romley and crystal forest BSP meta-crystalforest: update README to include support for River Forest MAINTAINERS |4 +- meta-crystalforest/README | 100 - 2 files changed, 64 insertions(+), 40 deletions(-) -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [dizzy][PATCH 1/2] MAINTAINERS: update name for romley and crystal forest BSP
This patch updates the maintainer for these two platforms to Wu Chia Chuan. Signed-off-by: Ong Boon Leong boon.leong@intel.com --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b7cd2a3..2f77f45 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -36,7 +36,7 @@ M:Nitin A Kamblenitin.a.kam...@intel.com F: meta-crownbay/ CRYSTALFOREST -M: Ong Boon Leong boon.leong@intel.com +M: Wu Chia Chuan chia.chuan...@intel.com F: meta-crystalforest/ EMENLOW @@ -52,7 +52,7 @@ M:Nitin A Kamblenitin.a.kam...@intel.com F: meta-jasperforest/ ROMLEY -M: Haw Foo Chien foo.chien@intel.com +M: Wu Chia Chuan chia.chuan...@intel.com F: meta-romley/ SUGARBAY -- 1.7.9.5 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [dizzy][PATCH 2/2] meta-crystalforest: update README to include support for River Forest
This adds further clarification on how various Intel Communication platforms that are supported across different branches within meta-crystalforest layer. Signed-off-by: Ong Boon Leong boon.leong@intel.com --- meta-crystalforest/README | 100 - 1 file changed, 62 insertions(+), 38 deletions(-) diff --git a/meta-crystalforest/README b/meta-crystalforest/README index 210df56..2053a3c 100644 --- a/meta-crystalforest/README +++ b/meta-crystalforest/README @@ -2,34 +2,38 @@ This README file contains information on building the meta-crystalforest BSP layer, and booting the images contained in the /binary directory. Please see the corresponding sections below for details. -The 'Crystal Forest' platform consists of two versions. -1. GLADDEN -2. SERVER +Overview of Intel Communication Product Offering + -The Gladden Platform consists of Intel Xeon E3-1125C/E3-1105C Processor, -plus the Intel Communication Chipset 89xx for Smaller Form Factor -Communication Infrastructure. -(Gladden + Cave Creek) also known as CrystalForest-Gladden +The following platforms are supported on meta-intel dizzy branch ONLY: -The Server Platform consists of Intel Xeon E5-2600 and E5-2400 Processors, -plus the Intel Communication Chipset 89xx for Large-Scale Communications -Infrastructure. -(Ivy Bridge-EP/EN + Coleto Creek) also known as HighlandForest -(Sandy Bridge-EP/EN + Cave Creek) also known as CrystalForest-Server +Crystal Forest/Server - Shumway reference platform configurations: +processor: Intel Xeon E5-2600/E5-2400 (Sandy Bridge-based) or + Intel Xeon E5-2600v2/E5-2400v2 (Ivy Bridge-based) +chipset: Intel Communication Chipset 8900-8920 Series (Cave Creek) +url: http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-e5-89xx/overview -Both Platforms use Matrox graphics Card. +Crystal Forest/Gladden - Stargo reference platform configurations: +processor: Intel Xeon E3-1125C/E3-1105C (Sandy Bridge-based) or + Intel Xeon E3-1125v2/E3-1105v2 (Ivy Bridge-based) +chipset: Intel Communication Chipset 8900-8920 Series (Cave Creek) +url: http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-core-pentium-celeron-89xx/overview -Further information about the Crystal Forest Gladden platform supported -by this BSP can be found here: +Highland Forest (Crystal Forest/Server Refresh) - Shumway reference platform configurations: +processor: Intel Xeon E5-2600v2/E5-2400v2 (Ivy Bridge-based) +chipset: Intel Communication Chipset 8925-8955 Series (Coleto Creek) +url: https://www-ssl.intel.com/content/www/us/en/intelligent-systems/crystal-forest-server/xeon-e5-v2-89xx-chipset-ibd.html - http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-core-pentium-celeron-89xx/overview +The following platform is supported on meta-intel fido branch and beyond. -Further information about the Crystal Forest server platform supported -by this BSP can be found here: +River Forest - Long Brook reference platform configurations: +processor: Intel Xeon E5-2600v3/E5-2400v3 (Haswell EP-based) +chipset: Intel Communication Chipset 8925-8955 Series (Coleto Creek) +url: https://www-ssl.intel.com/content/www/my/en/embedded/products/river-forest/overview.html?wapkw=coleto - http://www.intel.com/p/en_US/embedded/hwsw/hardware/xeon-e5-89xx/overview +All above four platforms use PCIe-based Matrox graphics card for display. -Information on all Intel® embedded platforms can be found here: +More Information on all Intel® embedded platforms can be found here: http://www.intel.com/p/en_US/embedded/hwsw/hardware @@ -65,7 +69,7 @@ Patches Please submit any patches against this BSP to the meta-intel mailing list (meta-intel@yoctoproject.org) and cc: the maintainer: -Maintainer: Chan Wei Sern wei.sern.c...@intel.com +Maintainer: Wu Chia Chuan chia.chuan...@intel.com Please see the meta-intel/MAINTAINERS file for more details. @@ -114,6 +118,8 @@ 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 that below, in the section 'Booting the images from /binary'). +The live image is located within build/tmp/deploy/images/machine folder. + 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 @@ -131,15 +137,26 @@ II. Booting the images in /binary This BSP contains bootable live images, which can be used to directly boot Yocto off of a USB flash drive. -Under Linux, insert a USB flash drive. Assuming the USB flash drive -takes device /dev/sdf, use dd to copy the live image to it. For -example: +You can deploy the hddimg image to a USB or SATA device. You will +need to know the device name on your host as well as the device name on +the target. Be careful with this step
