On Sat, Apr 28, 2012 at 8:05 AM, Bruce Ashfield <[email protected]> wrote: > On Sat, Apr 28, 2012 at 10:57 AM, Koen Kooi <[email protected]> > 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<[email protected]> >>>> --- >>>> 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 >> [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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
