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<[email protected]> >>>> --- >>>> 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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
