On Tue, Mar 28, 2017 at 7:19 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote: > > playing with building fit images, and i started with mpc8315e-rdb, > built virtual/kernel using all defaults, and got this in images/: > > modules--4.9.8+git0+b65e9b6153_6b67f448d6-r0-mpc8315e-rdb-20170315095945.tgz > uImage--4.9.8+git0+b65e9b6153_6b67f448d6-r0-mpc8315e-rdb-20170315095945.bin > uImage--4.9.8+git0+b65e9b6153_6b67f448d6-r0-mpc8315erdb-20170315095945.dtb > > which is perfectly fine, since the machine conf file for that target > includes the line: > > KERNEL_IMAGETYPE = "uImage" > > now i start another (fresh) build, and add to local.conf the lines: > > KERNEL_CLASSES = "kernel-fitimage" > KERNEL_IMAGETYPES = "fitImage" > > now my use of the above is my (alleged) way of saying, "i only want a > fitImage", but given this snippet from kernel.bbclass: > > # Merge KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES > type = d.getVar('KERNEL_IMAGETYPE') or "" > alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or "" > types = d.getVar('KERNEL_IMAGETYPES') or "" > if type not in types.split(): > types = (type + ' ' + types).strip() > > i apparently get both the default as specified in the machine .conf > file, *as well as* the fitImage i ask for. and, sure enough, in my > images/ directory, i have uImages and fitImages (and zImages, but i > believe that's because fitImages require them, so no big deal). > > i suspect i could prevent the generation of uImages by using: > > KERNEL_IMAGETYPE_mpc8315e-rdb = "fitImage" > > but from a clarity point of view, would it not make more sense that if > someone had a line: > > KERNEL_IMAGETYPES = " ... list of types ..." > > that should override whatever KERNEL_IMAGETYPE is in the machine conf > file and generate *just* those images? or am i missing something here?
KERNEL_IMAGETYPE is the legacy variable and it's added to KERNEL_IMAGETYPES for backwards compatibility. If you update your machine config and local.conf over-rides etc to all consistently use KERNEL_IMAGETYPES then the behaviour should be closer to what you expect. > rday > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core