Re: [meta-intel] [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs images
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, July 21, 2014 12:30 PM
To: Kamble, Nitin A
Cc: Zanussi, Tom; Hart, Darren; Purdie, Richard; meta-intel@yoctoproject.org
Subject: Re: [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs
images
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).
As this change will be in oecore layer, adding oecore mailing list to this
thread.
The INITRD variable is used at different places like grub-efi.bbclass,
syslinux.bbclass, bootimg.bbclass, gummyboot.bbclass, boot-directdisk.bbclass,
image-live.bbclass . So extending INITRD var is going to be bit invasive. Let
me see if this can be handled in less invasive way.
Nitin
Ross
--
___
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 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
--
___
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
[meta-intel] [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs images
From: Nitin A Kamble nitin.a.kam...@intel.com
This provides extensions to the image_types and image-live classes to enable
the initramfs recipes with early microcode support.
Look at these bbclass files from the oecore layer for context, as this is
extending functionality available there.
meta/classes/image_types.bbclass
meta/classes/image_live.bbclass
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Acked-by: Darren Hart dvh...@linux.intel.com
---
classes/image-ucode.bbclass | 17 +
1 file changed, 17 insertions(+)
create mode 100644 classes/image-ucode.bbclass
diff --git a/classes/image-ucode.bbclass b/classes/image-ucode.bbclass
new file mode 100644
index 000..93ac28e
--- /dev/null
+++ b/classes/image-ucode.bbclass
@@ -0,0 +1,17 @@
+# This provides extensions to the image_types and image-live classes to enable
+# the initramfs recipes with early microcode support.
+#
+# Look at these bbclass files from the oecore layer for context, as this is
+# extending functionality available there.
+# meta/classes/image_types.bbclass
+# meta/classes/image_live.bbclass
+#
+
+# extentions to image_types.bbclass
+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
+
+# Extentions to image-live.bbclass
+EARLY_UCODE_CPIO ?= ${DEPLOY_DIR_IMAGE}/microcode.cpio
--
1.8.1.4
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
