Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode
On 9/17/14, 13:51, Kamble, Nitin A nitin.a.kam...@intel.com wrote: The problem with this of course is we can't use it easily with the common BSPs and ultimately we want to eliminate as many of the other BSPs as possible. What is the exact issue with microcode? How does it break certain systems when enabled on the intel common BSPs? 1st there is no boot issue related to microcode. What was reported is a build issue. His initrd file was not built correctly. And we believe that it happened because he used older version of poky/oecore. So that is turning out to be a build setup issue. Here are the updates on the bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6730 Nitin Oh great! So what's the status of this then? Can it be enabled by default? -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/2] intel-corei7-64.conf: include the AMT daemon in the images
On 9/17/14, 15:52, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
On 9/17/14, 12:58 PM, Hart, Darren darren.h...@intel.com wrote:
On 9/17/14, 12:44, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Some of the platforms supported by the intel-corei7-64 BSP have AMT
feature
on the platform. Enable it so that it can get utilized with this BSP.
How does this impact boot of systems without AMT support? 32 and 64 bit?
This change just adds the AMT module to the images. It would not affect
booting unless a system has broken AMT firmware. In that case the
machine-setup-tool configuration can be used to blacklist the mei kernel
driver.
Nitin
Thanks,
Acked-by: Darren Hart dvh...@linux.intel.com
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
conf/machine/intel-corei7-64.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/machine/intel-corei7-64.conf
b/conf/machine/intel-corei7-64.conf
index c3b08bc..97d57b3 100644
--- a/conf/machine/intel-corei7-64.conf
+++ b/conf/machine/intel-corei7-64.conf
@@ -16,7 +16,7 @@ MACHINE_FEATURES += wifi 3g
MACHINE_HWCODECS ?= va-intel gst-va-intel
-MACHINE_EXTRA_RRECOMMENDS += linux-firmware
+MACHINE_EXTRA_RRECOMMENDS += linux-firmware lms8
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
--
1.8.1.4
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode
On 9/18/14, 9:18, Kamble, Nitin A nitin.a.kam...@intel.com wrote: On 9/18/14, 9:13 AM, Hart, Darren darren.h...@intel.com wrote: On 9/17/14, 13:51, Kamble, Nitin A nitin.a.kam...@intel.com wrote: The problem with this of course is we can't use it easily with the common BSPs and ultimately we want to eliminate as many of the other BSPs as possible. What is the exact issue with microcode? How does it break certain systems when enabled on the intel common BSPs? 1st there is no boot issue related to microcode. What was reported is a build issue. His initrd file was not built correctly. And we believe that it happened because he used older version of poky/oecore. So that is turning out to be a build setup issue. Here are the updates on the bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6730 Nitin Oh great! So what's the status of this then? Can it be enabled by default? I see no blockage for enabling by default. But usages like microyocto may want to disable the feature to save some space. So I am working on make the the intel microcode feature available as a machine feature, and all the machines in meta-intel will include the machine feature. Right, and I should have said make it the default for intel-core* machines. Thanks Nitin, -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode
On 9/17/14, 13:23, Kamble, Nitin A nitin.a.kam...@intel.com wrote: No, we had this discussion. These BSPs need to build out of the box without special flags to disable feature that would otherwise break it on supported systems. If Microcode can't be enabled generically and safely, then it needs to be opt-in, not opt-out. -- Darren We discussed this a bit on jabber. The new proposal is to make it a MACHINE_FEATURE and add it to all the machine .conf files from meta-intel. The problem with this of course is we can't use it easily with the common BSPs and ultimately we want to eliminate as many of the other BSPs as possible. What is the exact issue with microcode? How does it break certain systems when enabled on the intel common BSPs? -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v5 3/5] intel-microcode: a recipe for Intel microcode datafile
On 8/29/14, 10:22, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com This recipe provides the microcode datafile for Intel Processors. The recipe provides: 1. microcode.dat file for microcode updating from user space with the iucode-tool utility. 2. the microcode cpio file which gets bundled with the initrd to support microcode loading at early boot time. [ YOCTO #5114 ] Signed-off-by: Ross Burton ross.bur...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v5 5/5] use the INITRD list mechanism for early microcode loading
On 9/2/14, 8:29, Kamble, Nitin A nitin.a.kam...@intel.com wrote: -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, September 01, 2014 8:39 AM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; meta-intel@yoctoproject.org Subject: Re: [Patch v5 5/5] use the INITRD list mechanism for early microcode loading On 29 August 2014 18:22, nitin.a.kam...@intel.com wrote: # if enabled, include user space intel microcode loading support in the generated images. MACHINE_EXTRA_RRECOMMENDS = intel-microcode iucode-tool + +# if enabled, use the microcode added initrd I don't see any conditional tests for the if enabled part of the comment. Ross Good catch, I have fixed the comment on the contrib branch now. Hrm... I confess I forget where we left this. Do we not need the enabled condition? What happens if you try to build images for meta-intel systems without the meta-intel license whitelisted? My understanding is that those recipes still need to parse, but that will fail if the license requirements are not met. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs images
On 7/21/14, 12:29, Burton, Ross ross.bur...@intel.com wrote:
On 19 July 2014 01:18, nitin.a.kam...@intel.com wrote:
+IMAGE_TYPES += cpio.gz.ucode
+COMPRESSIONTYPES += gz.ucode
+COMPRESS_CMD_gz.ucode = ${COMPRESS_CMD_gz}; cat ${EARLY_UCODE_CPIO}
${IMAGE_NAME}.rootfs.${type}.gz ${IMAGE_NAME}.rootfs.${type}.gz.ucode
+COMPRESS_DEPENDS_gz.ucode = ${COMPRESS_DEPENDS_gz} intel-microcode
Something about this has always bugged me and I just realised what it
is. As I understand it the kernel allows an arbitrary number of cpio
archives to be appended to the kernel, but our image creation code
expects one. This class is basically working around that limitation
by being a specialised image type that appends another hard-coded
file.
If the image creation code was changed to expect a list, then we
wouldn't need this class at all but could simply do INITRD +=
$(EARLY_UCODE_CPIO).
Ross
Ooooh, clever boy.
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/1] image-ucode.bbclass: add dependency on the microcode cpio provider
On 7/18/14, 9:55, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The ${EARLY_UCODE_CPIO} file is generated by the intel-microcode recipe.
Even
though the intel-microcode recipe is included for every Intel BSP,
mention it
here additionally as it won't hurt anything, and it can reveal the
dependency
to the reviewer easily.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
classes/image-ucode.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/classes/image-ucode.bbclass b/classes/image-ucode.bbclass
index a0a3240..93ac28e 100644
--- a/classes/image-ucode.bbclass
+++ b/classes/image-ucode.bbclass
@@ -11,7 +11,7 @@
IMAGE_TYPES += cpio.gz.ucode
COMPRESSIONTYPES += gz.ucode
COMPRESS_CMD_gz.ucode = ${COMPRESS_CMD_gz}; cat ${EARLY_UCODE_CPIO}
${IMAGE_NAME}.rootfs.${type}.gz ${IMAGE_NAME}.rootfs.${type}.gz.ucode
-COMPRESS_DEPENDS_gz.ucode = ${COMPRESS_DEPENDS_gz}
+COMPRESS_DEPENDS_gz.ucode = ${COMPRESS_DEPENDS_gz} intel-microcode
# Extentions to image-live.bbclass
EARLY_UCODE_CPIO ?= ${DEPLOY_DIR_IMAGE}/microcode.cpio
--
1.8.1.4
OK, but this should just be done as part of 5/7 of the previous series
which hasn't been merged yet. Can you include it and update your contrib
branch? No need to resend. I'll then review for any pending comments and
pull.
One thing I don't think I've seen discussed is the level of testing this
has received. Maybe I missed it? In any case - what level of testing has
this received?
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 6/7] core-image-minimal-initramfs: extend to support early microcode loading
On 7/18/14, 10:59, Hart, Darren darren.h...@intel.com wrote: On 7/17/14, 15:27, Kamble, Nitin A nitin.a.kam...@intel.com wrote: +IMAGE_FSTYPES_meta-intel = cpio.gz.ucode -- 1.8.1.4 Hrm A meta-intel override... Do we need to introduce a layer override, or would the intel-common overrides be sufficient? It would reduce the complexity a bit. I have renamed the override to intel-common now. Well, what about the comment below? Nitin I do see the value in the layer override though as it applies to the BSPs that are not yet intel-common - or won't ever be. If you use the intel common overrides, then machines that don't share a common kernel cannot have microcode support? That seems overly restrictive to me. Ah, you are not using the same override as the common pkgarch, I misunderstood what you meant by intel-common. OK, this is fine either way. So.. Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- Darren HartOpen Source Technology Center darren.h...@intel.com Intel Corporation -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 6/7] core-image-minimal-initramfs: extend to support early microcode loading
On 7/17/14, 15:27, Kamble, Nitin A nitin.a.kam...@intel.com wrote: +IMAGE_FSTYPES_meta-intel = cpio.gz.ucode -- 1.8.1.4 Hrm A meta-intel override... Do we need to introduce a layer override, or would the intel-common overrides be sufficient? It would reduce the complexity a bit. I have renamed the override to intel-common now. Well, what about the comment below? Nitin I do see the value in the layer override though as it applies to the BSPs that are not yet intel-common - or won't ever be. If you use the intel common overrides, then machines that don't share a common kernel cannot have microcode support? That seems overly restrictive to me. So.. Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.comIntel Corporation -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 1/7] meta-intel BSPs: include meta-intel.inc
On 7/11/14, 11:59, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com To get common intel BSP configurations such as user land microcode loading support, each Intel BSP configuration needs to include the meta-intel.inc file. With the exception of few, many of the meta-intel BSP configuration files already include the meta-intel.inc file. With this commit now, all the remaining BSPs from the meta-intel layer also include meta-intel.inc file. The Intel platforms BSPs hosted outside of the meta-intel layer, such as minnow, need to include meta-intel.inc to get the common Intel features. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com Yes, agreed, all meta-intel BSPs should include meta-intel.inc. I had considered making this implicit in the intel-common*... But not all BSPs will use that, and including this everywhere makes it obvious and is more consistent. Reviewed-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 2/7] iucode-tool: a new recipe for loading Intel CPU microcode
On 7/11/14, 11:59, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com iucode_tool is a program to manipulate Intel i686 and X86-64 processor microcode update collections, and to use the kernel facilities to update the microcode on Intel system processors. Signed-off-by: Ross Burton ross.bur...@intel.com Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com Proper location and recipe format appears correct. Reviewed-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 3/7] intel-microcode: a recipe for Intel microcode datafile
On 7/11/14, 11:59, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
This recipe provides the microcode datafile for Intel Processors.
The recipe provides:
1. microcode.dat file for microcode updating from user space with the
iucode-tool utility.
2. the microcode cpio file which gets bundled with the initrd to support
microcode loading at early boot time.
Note that this recipe has LICENSE_FLAGS so will need to be whitelisted
before
it's usable.
This should be documented in the layer someplace. Can be done as a
follow-up patch.
[ YOCTO #5114 ]
Signed-off-by: Ross Burton ross.bur...@intel.com
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
common/custom-licenses/Intel-Microcode-License | 123
+
.../microcode/intel-microcode_20140430.bb | 53 +
2 files changed, 176 insertions(+)
create mode 100644 common/custom-licenses/Intel-Microcode-License
create mode 100644
common/recipes-core/microcode/intel-microcode_20140430.bb
...
diff --git a/common/recipes-core/microcode/intel-microcode_20140430.bb
b/common/recipes-core/microcode/intel-microcode_20140430.bb
new file mode 100644
index 000..f8aa45f
--- /dev/null
+++ b/common/recipes-core/microcode/intel-microcode_20140430.bb
@@ -0,0 +1,53 @@
+SUMMARY = Intel Processor Microcode Datafile for Linux
+HOMEPAGE = http://www.intel.com/;
+DESCRIPTION = The microcode data file contains the latest microcode\
+ definitions for all Intel processors. Intel releases microcode updates\
+ to correct processor behavior as documented in the respective processor\
+ specification updates. While the regular approach to getting this
microcode\
+ update is via a BIOS upgrade, Intel realizes that this can be an\
+ administrative hassle. The Linux operating system and VMware ESX\
+ products have a mechanism to update the microcode after booting.\
+ For example, this file will be used by the operating system mechanism\
+ if the file is placed in the /etc/firmware directory of the Linux
system.
+
+LICENSE = Intel-Microcode-License
+LICENSE_FLAGS = license_${PN}_${PV}
+LIC_FILES_CHKSUM =
file://microcode.dat;md5=64b91c8f504ef24a040ca129d1c2f657
+
+SRC_URI =
http://downloadmirror.intel.com/23829/eng/microcode-20140430.tgz;
+SRC_URI[md5sum] = 99c811133b002d1e73150f667a6a77f4
+SRC_URI[sha256sum] =
2e67767fd561164a2b09831020c2d36600ad336a9c0c117f1964edef284e4351
Why do we provide both? Is this accepted best practice? Just seems like
extra maintenance to me...
Otherwise, looks good, no objections.
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 4/7] meta-intel BSPs: enable user space microcode loading support
On 7/11/14, 11:59, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Enable user space microcode loading support for all the BSPs using the meta-intel.inc file. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- conf/machine/include/meta-intel.inc | 5 + 1 file changed, 5 insertions(+) diff --git a/conf/machine/include/meta-intel.inc b/conf/machine/include/meta-intel.inc index fb9b4a8..4baefc8 100644 --- a/conf/machine/include/meta-intel.inc +++ b/conf/machine/include/meta-intel.inc @@ -24,3 +24,8 @@ XSERVER_X86_MATROX_MGA = xf86-video-mga \ XSERVER_X86_ASPEED_AST = xf86-video-ast \ + + + +# Enable all BSPs from meta-intel layer with user space Intel microcode loading support. +MACHINE_EXTRA_RRECOMMENDS += intel-microcode iucode-tool -- 1.8.1.4 Seems like 4 and 7 can be done together. Any particular reason to keep them separate? -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 6/7] core-image-minimal-initramfs: extend to support early microcode loading
On 7/11/14, 11:59, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Consumes the intel-earlyload-microcode-image to generate an initrd which
is
extended with the earlyload microcode support.
This recipe now generates this additional initrd image:
core-image-minimal-initramfs-${MACHINE}.cpio.gz.ucode
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
common/recipes-core/images/core-image-minimal-initramfs.bbappend | 3 +++
1 file changed, 3 insertions(+)
create mode 100644
common/recipes-core/images/core-image-minimal-initramfs.bbappend
diff --git
a/common/recipes-core/images/core-image-minimal-initramfs.bbappend
b/common/recipes-core/images/core-image-minimal-initramfs.bbappend
new file mode 100644
index 000..d836400
--- /dev/null
+++ b/common/recipes-core/images/core-image-minimal-initramfs.bbappend
@@ -0,0 +1,3 @@
+inherit image-ucode
+
+IMAGE_FSTYPES_meta-intel = cpio.gz.ucode
--
1.8.1.4
Hrm A meta-intel override... Do we need to introduce a layer override,
or would the intel-common overrides be sufficient? It would reduce the
complexity a bit.
I do see the value in the layer override though as it applies to the BSPs
that are not yet intel-common - or won't ever be.
So..
Acked-by: Darren Hart dvh...@linux.intel.com
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 2/3] emenlow-noemgd: linux-yocto_3.14: use standard/base machine branch
On 5/13/14, 10:31, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
There is no need to use the standard/emenlow branch, as it points
to the same commit as standard/base branch.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Acked-by: Darren Hart dvh...@linux.intel.com
---
meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend
b/meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend
index 5d40da7..dae087d 100644
--- a/meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend
+++ b/meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_emenlow-noemgd = emenlow-noemgd
KMACHINE_emenlow-noemgd = emenlow
-KBRANCH_emenlow-noemgd = standard/emenlow
+KBRANCH_emenlow-noemgd = standard/base
KERNEL_FEATURES_append_emenlow-noemgd = features/drm-gma500/drm-gma500
LINUX_VERSION_emenlow-noemgd = 3.14.2
--
1.8.1.4
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 3/3] fri2-noemgd: linux-yocto_3.14: use standard/base machine branch
On 5/13/14, 10:32, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
There is no need to use the standard/fri2 branch, as it points
to the same commit as standard/base branch.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Acked-by: Darren Hart dvh...@linux.intel.com
---
meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend
b/meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend
index 49bf44d..7b437f7 100644
--- a/meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend
+++ b/meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_fri2-noemgd = fri2-noemgd
KMACHINE_fri2-noemgd = fri2
-KBRANCH_fri2-noemgd = standard/fri2
+KBRANCH_fri2-noemgd = standard/base
KERNEL_FEATURES_append_fri2-noemgd = cfg/vesafb
LINUX_VERSION_fri2-noemgd = 3.14.2
SRCREV_machine_fri2-noemgd = b0b9c962ea01f9356fc1542b9696ebe4a38e196a
--
1.8.1.4
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/6] Remove chiefriver, sys940x n450 BSPs
On 3/25/14, 22:08, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Configuration for the chiefriver, sys940x, sys940x-noemgd, n450 BSPs are deleted. The consolidated BSPs viz intel-corei7-64 and intel-core2-32 support these boards. As part of the usual retirement process, a heads-up email was sent to the meta-intel mailing list requesting any feedback regarding retirement of these BSPs. The community did not had any concerning feedback to reconsider the retirement decision. The MAINTAINERS file and the layer version of the meta-intel layer are updated to reflect removal of the BSPs. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com CC: Darren Hart dvh...@linux.intel.com Reviewed-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 2/6] emenlow: linux-yocto-3.10 update srcrevs to 3.10.33
On 3/25/14, 22:08, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Sync up with the latest branch HEADs on the linux-yocto_3.10 repository.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Hrm... Why are emgd and noemgd using different meta SRCREVs?
+SRCREV_meta_emenlow = 99c503a92885060bebf2bba6747735e8e9346a40
+SRCREV_meta_emenlow-noemgd = 6e0e756d51372c8b176c5d1e6f786545bceed351
--
Darren
---
meta-emenlow/recipes-kernel/linux/linux-yocto_3.10.bbappend | 12
++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta-emenlow/recipes-kernel/linux/linux-yocto_3.10.bbappend
b/meta-emenlow/recipes-kernel/linux/linux-yocto_3.10.bbappend
index 6075783..2d4a5bc 100644
--- a/meta-emenlow/recipes-kernel/linux/linux-yocto_3.10.bbappend
+++ b/meta-emenlow/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -11,13 +11,13 @@ KMACHINE_emenlow-noemgd = emenlow
KBRANCH_emenlow-noemgd = standard/emenlow
KERNEL_FEATURES_append_emenlow-noemgd = features/drm-gma500/drm-gma500
-LINUX_VERSION = 3.10.19
+LINUX_VERSION = 3.10.33
-SRCREV_meta_emenlow = d9cd83c0292bd4e2a6754a96761027252e726a42
-SRCREV_machine_emenlow = a9ec82e355130160f9094e670bd5be0022a84194
-SRCREV_emgd_emenlow = 39c44dd7838bfd228938219cdb21ca30c4d0cbbf
+SRCREV_meta_emenlow = 99c503a92885060bebf2bba6747735e8e9346a40
+SRCREV_machine_emenlow = 21df0c8486e129a4087970a07b423c533ae05de7
+SRCREV_emgd_emenlow = 42d5e4548e8e79e094fa8697949eed4cf6af00a3
-SRCREV_meta_emenlow-noemgd = d9cd83c0292bd4e2a6754a96761027252e726a42
-SRCREV_machine_emenlow-noemgd =
a9ec82e355130160f9094e670bd5be0022a84194
+SRCREV_meta_emenlow-noemgd = 6e0e756d51372c8b176c5d1e6f786545bceed351
+SRCREV_machine_emenlow-noemgd =
21df0c8486e129a4087970a07b423c533ae05de7
SRC_URI_emenlow =
git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1
;branch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd
--
1.8.1.4
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 4/6] nuc: linux-yocto-3.10 update srcrevs to 3.10.33
On 3/25/14, 22:08, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Sync up with the latest branch HEADs on the linux-yocto_3.10 repository. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta-nuc/recipes-kernel/linux/linux-yocto_3.10.bbappend | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta-nuc/recipes-kernel/linux/linux-yocto_3.10.bbappend b/meta-nuc/recipes-kernel/linux/linux-yocto_3.10.bbappend index ec67460..237b572 100644 --- a/meta-nuc/recipes-kernel/linux/linux-yocto_3.10.bbappend +++ b/meta-nuc/recipes-kernel/linux/linux-yocto_3.10.bbappend @@ -7,9 +7,9 @@ KBRANCH_nuc = standard/common-pc-64/chiefriver If we're deleting chiefriver, we should also kill the branch, and the branch is the same as standard/base, so we should just be using that too. Also, if we are using the common kernel for nuc, this entire recipe should be deleted. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 5/6] crownbay: linux-yocto-3.10 update srcrevs to 3.10.33
On 3/25/14, 22:08, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Even these should have commit messages. For example, see:
commit f122b5a10114416c55d015305fdd011d86e71353
Author: Darren Hart dvh...@linux.intel.com
Date: 2014-03-24
fri2: Update linux-yocto 3.10 SRCREV (3.10.33-LTSI)
Update to the HEAD of standard/fri2 (3.10.33-LTSI). This also works
around an open issue with do_validate_branches where feature branches
are reset the HEAD of the machine branch if they contain that commit.
Signed-off-by: Darren Hart dvh...@linux.intel.com
It only takes a minute to write the message, but it's there forever and
you never know who might need some context about what we were doing around
this time.
--
Darren
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
index 37cf96e..c2339fa 100644
--- a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -11,13 +11,13 @@ KMACHINE_crownbay-noemgd = crownbay
KBRANCH_crownbay-noemgd = standard/crownbay
KERNEL_FEATURES_append_crownbay-noemgd = cfg/vesafb
-LINUX_VERSION = 3.10.32
+LINUX_VERSION = 3.10.33
-SRCREV_meta_crownbay = 6e0e756d51372c8b176c5d1e6f786545bceed351
-SRCREV_machine_crownbay = 78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
+SRCREV_meta_crownbay = 99c503a92885060bebf2bba6747735e8e9346a40
+SRCREV_machine_crownbay = 21df0c8486e129a4087970a07b423c533ae05de7
SRCREV_emgd_crownbay = 42d5e4548e8e79e094fa8697949eed4cf6af00a3
SRCREV_meta_crownbay-noemgd = 6e0e756d51372c8b176c5d1e6f786545bceed351
-SRCREV_machine_crownbay-noemgd =
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
+SRCREV_machine_crownbay-noemgd =
21df0c8486e129a4087970a07b423c533ae05de7
SRC_URI_crownbay =
git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1
;branch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd
--
1.8.1.4
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 6/6] common linux-yocto-3.10: specify kernel SRCREVs
On 3/25/14, 22:08, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Define the kernel branch SRCREVs in meta-intel layer, so that other
layers can not break the common BSP kernel unknowingly.
Using the latest HEADs of the git branches for SRCREVs.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Thanks Nitin,
Reviewed-by: Darren Hart dvh...@linux.intel.com
---
common/recipes-kernel/linux/linux-yocto_3.10.bbappend | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
b/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
index 01e3f77..650919f 100644
--- a/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -2,18 +2,18 @@ FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
KERNEL_FEATURES_INTEL_COMMON += features/amt/mei/mei.scc
-#LINUX_VERSION_core2-32-intel-common = 3.10
+LINUX_VERSION_core2-32-intel-common = 3.10.33
COMPATIBLE_MACHINE_core2-32-intel-common = ${MACHINE}
-#SRCREV_meta_core2-32-intel-common = ${AUTOREV}
-#SRCREV_machine_core2-32-intel-common = ${AUTOREV}
+SRCREV_meta_core2-32-intel-common =
99c503a92885060bebf2bba6747735e8e9346a40
+SRCREV_machine_core2-32-intel-common =
21df0c8486e129a4087970a07b423c533ae05de7
KMACHINE_core2-32-intel-common = intel-core2-32
KBRANCH_core2-32-intel-common = standard/base
KERNEL_FEATURES_append_core2-32-intel-common =
${KERNEL_FEATURES_INTEL_COMMON}
-#LINUX_VERSION_corei7-64-intel-common = 3.10
+LINUX_VERSION_corei7-64-intel-common = 3.10.33
COMPATIBLE_MACHINE_corei7-64-intel-common = ${MACHINE}
-#SRCREV_meta_corei7-64-intel-common = ${AUTOREV}
-#SRCREV_machine_corei7-64-intel-common = ${AUTOREV}
+SRCREV_meta_corei7-64-intel-common =
99c503a92885060bebf2bba6747735e8e9346a40
+SRCREV_machine_corei7-64-intel-common =
21df0c8486e129a4087970a07b423c533ae05de7
KMACHINE_intel-corei7-64-intel-common = intel-corei7-64
KBRANCH_intel-corei7-64-intel-common = standard/base
KERNEL_FEATURES_append_corei7-64-intel-common =
${KERNEL_FEATURES_INTEL_COMMON}
--
1.8.1.4
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] Build failure
I believe I know what the issue is, I'll have a patch out by EOD. On 3/17/14, 2:22, Richard Purdie richard.pur...@linuxfoundation.org wrote: After the recent linux-yocto-rt changes, we're seeing a build failure: http://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds /90/steps/BuildImages/logs/stdio Reproducer is MACHINE=fri2-emgd bitbake universe -c fetch (or just bitbake linux-yocto-rt) Cheers, Richard -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 4/6] lms7: update the source download URL
On 3/6/14, 12:52, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
-Original Message-
From: Hart, Darren
Sent: Wednesday, March 05, 2014 11:08 PM
To: Kamble, Nitin A; Zanussi, Tom; meta-intel@yoctoproject.org
Subject: Re: [PATCH 4/6] lms7: update the source download URL
On 3/5/14, 20:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
On 3/5/2014 7:48 PM, Hart, Darren wrote:
On 3/5/14, 17:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The old URL is not working anymore. Using a new URL for source zip
file.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
common/recipes-bsp/amt/lms7_7.1.20.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-bsp/amt/lms7_7.1.20.bb
b/common/recipes-bsp/amt/lms7_7.1.20.bb
index 9bc9ef1..261f968 100644
--- a/common/recipes-bsp/amt/lms7_7.1.20.bb
+++ b/common/recipes-bsp/amt/lms7_7.1.20.bb
@@ -8,7 +8,7 @@ LICENSE = BSD_LMS
PR = r0
BPN=lms
PV_SUB = 25
-SRC_URI =
http://software.intel.com/file/37962;downloadfilename=${BPN}+${PV}.
$
{PV
_S
UB}.zip \
+SRC_URI =
http://software.intel.com/sites/default/files/m/4/e/a/9/b/37962-lms_
7.1
.2
0.25.zip
I suppose there is no real harm in dropping the use of the PR/PV/etc
variables in the URL, but seems a bit odd to do so, any particular
reason to do so?
I copy pasted the actual URL. The filename is changed too, so there is
no fixed naming scheme here to make good use of the variables.
OK, so doesn't that leave BPN now unused? And BPN basically unused,
except in do_unpack() where it is used in the tar filename... Which
should
probably match how you refer to it in the SRC_URI.
BPN var is also used in the packaging, so BPN is not left unused. But if
it is a concern I can easily revert the SRC_URI filename to use all the
variables.
Sorry, I meant BPN and PV_SUB It was late.
Anyway, this isn't critical stuff, it just seems a bit inconsistent, which
can lead to confusion and bugs later when things are updated. Have a look
at it, do what you think needs doing to make it consistent and avoid
leaving unused variables lying around, and I'm sure it'll be fine.
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 1/1] lms7: update the source download URL
On 3/6/14, 13:51, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The old URL is not working anymore. Using a new URL for source zip file. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 3/6] alsa-state: ALSA config for intel-corei7-64 BSP
On 3/5/14, 17:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Provide ALSA config file for intel-corei7-64 BSP which enables ALSA sound on hardware like NUC. This is HIGHLY machine specific unless I am sorely mistaken, this should not be made part of a generic BSP. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 4/6] lms7: update the source download URL
On 3/5/14, 17:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The old URL is not working anymore. Using a new URL for source zip file.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
common/recipes-bsp/amt/lms7_7.1.20.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-bsp/amt/lms7_7.1.20.bb
b/common/recipes-bsp/amt/lms7_7.1.20.bb
index 9bc9ef1..261f968 100644
--- a/common/recipes-bsp/amt/lms7_7.1.20.bb
+++ b/common/recipes-bsp/amt/lms7_7.1.20.bb
@@ -8,7 +8,7 @@ LICENSE = BSD_LMS
PR = r0
BPN=lms
PV_SUB = 25
-SRC_URI =
http://software.intel.com/file/37962;downloadfilename=${BPN}+${PV}.${PV_S
UB}.zip \
+SRC_URI =
http://software.intel.com/sites/default/files/m/4/e/a/9/b/37962-lms_7.1.2
0.25.zip
I suppose there is no real harm in dropping the use of the PR/PV/etc
variables in the URL, but seems a bit odd to do so, any particular reason
to do so?
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 5/6] nuc BSP: include AMT 8+ support
On 3/5/14, 17:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Include support for Intel Active Management Technology version 8+ on the
NUC BSP.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Acked-by: Darren Hart dvh...@linux.intel.com
---
meta-nuc/conf/machine/nuc.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-nuc/conf/machine/nuc.conf
b/meta-nuc/conf/machine/nuc.conf
index 7dcfcc8..631d360 100644
--- a/meta-nuc/conf/machine/nuc.conf
+++ b/meta-nuc/conf/machine/nuc.conf
@@ -19,7 +19,7 @@ XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_I965} \
-MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6
+MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
--
1.8.1.4
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 4/6] lms7: update the source download URL
On 3/5/14, 20:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
On 3/5/2014 7:48 PM, Hart, Darren wrote:
On 3/5/14, 17:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The old URL is not working anymore. Using a new URL for source zip
file.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
common/recipes-bsp/amt/lms7_7.1.20.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-bsp/amt/lms7_7.1.20.bb
b/common/recipes-bsp/amt/lms7_7.1.20.bb
index 9bc9ef1..261f968 100644
--- a/common/recipes-bsp/amt/lms7_7.1.20.bb
+++ b/common/recipes-bsp/amt/lms7_7.1.20.bb
@@ -8,7 +8,7 @@ LICENSE = BSD_LMS
PR = r0
BPN=lms
PV_SUB = 25
-SRC_URI =
http://software.intel.com/file/37962;downloadfilename=${BPN}+${PV}.${PV
_S
UB}.zip \
+SRC_URI =
http://software.intel.com/sites/default/files/m/4/e/a/9/b/37962-lms_7.1
.2
0.25.zip
I suppose there is no real harm in dropping the use of the PR/PV/etc
variables in the URL, but seems a bit odd to do so, any particular
reason
to do so?
I copy pasted the actual URL. The filename is changed too, so there is
no fixed naming scheme here to make good use of the variables.
OK, so doesn't that leave BPN now unused? And BPN basically unused, except
in do_unpack() where it is used in the tar filename... Which should
probably match how you refer to it in the SRC_URI.
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 3/6] alsa-state: ALSA config for intel-corei7-64 BSP
On 3/5/14, 20:56, Kamble, Nitin A nitin.a.kam...@intel.com wrote: On 3/5/2014 7:47 PM, Hart, Darren wrote: On 3/5/14, 17:58, Kamble, Nitin A nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Provide ALSA config file for intel-corei7-64 BSP which enables ALSA sound on hardware like NUC. This is HIGHLY machine specific unless I am sorely mistaken, this should not be made part of a generic BSP. This is a static file, but there is another initscripts commit in this pull request, which changes this file as per the machine needs. I saw the initiscript patch which dynamically rewrites asound.conf. It seems to me there are a great deal of variables it can't really account for. But independent of that, I don't think we want to use initscripts that run at every boot to dynamically overwrite configuration files. We should have a higher level design and planning discussion before we start creating one-off solutions for each config file. I suspect if we decide to have some kind of a runtime config, we'll want a run-once mechanism, or possibly something that runs in the installer, not at every boot. Did you already have some broader scheme in mind as to how to address the larger problem of supporting multiple platforms with a single image. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] Next Gen Intel BSPs
On 2/25/14, 21:44, Zanussi, Tom tom.zanu...@intel.com wrote:
On Thu, 2014-02-20 at 20:56 -0600, Tom Zanussi wrote:
On Tue, 2014-02-11 at 18:18 -0600, Hart, Darren wrote:
All,
I have just pushed the next-gen Intel BSP changes following the meta
commits to linux-yocto-dev and linux-yocto-3.10.
Changes include:
1) New common BSPs:
intel-core2-32: Support core2 and old atom (pre-baytrail) CPUs
intel-corei7-64: Support Nehalem and Baytrail and newer
core/xeon/atom CPUs
[ ] Beth: Can you please add these two BSPs to meta-intel-nightly?
2) New INTEL_COMMON_PACKAGE_ARCH
This is set to ${TUNE_PKGARCH}-intel-common and applies to any BSP
including intel-common-pkgarch.inc. This demotes the linux-yocto and
linux-yocto-dev recipes to a PACKAGE_ARCH less specific than
MACHINE_ARCH
(the default for linux-yocto*). For machines that include the
intel-common-pkgarch.inc and delete their linux-yocto*bbappend Files,
they
will reuse the intel-common linux-yocto* package. This is either the
intel-core2-32-intel-common or the intel-corei7-64-intel-common
kernel,
the same one used for the two new BSPs.
Using the new intel-common PACKAGE_ARCH is an opt-in mechanism.
Currently
only the two new BSPs are using it, although the linux-yocto
meta-data is
already building in support for all the non-emgd meta-intel BSPs.
Next step is to add the inclusion of the intel-common-pkgarch.inc to
every
BSP and delete the linux-yocto machine-specific bbappend and
build/boot/verify each BSP. Such a patch series exists here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=dvhar
t/
bsp-ng
Just FYI...
crownbay-noemgd from bsp-ng boots but X doesn't start (last good boot or
normal non-bsp-ng bSP was 2/12 so it's either this patchset or something
in master since then, will look into it...):
using poky/master: bb0c26960d3b05070346cdfdfd05d6fd4ad0a7b1
So the problem here is some kind of interference with the CONFIG_GMA600,
which is now turned on by default - I'll have to either dig into find
the actual problem or just turn it off for _crownbay-noegd...
Oh... Hrm... We should actually be able to use that driver now on the
Tunnel Creek systems as of 3.10-LTSI and 3.13+. Scott Garman tested it on
the MinnowBoard, I haven't done so myself unfortunately. Do we specify
another driver in the xorg.conf or something that is causing some
confusion about which driver to use?
--
Darren
Tom
Stopping Bootlog daemon: bootlogd.
Loading extension GLX
Poky (Yocto Project Reference Distro) 1.5+snapshot-20140221
crownbay-noemgd /dev/ttyS0
crownbay-noemgd login: vesa: Ignoring device with a bound kernel driver
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at /var/log/Xorg.0.log for
additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
Poky (Yocto Project Reference Distro) 1.5+snapshot-20140221
crownbay-noemgd /dev/ttyS0
crownbay-noemgd login: xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
Poky (Yocto Project Reference Distro) 1.5+snapshot-20140221
crownbay-noemgd /dev/ttyS0
This adds amt/mei to the intel-common kernel as well as autoloading
of uio
and iwlwifi to accommodate crystal forest,romley, and fri2 default
settings.
This branch is running meta-intel-nightly Build #42 on ab03
[ ] Nitin, can you help nurse this patch series into something ready
to
commit? Including some boot testing?
[ ] Boon Leon, this update the ISG BSPs as well to use the common
kernel.
This only impacts the upcoming 1.6 release. Please review and boot
test
and let us know if you have any objections to these changes to your
BSPs.
This series also purges all the 3.4 and 3.8 linux-yocto* bbappends
from
the meta-intel master branch as they are no longer supported for 1.6.
With
3.10 LTSI now merged, the time has come to remove them.
The diffstat here is rather pleasing from a maintenance perspective
:-)
$ git diff origin/master.. | diffstat -s
81 files changed, 62 insertions(+), 934 deletions(-)
Thanks,
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] Next Gen Intel BSPs (GMA600 on TunnelCreek)
Scott, question for you below...
On 2/25/14, 21:56, Zanussi, Tom tom.zanu...@intel.com wrote:
On Tue, 2014-02-25 at 07:48 -0600, Hart, Darren wrote:
On 2/25/14, 21:44, Zanussi, Tom tom.zanu...@intel.com wrote:
On Thu, 2014-02-20 at 20:56 -0600, Tom Zanussi wrote:
On Tue, 2014-02-11 at 18:18 -0600, Hart, Darren wrote:
All,
I have just pushed the next-gen Intel BSP changes following the
meta
commits to linux-yocto-dev and linux-yocto-3.10.
Changes include:
1) New common BSPs:
intel-core2-32: Support core2 and old atom (pre-baytrail) CPUs
intel-corei7-64: Support Nehalem and Baytrail and newer
core/xeon/atom CPUs
[ ] Beth: Can you please add these two BSPs to meta-intel-nightly?
2) New INTEL_COMMON_PACKAGE_ARCH
This is set to ${TUNE_PKGARCH}-intel-common and applies to any BSP
including intel-common-pkgarch.inc. This demotes the linux-yocto
and
linux-yocto-dev recipes to a PACKAGE_ARCH less specific than
MACHINE_ARCH
(the default for linux-yocto*). For machines that include the
intel-common-pkgarch.inc and delete their linux-yocto*bbappend
Files,
they
will reuse the intel-common linux-yocto* package. This is either
the
intel-core2-32-intel-common or the intel-corei7-64-intel-common
kernel,
the same one used for the two new BSPs.
Using the new intel-common PACKAGE_ARCH is an opt-in mechanism.
Currently
only the two new BSPs are using it, although the linux-yocto
meta-data is
already building in support for all the non-emgd meta-intel BSPs.
Next step is to add the inclusion of the intel-common-pkgarch.inc
to
every
BSP and delete the linux-yocto machine-specific bbappend and
build/boot/verify each BSP. Such a patch series exists here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=dvh
ar
t/
bsp-ng
Just FYI...
crownbay-noemgd from bsp-ng boots but X doesn't start (last good
boot or
normal non-bsp-ng bSP was 2/12 so it's either this patchset or
something
in master since then, will look into it...):
using poky/master: bb0c26960d3b05070346cdfdfd05d6fd4ad0a7b1
So the problem here is some kind of interference with the
CONFIG_GMA600,
which is now turned on by default - I'll have to either dig into find
the actual problem or just turn it off for _crownbay-noegd...
Oh... Hrm... We should actually be able to use that driver now on the
Tunnel Creek systems as of 3.10-LTSI and 3.13+. Scott Garman tested it
on
the MinnowBoard, I haven't done so myself unfortunately. Do we specify
another driver in the xorg.conf or something that is causing some
confusion about which driver to use?
No, there's no special xorg.conf for crownbay-noemgd...
Scott, did you have to do something special to get the gma600 driver
working on the MinnowBoard? Did it require you to write an xorg.conf?
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] Next Gen Intel BSPs
On 2/20/14, 18:56, Zanussi, Tom tom.zanu...@intel.com wrote:
On Tue, 2014-02-11 at 18:18 -0600, Hart, Darren wrote:
All,
I have just pushed the next-gen Intel BSP changes following the meta
commits to linux-yocto-dev and linux-yocto-3.10.
Changes include:
1) New common BSPs:
intel-core2-32: Support core2 and old atom (pre-baytrail) CPUs
intel-corei7-64: Support Nehalem and Baytrail and newer core/xeon/atom
CPUs
[ ] Beth: Can you please add these two BSPs to meta-intel-nightly?
2) New INTEL_COMMON_PACKAGE_ARCH
This is set to ${TUNE_PKGARCH}-intel-common and applies to any BSP
including intel-common-pkgarch.inc. This demotes the linux-yocto and
linux-yocto-dev recipes to a PACKAGE_ARCH less specific than
MACHINE_ARCH
(the default for linux-yocto*). For machines that include the
intel-common-pkgarch.inc and delete their linux-yocto*bbappend Files,
they
will reuse the intel-common linux-yocto* package. This is either the
intel-core2-32-intel-common or the intel-corei7-64-intel-common kernel,
the same one used for the two new BSPs.
Using the new intel-common PACKAGE_ARCH is an opt-in mechanism.
Currently
only the two new BSPs are using it, although the linux-yocto meta-data
is
already building in support for all the non-emgd meta-intel BSPs.
Next step is to add the inclusion of the intel-common-pkgarch.inc to
every
BSP and delete the linux-yocto machine-specific bbappend and
build/boot/verify each BSP. Such a patch series exists here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=dvhar
t/
bsp-ng
Just FYI...
crownbay-noemgd from bsp-ng boots but X doesn't start (last good boot or
normal non-bsp-ng bSP was 2/12 so it's either this patchset or something
in master since then, will look into it...):
Thanks Tom,
I discovered tonight that I botched the PACKAGE_EXTRA_ARCHS variable in
intel-common-pkgarch. I omitted the trailing S, causing the kernel-modules
package to not be found and not be installed. I've pushed the fix to
meta-intel/master, and updated the dvhart/bsp-ng branch on top of it and
pushed that out to contrib. Probably worth trying with that now. Sorry
about that :-/
--
Darren
using poky/master: bb0c26960d3b05070346cdfdfd05d6fd4ad0a7b1
Stopping Bootlog daemon: bootlogd.
Loading extension GLX
Poky (Yocto Project Reference Distro) 1.5+snapshot-20140221
crownbay-noemgd /dev/ttyS0
crownbay-noemgd login: vesa: Ignoring device with a bound kernel driver
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at /var/log/Xorg.0.log for
additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
Poky (Yocto Project Reference Distro) 1.5+snapshot-20140221
crownbay-noemgd /dev/ttyS0
crownbay-noemgd login: xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
Poky (Yocto Project Reference Distro) 1.5+snapshot-20140221
crownbay-noemgd /dev/ttyS0
This adds amt/mei to the intel-common kernel as well as autoloading of
uio
and iwlwifi to accommodate crystal forest,romley, and fri2 default
settings.
This branch is running meta-intel-nightly Build #42 on ab03
[ ] Nitin, can you help nurse this patch series into something ready to
commit? Including some boot testing?
[ ] Boon Leon, this update the ISG BSPs as well to use the common
kernel.
This only impacts the upcoming 1.6 release. Please review and boot test
and let us know if you have any objections to these changes to your
BSPs.
This series also purges all the 3.4 and 3.8 linux-yocto* bbappends from
the meta-intel master branch as they are no longer supported for 1.6.
With
3.10 LTSI now merged, the time has come to remove them.
The diffstat here is rather pleasing from a maintenance perspective :-)
$ git diff origin/master.. | diffstat -s
81 files changed, 62 insertions(+), 934 deletions(-)
Thanks,
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] grub-efi change pending
Thanks for the heads up! Saul Wold s...@linux.intel.com wrote: Guys, We have a change pending in MUT which will rename the grub-efi-native to grub-efi, this will affect meta-intel as some BSP might have a .bbappend file. Can you have a look at http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stage/master_under_testid=c22ff1ee899126cee8e5edd9fb8c3f487f6f932e Darren has already reviewed these, but they will require some action on your part. Thanks -- Sau! Saul Wold Yocto Component Wrangler @ Intel Yocto Project / Poky Build System ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] ia32-base: Remove cpio and ext3 defaults
On Thu, 2013-11-21 at 15:25 +, Richard Purdie wrote: On real IA hardware, neither the ext3 or cpio images are particularly useful or used. cpio is legacy from initramfs and that specific image now overrides FSTYPES accordingly. The size difference in filesystems makes ext3 as a file format less useful, mainly being useful in the qemu case. When needed users can still override the default FSTYPES so having saner defaults makes sense. This improves build times and uses less network bandwidth for builds and releases. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org I'm fine with this, although it raises the question if we ought to be doing anything more than tar rootfs in include files like this. there are ia32 machines where a live image is not useful (although rare). Most x86 BSPs would add live - but then again, most x86 BSPs will be starting to consolidate on the genericx86 BSPs anyway But, this is a clear improvement as is. Acked-by: Darren Hart dvh...@linux.intel.com --- diff --git a/meta/conf/machine/include/ia32-base.inc b/meta/conf/machine/include/ia32-base.inc index 8a20bca..e15f927 100644 --- a/meta/conf/machine/include/ia32-base.inc +++ b/meta/conf/machine/include/ia32-base.inc @@ -10,7 +10,7 @@ MACHINE_FEATURES += screen keyboard pci usbhost ext2 ext3 x86 \ MACHINE_EXTRA_RRECOMMENDS += kernel-modules -IMAGE_FSTYPES += ext3 cpio.gz live +IMAGE_FSTYPES += live KERNEL_IMAGETYPE ?= bzImage -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
