Re: [OE-core] [PATCH 2/9] kernel.bbclass: move uImage handling to separate task

2011-12-15 Thread Bruce Ashfield 
On Thu, Dec 15, 2011 at 1:23 AM, Dmitry Eremin-Solenikov
dbarysh...@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-Solenikovdbarysh...@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

Re: [OE-core] [PATCH 2/9] kernel.bbclass: move uImage handling to separate task

2011-12-15 Thread Bruce Ashfield 
On Thu, Dec 15, 2011 at 2:09 PM, Tom Rini tom.r...@gmail.com wrote:
 On Thu, Dec 15, 2011 at 6:55 AM, Bruce Ashfield
 bruce.ashfi...@gmail.com wrote:
 [snip]
 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.

 Part of the history[1], and I was surprised at the time too, was that
 for ARM at least, rmk had said that you should not use the uImages
 generated by the kernel.  So the question is, has this changed?  Is
 this an ARM-only thing?'

I've been booting uImages generated by the kernel on ARM boards since nearly
2008. So it may be more of a per-board thing now .. or something else entirely.

Cheers,

Bruce


 [1]: 
 http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-November/007096.html

 --
 Tom

 ___
 Openembedded-core mailing list
 Openembedded-core@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

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/9] kernel.bbclass: move uImage handling to separate task

2011-12-14 Thread Koen Kooi 

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)

 . 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

 
 Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@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@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/9] kernel.bbclass: move uImage handling to separate task

2011-12-14 Thread Dmitry Eremin-Solenikov 

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?


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-Solenikovdbarysh...@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