[OE-core] [PATCH 2/9] kernel.bbclass: move uImage handling to separate task
Bruce Ashfield
bruce.ashfield at gmail.com
Thu Dec 15 13:55:50 UTC 2011
On Thu, Dec 15, 2011 at 1:23 AM, Dmitry Eremin-Solenikov
<dbaryshkov at gmail.com> wrote:
> On 12/15/2011 01:20 AM, Koen Kooi wrote:
>>
>>
>> Op 13 dec. 2011, om 16:19 heeft Dmitry Eremin-Solenikov het volgende
>> geschreven:
>>
>>> As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
>>> separate task from do_deploy. This way the do_install task can also
>>> benefit from generated uImage.
>>>
>>> The only major feature of oe-core's version (not to recreate uImage
>>> if it exists) is retained in this patch
>>
>>
>> The whole point of the OE uImage handling is that in general we know
>> better than the kernel and can apply fixups if needed (turning on/off
>> compression, etc)
>
>
> Please check the history of OE-core uImage handling. Initially uImage was
> always recreated (as it's currently done in meta-oe). Then (422a017e6 on Oct
> 29, 2010) OE-core kernel.bbclass was changed to default to not to recreate
> uImage if it was created by kbuild (IIRC it was done so, because recreated
> uImages weren't always booting as they required more setup). I don't know
> which way is correct. Maybe we should add a hook that will tell if
> kernel.bbclass should prefer to recreate uImage or to use kernel one. Would
> you like such variable?
If no one minds the tiny bit of extra complexity, this was the approach that I
was thinking about when reading this thread.
I can report for fact, that the uImages that were being generated by
the existing
rules were binary blobs of silent boot death on the powerpc boards that I was
using during initial development. The in tree images worked perfectly.
For everything I've done in the past, I've always used in tree uImages
or patched the
kernel tree itself to generated images that worked for the board in question.
The difference in approach could likely be chalked up to a guy just
trying to get a
kernel to boot, and someone working more closely with the bootloader -> kernel
handoff.
I think a variable, or some other switch, to support the two workflows
is a reasonable
compromise.
Cheers,
Bruce
>
> Another point (that I probably failed to emphasize): currently do_install
> and do_deploy will use different uImages. The image in /boot on rootfs might
> be different from uImage really in deploy dir. I would assume that this is
> not the expected way to do things.
>
>
>>
>>> . On the contra, as this version
>>> was merged from meta-oe/org.oe.dev, new function has another feature:
>>> it permits overriding the u-boot entrypoint via u-boot symbol.
>>
>>
>> Not if uimage exists, see above
>
>
> Of course.
>
>
>>
>>>
>>> Signed-off-by: Dmitry Eremin-Solenikov<dbaryshkov at gmail.com>
>>> ---
>>> meta/classes/kernel.bbclass | 40
>>> ++++++++++++++++++++++++----------------
>>> 1 files changed, 24 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>> index a75c199..db00d2d 100644
>>> --- a/meta/classes/kernel.bbclass
>>> +++ b/meta/classes/kernel.bbclass
>>> @@ -485,6 +485,30 @@ do_sizecheck() {
>>>
>>> addtask sizecheck before do_install after do_compile
>>>
>>> +do_uboot_mkimage() {
>>> + if test "x${KERNEL_IMAGETYPE}" = "xuImage" -a \
>>> + ! -e arch/${ARCH}/boot/uImage ; then
>>> + ENTRYPOINT=${UBOOT_ENTRYPOINT}
>>> + if test -n "${UBOOT_ENTRYSYMBOL}"; then
>>> + ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
>>> + awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
>>> + fi
>>> + if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
>>> + ${OBJCOPY} -O binary -R .note -R .comment -S
>>> arch/${ARCH}/boot/compressed/vmlinux linux.bin
>>> + uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a
>>> ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d
>>> linux.bin arch/${ARCH}/boot/uImage
>>> + rm -f linux.bin
>>> + else
>>> + ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux
>>> linux.bin
>>> + rm -f linux.bin.gz
>>> + gzip -9 linux.bin
>>> + uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a
>>> ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d
>>> linux.bin.gz arch/${ARCH}/boot/uImage
>>> + rm -f linux.bin.gz
>>> + fi
>>> + fi
>>> +}
>>> +
>>> +addtask uboot_mkimage before do_install after do_compile
>>> +
>>> KERNEL_IMAGE_BASE_NAME ?=
>>> "${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
>>> # Don't include the DATETIME variable in the sstate package signatures
>>> KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
>>> @@ -496,22 +520,6 @@ kernel_do_deploy() {
>>> tar -cvzf
>>> ${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
>>> fi
>>>
>>> - if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
>>> - if test -e arch/${ARCH}/boot/uImage ; then
>>> - cp arch/${ARCH}/boot/uImage
>>> ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>>> - elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
>>> - ${OBJCOPY} -O binary -R .note -R .comment -S
>>> arch/${ARCH}/boot/compressed/vmlinux linux.bin
>>> - uboot-mkimage -A ${ARCH} -O linux -T kernel -C
>>> none -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n
>>> "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin
>>> ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>>> - rm -f linux.bin
>>> - else
>>> - ${OBJCOPY} -O binary -R .note -R .comment -S
>>> vmlinux linux.bin
>>> - rm -f linux.bin.gz
>>> - gzip -9 linux.bin
>>> - uboot-mkimage -A ${ARCH} -O linux -T kernel -C
>>> gzip -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n
>>> "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz
>>> ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>>> - rm -f linux.bin.gz
>>> - fi
>>> - fi
>>> -
>>> cd ${DEPLOYDIR}
>>> rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
>>> ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin
>>> ${KERNEL_IMAGE_SYMLINK_NAME}.bin
>>> --
>>> 1.7.7.3
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
> --
> With best wishes
> Dmitry
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
More information about the Openembedded-core
mailing list