[OE-core] [PATCH 1/2] image_types: Add elf image type

Darren Hart dvhart at linux.intel.com
Wed Jun 27 21:32:48 UTC 2012



On 06/27/2012 01:43 PM, Raymond Danks wrote:
> On 06/27/2012 02:34 PM, Raymond Danks wrote:
>> Hi Darren,
>>
>> Thanks for the feedback.
>>
>> On 06/25/2012 10:58 AM, Darren Hart wrote:
>>> Hi Raymond,
>>>
>>> On 06/22/2012 01:22 PM, Raymond Danks wrote:
>>>> On x86, an ELF image file may be stored as a coreboot payload.
>>>> The image file is constructed, using the mkelfimage utility,
>>>> from a kernel and an initrd.
>>>>
>>> Is this usable solely as a coreboot payload?
>>>
>>> The reason I ask is there have been requests to be able to build the
>>> kernel+initramfs that the Linux make system supports. The coreboot wiki
>>> suggests that this may be sufficient in lieu of the mkelfimage format.
>>>
>>> http://www.coreboot.org/Mkelfimage
>>>
>>> If we can satisfy both goals with one image type, I would prefer we do
>>> that, at least for the core.
>> I have not tried this.
>>
>> I prefer the mkelfimage mechanism over the linux kernel's mechanism 
>> due to the manner in which the OpenEmbedded build process is laid 
>> out.  In my experience, the rootfs/initrd is constructed *after* the 
>> kernel and is not necessarily available for inclusion by the kernel 
>> build.
>>
>> Of course, if you have a patch for this, I'd be happy to give that a try.
> 
> One more point of interest I guess:
> 
> I was able to boot this elf file using syslinux and mboot.c32.  So, 
> depending upon your use case, it may be possible to use this elf file 
> instead of the kernel+initramfs.

That is excellent news. It is certainly better suited to our workflow
than the Linux Kernel mechanism.

--
Darren

> 
>>>> Signed-off-by: Raymond Danks<ray.danks at se-eng.com>
>>>> ---
>>>> This was originally submitted to the openembedded project:
>>>> http://patches.openembedded.org/patch/7689/
>>>>
>>>> Resubmitting to oe-core for review prior to commit in 
>>>> openembedded-core.
>>>>
>>>>   meta/classes/image_types.bbclass |   18 +++++++++++++++++-
>>>>   1 files changed, 17 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/meta/classes/image_types.bbclass 
>>>> b/meta/classes/image_types.bbclass
>>>> index 55f122e..bbca20c 100644
>>>> --- a/meta/classes/image_types.bbclass
>>>> +++ b/meta/classes/image_types.bbclass
>>>> @@ -7,6 +7,12 @@ def get_imagecmds(d):
>>>>       ctypes = d.getVar('COMPRESSIONTYPES', True).split()
>>>>       cimages = {}
>>>>
>>>> +    if "elf" in alltypes:
>>>> +        alltypes.remove("elf")
>>>> +        if "cpio.gz" not in alltypes:
>>>> +                alltypes.append("cpio.gz")
>>>> +        alltypes.append("elf")
>>>> +
>>> What is the goal of this? Do you just need cpio.gz to appear before elf
>>> in the list?
>> Yes.  The cpio.gz is an input to the mkelfimage command below.
>>> If so, can that just be checked for at the time of adding
>>> elf the first time?
>> Possibly.  Can you tell me where this is done?
>>>
>>>>       # Filter out all the compressed images from types
>>>>       for type in alltypes:
>>>>           basetype = None
>>>> @@ -173,6 +179,14 @@ IMAGE_CMD_cpio () {
>>>>       cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H 
>>>> newc>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
>>>>   }
>>>>
>>>> +ELF_KERNEL ?= ${STAGING_DIR_HOST}/kernel/bzImage
>>> There are various kernel image types. Is the elf format only valid with
>>> bzImage?
>> The mkelfimage documentation indicates that bzImage and vmlinux are 
>> supported.  I have only worked with bzImage.  That said, I agree that 
>> this is more appropriate:
>>
>> ELF_KERNEL ?= ${STAGING_DIR_HOST}/kernel/${KERNEL_IMAGETYPE}
>>>
>>>> +ELF_APPEND ?= "ramdisk_size=32768 root=/dev/ram0 rw console="
>>> We would need to parameterize ramdisk_size.
>> I am hoping that this initial patch will satisfy most needs.  I agree 
>> that changes may need to be made as needs become more specific.
>>>
>>> -- 
>>> Darren
>>>
>>>> +
>>>> +IMAGE_CMD_elf () {
>>>> +    test -f ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.elf&&  rm -f 
>>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.elf
>>>> +    mkelfImage --kernel=${ELF_KERNEL} 
>>>> --initrd=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz 
>>>> --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.elf 
>>>> --append='${ELF_APPEND}' ${EXTRA_IMAGECMD}
>>>> +}
>>>> +
>>>>   UBI_VOLNAME ?= "${MACHINE}-rootfs"
>>>>
>>>>   IMAGE_CMD_ubi () {
>>>> @@ -199,6 +213,7 @@ EXTRA_IMAGECMD_ext2 ?= "-i 8192"
>>>>   EXTRA_IMAGECMD_ext3 ?= "-i 8192"
>>>>   EXTRA_IMAGECMD_ext4 ?= "-i 8192"
>>>>   EXTRA_IMAGECMD_btrfs ?= ""
>>>> +EXTRA_IMAGECMD_elf ?= ""
>>>>
>>>>   IMAGE_DEPENDS = ""
>>>>   IMAGE_DEPENDS_jffs2 = "mtd-utils-native"
>>>> @@ -210,11 +225,12 @@ IMAGE_DEPENDS_ext4 = "genext2fs-native 
>>>> e2fsprogs-native"
>>>>   IMAGE_DEPENDS_btrfs = "btrfs-tools-native"
>>>>   IMAGE_DEPENDS_squashfs = "squashfs-tools-native"
>>>>   IMAGE_DEPENDS_squashfs-lzma = "squashfs-lzma-tools-native"
>>>> +IMAGE_DEPENDS_elf = "virtual/kernel mkelfimage-native"
>>>>   IMAGE_DEPENDS_ubi = "mtd-utils-native"
>>>>   IMAGE_DEPENDS_ubifs = "mtd-utils-native"
>>>>
>>>>   # This variable is available to request which values are suitable 
>>>> for IMAGE_FSTYPES
>>>> -IMAGE_TYPES = "jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 
>>>> ext3.gz ext2.lzma btrfs live squashfs squashfs-lzma ubi tar tar.gz 
>>>> tar.bz2 tar.xz cpio cpio.gz cpio.xz cpio.lzma vmdk"
>>>> +IMAGE_TYPES = "jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 
>>>> ext3.gz ext2.lzma btrfs live squashfs squashfs-lzma ubi tar tar.gz 
>>>> tar.bz2 tar.xz cpio cpio.gz cpio.xz cpio.lzma vmdk elf"
>>>>
>>>>   COMPRESSIONTYPES = "gz bz2 lzma xz"
>>>>   COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}"
>>>>
>>
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel






More information about the Openembedded-core mailing list