[OE-core] [PATCH 1/5] kernel.bbclass: move uImage handling to separate task

Bruce Ashfield bruce.ashfield at gmail.com
Mon Dec 19 05:23:19 UTC 2011


On Mon, Dec 19, 2011 at 12:06 AM, Khem Raj <raj.khem at gmail.com> wrote:
> On Sun, Dec 18, 2011 at 5:39 PM, Bruce Ashfield
> <bruce.ashfield at gmail.com> wrote:
>> On Sun, Dec 18, 2011 at 4:19 PM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>>>
>>> Op 18 dec. 2011, om 21:27 heeft Bruce Ashfield het volgende geschreven:
>>>
>>>> On Sun, Dec 18, 2011 at 3:13 PM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>>>>>
>>>>> Op 18 dec. 2011, om 20:47 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.
>>>>>
>>>>> I still don't agree with that behaviour. The in-kernel uImage code is just like the in-kernel defconfigs: useless for people who aren't kernel developers.
>>>>
>>>> In that case, shouldn't people doing u-boot development (or other
>>>> non-kernel developers),
>>>> be building a uImage via something that isn't in kernel.bbclass ?
>>>
>
> i think we have UBOOT_ENTRYPOINT, UBOOT_ENTRYSYMBOL and
> UBOOT_LOADADDRESS which are then used to generate the uImage
> and sometimes defaults from kernel build system may not be usable as
> it might be generating the image using some other values and we are not
> able to control the image generation. Now is that fixable in kernel I guess
> it could be but why not have flexibility of generating the image.

I'm all for flexibility (see my comments earlier in the thread), have a variable
or some other construct that specifies how you'd like to construct the uImage
(kernel vs non-kernel, as a basic attempt to differentiate the two).

I'm just driving for the details to see if we can remedy the situation in the
medium to long term, since burying the details of how to construct any sort
of image in multiple places .. is not ideal (but I state the obvious).

Cheers,

Bruce

>
>>> I use the kernel.bbclass in meta-oe, that does what I need.
>>
>
> _______________________________________________
> 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