[meta-intel] [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs images

[Kamble, Nitin A]

> -----Original Message-----
> From: Burton, Ross [mailto:ross.burton at intel.com]
> Sent: Monday, July 21, 2014 12:30 PM
> To: Kamble, Nitin A
> Cc: Zanussi, Tom; Hart, Darren; Purdie, Richard; meta-intel at 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.kamble at 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