Re: [meta-intel] [Patch v4 5/6] core-image-minimal-initramfs: extend to support early microcode loading
On Fri, 2014-07-18 at 17:18 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
If the microcode support is enabled in the license flags, then consume the
microcode.cpio to generate an initrd which is extended with the earlyload
microcode support.
This recipe now can optionally generate 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 | 4
1 file changed, 4 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..1592630
--- /dev/null
+++ b/common/recipes-core/images/core-image-minimal-initramfs.bbappend
@@ -0,0 +1,4 @@
+inherit image-ucode
+
+# if the microcode support is enabled, then build the microcode enabled
initrd
+IMAGE_FSTYPES .= ${@['', '.ucode']['license_intel-microcode' in
d.getVar('LICENSE_FLAGS_WHITELIST', True)]}
Nearly there but this also needs to check if this is an x86 BSP. There
is no point in adding this to an ARM image for example. x86 in
OVERRIDES might be a good check iirc.
Cheers,
Richard
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] How should I do to make it boot on the low-end machine with 64MB main memory?
Title: Samsung Enterprise Portal mySingle Hi,I'm trying to run Tizen Linux in the machine with Intel ivy bridge, and 64MB main memory. I followed the instructions in https://wiki.tizen.org/wiki/Tizen_on_yocto. But it failed to boot becuase out of memory. The image which is made after the instructions includes weston for GUI, and systemd for init. It seems that they use too many memory to run on the machine with 64MB. I saw that the image core-image-sato,which includes X and matchbox for GUI and sysvinit for init,is able to run on QEMU-ARM with 64MB, even though it failed to do on QEMU-x86_64. But especially I am interested to boot the image with weston. I wonder what I am missing.Is there someone who succeeded to boot the Tizen Linux or a Linux with weston in this kind of environments, or can give me some advice? Thanks. Best regards,Hyungwon Hwang -- ___ 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
