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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox