All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <koen@dominion.kabel.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: uImage generation: kernel.bbclass vs linux.inc
Date: Fri, 28 Mar 2008 20:30:25 +0100	[thread overview]
Message-ID: <fsjh0h$6k1$1@ger.gmane.org> (raw)
In-Reply-To: <47ED3CE1.7020000@bolloretelecom.eu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Lainé schreef:
| With the recent changes to kernel.bbclass it seems that uboot-mkimage is
| called twice:
|
| linux.inc: do_compile_append()
|
| 1/ uses uboot-mkimage to generate generates arch/${ARCH}/boot/uImage

That's needed to get the correct uImage packaged, some machines have the
uImage in the rootfs (don't turn on lzo in jffs2, uboot doesn't like that).

| kernel.bbclass: do_deploy()
|
| 1/ copies arch/${ARCH}/boot/uImage to
| ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.bin
|
| 2/ does package_stagefile_shell
| ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.bin
|
| 3/ uses uboot-mkimage to generate
| ${DEPLOY_DIR_IMAGE}/uImage-${PV}-${PR}-${MACHINE}.bin
|
| This seems pretty inconsistent! Also, why the hard-coded uImage-xyz file
| name, shouldn't we be using KERNEL_IMAGE_BASE_NAME?
|
| To make things a bit more interesting, KERNEL_IMAGE_BASE_NAME is set
| differently in kernel.bbclass and linux.inc:
|
| kernel.bbclass :
| KERNEL_IMAGE_BASE_NAME =
| ${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
|
| linux.inc:
| KERNEL_IMAGE_BASE_NAME = "${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}"

Looking at how OE mananges zImages, it probably should be something like:

${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE} with a
symlink to ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}

and

/boot/${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE} with a symlink to
/boot/${KERNEL_IMAGETYPE} on the target.

That raises the question how kexec handles uImage files and how we can
make it easy for people to generate uImage for flashing and zImage for
kexecing in the same build.

DATETIME in version strings should die, we have PR for that. If the
output changed, PR should have been bumped. Lazyness is not a valid
excuse for littering my deploydir with identical files with a different
timestamp each build. Your filesystem has mtime if you really want to
see a date.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH7UdRMkyGM64RGpERArOtAJ9rVNs9JEwyjwz8fSiQv1L5OrLdBgCeJafZ
WrJMEs48LDXwh5pS/tIx+pw=
=SUZJ
-----END PGP SIGNATURE-----




  parent reply	other threads:[~2008-03-28 19:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28 18:45 uImage generation: kernel.bbclass vs linux.inc Jeremy Lainé
2008-03-28 19:06 ` Thomas Kunze
2008-03-31  8:32   ` Jeremy Lainé
2008-03-28 19:30 ` Koen Kooi [this message]
2008-03-31  9:19   ` Jeremy Lainé

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='fsjh0h$6k1$1@ger.gmane.org' \
    --to=koen@dominion.kabel.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@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.