On Wed, 15 Mar 2017, Belisko Marek wrote:

On Tue, Mar 14, 2017 at 9:53 PM, Robert P. J. Day <rpjday@...> wrote:

On Tue, 14 Mar 2017, Belisko Marek wrote:

Hi Robert,

On Tue, Mar 14, 2017 at 9:16 PM, Robert P. J. Day <rpjday@...> wrote:

On Mon, 13 Mar 2017, Robert P. J. Day wrote:

i'll start a new thread to focus on just this issue. again, building
core-image-minimal for mpc8315e-rdb, adding this to local.conf:

INHERIT += "kernel-fitimage" <-- do i need this line?
KERNEL_IMAGETYPES_append = " fitImage"

anyway, run:

$ bitbake virtual/kernel

and eventually get:

make[2]: *** No rule to make target 'fitImage'. Stop.

... snip ...

i would still love to figure out how to generate a simple FIT image
when building core-image-minimal for mpc8315e-rdb.

first, based on what i read, my first attempt was to add the
following line to local.conf:

KERNEL_IMAGETYPES_append = " fitImage"

You need probably also add:

KERNEL_CLASSES += "kernel-fitimage"

to local.conf

that *appears* to have solved the problem ... so why is it i didn't
realize that? where is that written up that i somehow missed it?

It is not documented in yocto manual (I cannot find anything about
fitimage at all), so maybe it could be extended.

i'll check later to see where it would seem to belong, unless
someone has a suggestion.

and would it not make sense that selecting FIT image in one
variable should automatically set the other required variables?

I think something like that can be doable and it will save a lot of
time for people who want's to have it enabled.

actually, i take back that suggestion, as i think it would overly
complicate kernel.bbclass (at least the way i read it).

i can see that, for backward compatibility, kernel.bbclass contains
the following:

# Here we pull in all various kernel image types which we support.
#
# In case you're wondering why kernel.bbclass inherits the other image
# types instead of the other way around, the reason for that is to
# maintain compatibility with various currently existing meta-layers.
# By pulling in the various kernel image types here, we retain the
# original behavior of kernel.bbclass, so no meta-layers should get
# broken.
#
# KERNEL_CLASSES by default pulls in kernel-uimage.bbclass, since this
# used to be the default behavior when only uImage was supported. This
# variable can be appended by users who implement support for new kernel
# image types.

KERNEL_CLASSES ?= " kernel-uimage "
inherit ${KERNEL_CLASSES}

so it's quite simple to extend the set of .bbclass files that provide
new kernel image types with, say:

KERNEL_CLASSES += "kernel-fitimage"

beyond that, however, since a new kernel class file might define a
*pile* of new kernel image types, poor kernel.bbclass would need to
recognize all of them and know which kernel class file to inherit for
each new kernel type, which seems unwieldy.

so as long as how to define new kernel image types is explained
clerly (is it?), then a discussion of FIT images should simply need to
refer the reader to that section.

thoughts?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================