On Tuesday, April 28, 2015 at 08:43:48 PM, Bruce Ashfield wrote: > On 2015-04-28 12:38 PM, Marek Vasut wrote: > > Build the uImage file using the kernel build system only when > > it is really required, which is only in case KEEPUIMAGE == yes. > > Otherwise, just build zImage, since the Yocto build system will > > handle the uImage generation for us. > > > > Signed-off-by: Marek Vasut <ma...@denx.de> > > Cc: Richard Purdie <richard.pur...@linuxfoundation.org> > > Cc: Koen Kooi <k...@dominion.thruhere.net> > > Cc: Paul Eggleton <paul.eggle...@linux.intel.com> > > Cc: Ross Burton <ross.bur...@intel.com> > > Cc: Bruce Ashfield <bruce.ashfi...@windriver.com> > > --- > > > > meta/classes/kernel-uimage.bbclass | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/meta/classes/kernel-uimage.bbclass > > b/meta/classes/kernel-uimage.bbclass index ce8f96f..acde9ae 100644 > > --- a/meta/classes/kernel-uimage.bbclass > > +++ b/meta/classes/kernel-uimage.bbclass > > @@ -6,6 +6,14 @@ python __anonymous () { > > > > depends = d.getVar("DEPENDS", True) > > depends = "%s u-boot-mkimage-native" % depends > > d.setVar("DEPENDS", depends) > > > > + > > + # Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal > > + # to kernel.bbclass . We override the variable here, since we need > > + # to build uImage using the kernel build system if and only if > > + # KEEPUIMAGE != yes. Otherwise, we pack compressed vmlinux into > > + # the uImage . > > I keep reading this, and must be inverting the logic in my head. > > If we've set KEEPUIMAGE = yes, that means we just want to let the > kernel build the uImage and perform no extra generation steps. > > When I read this, it looks like if I set the keep flag, I'll be > overriden to build a zImage. Is that intentional ? I'd think we > would have just left it alone or set it to uImage (unless we > are saying that everyone should be building zImage now .. but > I know some old ppc targets that do want to build uImages).
Uhhh, you're obviously right. The logic in the __anonymous function is clearly inverted. Thanks for spotting this! Best regards, Marek Vasut -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core