[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