All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raymond Danks <ray.danks@se-eng.com>
To: Darren Hart <dvhart@linux.intel.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:34:24 -0600	[thread overview]
Message-ID: <4FEB6E50.30203@se-eng.com> (raw)
In-Reply-To: <4FE898B7.3050606@linux.intel.com>

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.
>> 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}"
>>




  reply	other threads:[~2012-06-27 20:53 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 [this message]
2012-06-27 20:43     ` Raymond Danks
2012-06-27 21:32       ` Darren Hart

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=4FEB6E50.30203@se-eng.com \
    --to=ray.danks@se-eng.com \
    --cc=dvhart@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.