From: Darren Hart <dvhart@linux.intel.com>
To: ray.danks@se-eng.com
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/2] image_types: Add elf image type
Date: Wed, 27 Jun 2012 14:32:48 -0700 [thread overview]
Message-ID: <4FEB7C00.9040603@linux.intel.com> (raw)
In-Reply-To: <4FEB705A.3010803@se-eng.com>
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@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
prev parent reply other threads:[~2012-06-27 21:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 20:22 [PATCH 1/2] image_types: Add elf image type Raymond Danks
2012-06-22 20:22 ` [PATCH 2/2] mkelfimage: Add stable git build (initial recipe) Raymond Danks
2012-06-29 12:19 ` Richard Purdie
2012-06-29 15:32 ` Raymond Danks
2012-06-29 15:41 ` [PATCH 1/2 v2] image_types: Add elf image type Raymond Danks
2012-06-29 17:45 ` Darren Hart
2012-06-29 20:01 ` Raymond Danks
2012-06-29 15:41 ` [PATCH 2/2 v2] mkelfimage: Add stable git build (initial recipe) Raymond Danks
2012-06-29 17:47 ` Darren Hart
2012-06-29 20:03 ` Raymond Danks
2012-06-29 20:19 ` [PATCH 1/2 v3] image_types: Add elf image type Raymond Danks
2012-06-30 13:38 ` Darren Hart
2012-07-02 4:22 ` Saul Wold
2012-07-02 15:05 ` Raymond Danks
2012-07-02 16:51 ` Saul Wold
2012-07-02 19:00 ` Raymond Danks
2012-07-02 20:51 ` [PATCH 1/2 v4] " Raymond Danks
2012-07-05 17:35 ` Saul Wold
2012-06-29 20:30 ` [PATCH 2/2 v3] mkelfimage: Add stable git build (initial recipe) Raymond Danks
2012-07-08 21:34 ` [PATCH 2/2] " Saul Wold
2012-07-09 19:20 ` Raymond Danks
2012-06-25 16:58 ` [PATCH 1/2] image_types: Add elf image type Darren Hart
2012-06-27 20:34 ` Raymond Danks
2012-06-27 20:43 ` Raymond Danks
2012-06-27 21:32 ` Darren Hart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FEB7C00.9040603@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=ray.danks@se-eng.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.