[oe] [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 at gmail.com> wrote:
> On Sat, Apr 28, 2012 at 10:57 AM, Koen Kooi <koen at 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 at 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 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"
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core