On Mon, Dec 19, 2011 at 12:06 AM, Khem Raj <[email protected]> wrote: > On Sun, Dec 18, 2011 at 5:39 PM, Bruce Ashfield > <[email protected]> wrote: >> On Sun, Dec 18, 2011 at 4:19 PM, Koen Kooi <[email protected]> >> 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 <[email protected]> >>>> 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 > [email protected] > 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 [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
