* [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set @ 2012-04-27 8:06 ` Koen Kooi 0 siblings, 0 replies; 8+ messages in thread From: Koen Kooi @ 2012-04-27 8:06 UTC (permalink / raw) To: openembedded-devel; +Cc: Koen Kooi The intent of the uImage code in this class includes the following 1) be able to specify custom load addresses without needing to patch the kernel 2) add better information to the uImage description field The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. Signed-off-by: Koen Kooi <koen@dominion.thruhere.net> --- meta-oe/classes/kernel.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass index b7e9f54..98320fe 100644 --- a/meta-oe/classes/kernel.bbclass +++ b/meta-oe/classes/kernel.bbclass @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" do_uboot_mkimage() { if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then - if test ! -e arch/${ARCH}/boot/uImage ; then + if test "x${KEEPUIMAGE}" = "x" ; then ENTRYPOINT=${UBOOT_ENTRYPOINT} if test -n "${UBOOT_ENTRYSYMBOL}"; then ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \ -- 1.7.10 _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set @ 2012-04-27 8:06 ` Koen Kooi 0 siblings, 0 replies; 8+ messages in thread From: Koen Kooi @ 2012-04-27 8:06 UTC (permalink / raw) To: openembedded-devel; +Cc: Koen Kooi The intent of the uImage code in this class includes the following 1) be able to specify custom load addresses without needing to patch the kernel 2) add better information to the uImage description field The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. Signed-off-by: Koen Kooi <koen@dominion.thruhere.net> --- meta-oe/classes/kernel.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass index b7e9f54..98320fe 100644 --- a/meta-oe/classes/kernel.bbclass +++ b/meta-oe/classes/kernel.bbclass @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" do_uboot_mkimage() { if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then - if test ! -e arch/${ARCH}/boot/uImage ; then + if test "x${KEEPUIMAGE}" = "x" ; then ENTRYPOINT=${UBOOT_ENTRYPOINT} if test -n "${UBOOT_ENTRYSYMBOL}"; then ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \ -- 1.7.10 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set 2012-04-27 8:06 ` Koen Kooi (?) @ 2012-04-28 14:32 ` Bruce Ashfield 2012-04-28 14:57 ` [OE-core] " Koen Kooi -1 siblings, 1 reply; 8+ messages in thread From: Bruce Ashfield @ 2012-04-28 14:32 UTC (permalink / raw) To: openembedded-devel, Patches and discussions about the oe-core layer Cc: Koen Kooi, Koen Kooi On 12-04-27 4:06 AM, Koen Kooi wrote: > The intent of the uImage code in this class includes the following > > 1) be able to specify custom load addresses without needing to patch the kernel > 2) add better information to the uImage description field > > The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. > > Signed-off-by: Koen Kooi<koen@dominion.thruhere.net> > --- > meta-oe/classes/kernel.bbclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass > index b7e9f54..98320fe 100644 > --- a/meta-oe/classes/kernel.bbclass > +++ b/meta-oe/classes/kernel.bbclass > @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" > > do_uboot_mkimage() { > if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then > - if test ! -e arch/${ARCH}/boot/uImage ; then > + if test "x${KEEPUIMAGE}" = "x" ; then I realize this is targeted meta-oe, and not directly to oe-core (but openembedded-core is cc'd + it's Saturday morning with no coffee here yet which means I may be misreading) .. so I thought I'd comment as this whizzed past. The existing users on top of the oe-core class expect (whether they know it or not) the opposite of this (i.e. do nothing, get the kernel's uImage). To keep their old behaviour, they now need to explicitly set a flag. I know that I'd have quite a few layers to update if this went directly into oe-core. How are the current meta-oe and related BSPs currently overriding the behaviour (I didn't go look, I'm invoking my Saturday morning clause again :) ? Is it a class override ? If so, can the layers that currently have an override set a flag (which is a simpler override) to get the behaviour they used to have, while leaving the boards with no override the behaviour that they used to have ? Cheers, Bruce > ENTRYPOINT=${UBOOT_ENTRYPOINT} > if test -n "${UBOOT_ENTRYSYMBOL}"; then > ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set 2012-04-28 14:32 ` [oe] " Bruce Ashfield @ 2012-04-28 14:57 ` Koen Kooi 0 siblings, 0 replies; 8+ messages in thread From: Koen Kooi @ 2012-04-28 14:57 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel Op 28 apr. 2012, om 16:32 heeft Bruce Ashfield het volgende geschreven: > On 12-04-27 4:06 AM, Koen Kooi wrote: >> The intent of the uImage code in this class includes the following >> >> 1) be able to specify custom load addresses without needing to patch the kernel >> 2) add better information to the uImage description field >> >> The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. >> >> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net> >> --- >> meta-oe/classes/kernel.bbclass | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass >> index b7e9f54..98320fe 100644 >> --- a/meta-oe/classes/kernel.bbclass >> +++ b/meta-oe/classes/kernel.bbclass >> @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" >> >> do_uboot_mkimage() { >> if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then >> - if test ! -e arch/${ARCH}/boot/uImage ; then >> + if test "x${KEEPUIMAGE}" = "x" ; then > > I realize this is targeted meta-oe, and not directly to oe-core (but > openembedded-core is cc'd + it's Saturday morning with no coffee here > yet which means I may be misreading) .. so I thought I'd comment as > this whizzed past. > > The existing users on top of the oe-core class expect (whether they > know it or not) the opposite of this (i.e. do nothing, get the kernel's > uImage). To keep their old behaviour, they now need to explicitly set a > flag. I know that I'd have quite a few layers to update if this went > directly into oe-core. > > How are the current meta-oe and related BSPs currently overriding > the behaviour (I didn't go look, I'm invoking my Saturday morning clause > again :) ? Is it a class override ? If so, can the layers that > currently have an override set a flag (which is a simpler override) to > get the behaviour they used to have, while leaving the boards with no > override the behaviour that they used to have ? "used to have" is quite vague, since the OE-classic behaviour is to always replace the uImage. And that's where I'm migrating machines from. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set @ 2012-04-28 14:57 ` Koen Kooi 0 siblings, 0 replies; 8+ messages in thread From: Koen Kooi @ 2012-04-28 14:57 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel Op 28 apr. 2012, om 16:32 heeft Bruce Ashfield het volgende geschreven: > On 12-04-27 4:06 AM, Koen Kooi wrote: >> The intent of the uImage code in this class includes the following >> >> 1) be able to specify custom load addresses without needing to patch the kernel >> 2) add better information to the uImage description field >> >> The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. >> >> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net> >> --- >> meta-oe/classes/kernel.bbclass | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass >> index b7e9f54..98320fe 100644 >> --- a/meta-oe/classes/kernel.bbclass >> +++ b/meta-oe/classes/kernel.bbclass >> @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" >> >> do_uboot_mkimage() { >> if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then >> - if test ! -e arch/${ARCH}/boot/uImage ; then >> + if test "x${KEEPUIMAGE}" = "x" ; then > > I realize this is targeted meta-oe, and not directly to oe-core (but > openembedded-core is cc'd + it's Saturday morning with no coffee here > yet which means I may be misreading) .. so I thought I'd comment as > this whizzed past. > > The existing users on top of the oe-core class expect (whether they > know it or not) the opposite of this (i.e. do nothing, get the kernel's > uImage). To keep their old behaviour, they now need to explicitly set a > flag. I know that I'd have quite a few layers to update if this went > directly into oe-core. > > How are the current meta-oe and related BSPs currently overriding > the behaviour (I didn't go look, I'm invoking my Saturday morning clause > again :) ? Is it a class override ? If so, can the layers that > currently have an override set a flag (which is a simpler override) to > get the behaviour they used to have, while leaving the boards with no > override the behaviour that they used to have ? "used to have" is quite vague, since the OE-classic behaviour is to always replace the uImage. And that's where I'm migrating machines from. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set 2012-04-28 14:57 ` [OE-core] " Koen Kooi (?) @ 2012-04-28 15:05 ` Bruce Ashfield 2012-04-28 22:34 ` [OE-core] " Khem Raj -1 siblings, 1 reply; 8+ messages in thread From: Bruce Ashfield @ 2012-04-28 15:05 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel On Sat, Apr 28, 2012 at 10:57 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > > Op 28 apr. 2012, om 16:32 heeft Bruce Ashfield het volgende geschreven: > >> On 12-04-27 4:06 AM, Koen Kooi wrote: >>> The intent of the uImage code in this class includes the following >>> >>> 1) be able to specify custom load addresses without needing to patch the kernel >>> 2) add better information to the uImage description field >>> >>> The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. >>> >>> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net> >>> --- >>> meta-oe/classes/kernel.bbclass | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass >>> index b7e9f54..98320fe 100644 >>> --- a/meta-oe/classes/kernel.bbclass >>> +++ b/meta-oe/classes/kernel.bbclass >>> @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" >>> >>> do_uboot_mkimage() { >>> if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then >>> - if test ! -e arch/${ARCH}/boot/uImage ; then >>> + if test "x${KEEPUIMAGE}" = "x" ; then >> >> I realize this is targeted meta-oe, and not directly to oe-core (but >> openembedded-core is cc'd + it's Saturday morning with no coffee here >> yet which means I may be misreading) .. so I thought I'd comment as >> this whizzed past. >> >> The existing users on top of the oe-core class expect (whether they >> know it or not) the opposite of this (i.e. do nothing, get the kernel's >> uImage). To keep their old behaviour, they now need to explicitly set a >> flag. I know that I'd have quite a few layers to update if this went >> directly into oe-core. >> >> How are the current meta-oe and related BSPs currently overriding >> the behaviour (I didn't go look, I'm invoking my Saturday morning clause >> again :) ? Is it a class override ? If so, can the layers that >> currently have an override set a flag (which is a simpler override) to >> get the behaviour they used to have, while leaving the boards with no >> override the behaviour that they used to have ? > > "used to have" is quite vague, since the OE-classic behaviour is to always replace the uImage. And that's where I'm migrating machines from. That's why I referenced oe-core, that's all I'm talking about. It's behaviour for every tagged release has been what I'm talking about. This is a change in that behaviour, and if that's the intended target for this, it is relevant. Cheers, Bruce > > > > _______________________________________________ > 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" ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set 2012-04-28 15:05 ` [oe] " Bruce Ashfield @ 2012-04-28 22:34 ` Khem Raj 0 siblings, 0 replies; 8+ messages in thread From: Khem Raj @ 2012-04-28 22:34 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel On Sat, Apr 28, 2012 at 8:05 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > On Sat, Apr 28, 2012 at 10:57 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> >> Op 28 apr. 2012, om 16:32 heeft Bruce Ashfield het volgende geschreven: >> >>> On 12-04-27 4:06 AM, Koen Kooi wrote: >>>> The intent of the uImage code in this class includes the following >>>> >>>> 1) be able to specify custom load addresses without needing to patch the kernel >>>> 2) add better information to the uImage description field >>>> >>>> The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. >>>> >>>> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net> >>>> --- >>>> meta-oe/classes/kernel.bbclass | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass >>>> index b7e9f54..98320fe 100644 >>>> --- a/meta-oe/classes/kernel.bbclass >>>> +++ b/meta-oe/classes/kernel.bbclass >>>> @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" >>>> >>>> do_uboot_mkimage() { >>>> if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then >>>> - if test ! -e arch/${ARCH}/boot/uImage ; then >>>> + if test "x${KEEPUIMAGE}" = "x" ; then >>> >>> I realize this is targeted meta-oe, and not directly to oe-core (but >>> openembedded-core is cc'd + it's Saturday morning with no coffee here >>> yet which means I may be misreading) .. so I thought I'd comment as >>> this whizzed past. >>> >>> The existing users on top of the oe-core class expect (whether they >>> know it or not) the opposite of this (i.e. do nothing, get the kernel's >>> uImage). To keep their old behaviour, they now need to explicitly set a >>> flag. I know that I'd have quite a few layers to update if this went >>> directly into oe-core. >>> >>> How are the current meta-oe and related BSPs currently overriding >>> the behaviour (I didn't go look, I'm invoking my Saturday morning clause >>> again :) ? Is it a class override ? If so, can the layers that >>> currently have an override set a flag (which is a simpler override) to >>> get the behaviour they used to have, while leaving the boards with no >>> override the behaviour that they used to have ? >> >> "used to have" is quite vague, since the OE-classic behaviour is to always replace the uImage. And that's where I'm migrating machines from. > > That's why I referenced oe-core, that's all I'm talking about. It's > behaviour for > every tagged release has been what I'm talking about. This is a change in > that behaviour, and if that's the intended target for this, it is relevant. > I think keeping OE-Core's behavior and introducing a variable (REDO_UIMAGE_BECAUSE_KERNEL_BUILT_UIMAGE_IS_CRAP_FOR_MY_MACHINE or something) to indicate regenerate my uImage might be a better compromise here. > Cheers, > > Bruce > >> >> >> >> _______________________________________________ >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set @ 2012-04-28 22:34 ` Khem Raj 0 siblings, 0 replies; 8+ messages in thread From: Khem Raj @ 2012-04-28 22:34 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel On Sat, Apr 28, 2012 at 8:05 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > On Sat, Apr 28, 2012 at 10:57 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> >> Op 28 apr. 2012, om 16:32 heeft Bruce Ashfield het volgende geschreven: >> >>> On 12-04-27 4:06 AM, Koen Kooi wrote: >>>> The intent of the uImage code in this class includes the following >>>> >>>> 1) be able to specify custom load addresses without needing to patch the kernel >>>> 2) add better information to the uImage description field >>>> >>>> The current state is a NOP anyway, the kernel will always build a uImage when you tell it to 'make uImage'. >>>> >>>> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net> >>>> --- >>>> meta-oe/classes/kernel.bbclass | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/meta-oe/classes/kernel.bbclass b/meta-oe/classes/kernel.bbclass >>>> index b7e9f54..98320fe 100644 >>>> --- a/meta-oe/classes/kernel.bbclass >>>> +++ b/meta-oe/classes/kernel.bbclass >>>> @@ -512,7 +512,7 @@ KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}" >>>> >>>> do_uboot_mkimage() { >>>> if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then >>>> - if test ! -e arch/${ARCH}/boot/uImage ; then >>>> + if test "x${KEEPUIMAGE}" = "x" ; then >>> >>> I realize this is targeted meta-oe, and not directly to oe-core (but >>> openembedded-core is cc'd + it's Saturday morning with no coffee here >>> yet which means I may be misreading) .. so I thought I'd comment as >>> this whizzed past. >>> >>> The existing users on top of the oe-core class expect (whether they >>> know it or not) the opposite of this (i.e. do nothing, get the kernel's >>> uImage). To keep their old behaviour, they now need to explicitly set a >>> flag. I know that I'd have quite a few layers to update if this went >>> directly into oe-core. >>> >>> How are the current meta-oe and related BSPs currently overriding >>> the behaviour (I didn't go look, I'm invoking my Saturday morning clause >>> again :) ? Is it a class override ? If so, can the layers that >>> currently have an override set a flag (which is a simpler override) to >>> get the behaviour they used to have, while leaving the boards with no >>> override the behaviour that they used to have ? >> >> "used to have" is quite vague, since the OE-classic behaviour is to always replace the uImage. And that's where I'm migrating machines from. > > That's why I referenced oe-core, that's all I'm talking about. It's > behaviour for > every tagged release has been what I'm talking about. This is a change in > that behaviour, and if that's the intended target for this, it is relevant. > I think keeping OE-Core's behavior and introducing a variable (REDO_UIMAGE_BECAUSE_KERNEL_BUILT_UIMAGE_IS_CRAP_FOR_MY_MACHINE or something) to indicate regenerate my uImage might be a better compromise here. > Cheers, > > Bruce > >> >> >> >> _______________________________________________ >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-04-28 22:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-27 8:06 [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set Koen Kooi 2012-04-27 8:06 ` Koen Kooi 2012-04-28 14:32 ` [oe] " Bruce Ashfield 2012-04-28 14:57 ` Koen Kooi 2012-04-28 14:57 ` [OE-core] " Koen Kooi 2012-04-28 15:05 ` [oe] " Bruce Ashfield 2012-04-28 22:34 ` Khem Raj 2012-04-28 22:34 ` [OE-core] " Khem Raj
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.