> -----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-in...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
