uImage generation: kernel.bbclass vs linux.inc

uImage generation: kernel.bbclass vs linux.inc

[Jeremy Lainé]

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


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

Where do we go from here?

Cheers,
Jeremy

Re: uImage generation: kernel.bbclass vs linux.inc

[Thomas Kunze]

Jeremy Lainé wrote:
>
> 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}"
>   
This one is easy:
KERNEL_IMAGE_BASE_NAME and KERNEL_IMAGE_SYMLINK_NAME should be '?=' so 
that kernel recipes can overide it.

Re: uImage generation: kernel.bbclass vs linux.inc

[Jeremy Lainé]

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


> This one is easy:
> KERNEL_IMAGE_BASE_NAME and KERNEL_IMAGE_SYMLINK_NAME should be '?=' so
> that kernel recipes can overide it.
OK, I have commited this change.

- --
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH8KGACL1n3lVB9EYRAudWAKCGMQcpozrc1mdpjLJjLi8qHQaJXACg3hdh
k5uLshIo8YT31DYD45tLIGI=
=J9/h
-----END PGP SIGNATURE-----

Re: uImage generation: kernel.bbclass vs linux.inc

[Koen Kooi]

-----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-----

Re: uImage generation: kernel.bbclass vs linux.inc

[Jeremy Lainé]

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

Koen Kooi wrote:
> 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).
>
I totally agree, the change to uImage needs to be done in time for it
to be picked up by packaging. My point is I think we should:

a/ move do_compile_append() into kernel.bbclass
b/ in do_deploy() : not run uboot-mkimage since this has already been
done during do_compile_append()

> 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.
>
OK, we will have to look into this.
> 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.
>
I agree, I have commited this change.

- --
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH8KyDCL1n3lVB9EYRAl2IAJ9sqVBp4OAgg55zzKCGuhyLk5Gq5QCfdrxB
Ghj+IYQbuVPITyMIxR3DFc4=
=r441
-----END PGP SIGNATURE-----