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

[Robert P. J. Day]

On Wed, 15 Mar 2017, Belisko Marek wrote:

> On Tue, Mar 14, 2017 at 9:53 PM, Robert P. J. Day <rpjday at crashcourse.ca> 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 at crashcourse.ca> 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
========================================================================