[oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[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

[meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[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

Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[Bruce Ashfield]

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

Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[Koen Kooi]

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.

Re: [OE-core] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[Koen Kooi]

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.

Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[Bruce Ashfield]

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"

Re: [oe] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[Khem Raj]

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

Re: [OE-core] [meta-oe][PATCH] kernel bbclass: recreate uImage unless KEEPUIMAGE is set

[Khem Raj]

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