All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefano Babic" <sbabic@denx.de>
To: Vladimir Motyka <vladimir.motyka@kistler.com>,
	"yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>
Subject: Re: [yocto] Building FIT images with different initramfs images
Date: Tue, 24 Mar 2020 12:53:49 +0100	[thread overview]
Message-ID: <76da1b39-7e96-c7ec-ef30-21b7d2b6ccba@denx.de> (raw)
In-Reply-To: <cfa2c0f18911496e8d3ebb61287a0e81@kistler.com>

Hi Vladimir,

On 24.03.20 11:00, Vladimir Motyka wrote:
> Hello,
> 
> I want to ask if there is some best practice or recommendation on how to build multiple FIT images with different initramfs image. We need more FIT images with a different set of packages to support different use cases(development image, production test image, etc.).
> 
> As the INITRAMFS_IMAGE variable is set in the machine configuration, we defined more machines with different INITRAMFS_IMAGE value. I think this is abusing of machine configuration.
> 
> I found a similar question here on the mailing list (https://www.yoctoproject.org/pipermail/yocto/2017-August/037676.html), where Christian describes his solution - adjusting kernel.bbclass and kernel-fitimage.bbclass and creating a new variable INITRAMFS_IMAGES. However, it wasn't integrated into YP.
> 
> To summarize, is there a better/recommended solution for building multiple FIT images with different initramfs image, then abusing the MACHINE configuration, or adjusting kernel.bbclass and kernel-fitimage.bbclass by myself?
> 

I do not know if there is a best practise - but I do not like to extend
kernel classes as described above. IMHO the ramdisk does not belong to
MACHINE. I can build several images, and I would like that some of them
are put into a fit container. The kernel-fitimage class fits a very
common use case and generates the .its file (the description of fitIMage
used by mkimage), too, but it cannot fit all possible use cases: I have
often to put into a fitImage other components, like FPGA bitstreams,
splash images, multiple DTs and further configuration.

I see and I use fitImage as a container for an image class, that means
not bound to MACHINE. So in my image recipe (where I generate the
Ramdisk), I add a task that uses a fetched "its" file to generate the
resulting fitImage.

Somethink like:


SRC_URI = " my-fit.its"

do_prepareitb() {
     < further compression, and so on>

      mkimage -f ${WORKDIR}/my-fit.its ${WORKDIR}/${PN}-${MACHINE}.itb

}

addtask prepareitb before do_build after do_image_complete

Maybe someone else has solved in a different way..

Best regards,
Stefano Babic




-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

      reply	other threads:[~2020-03-24 11:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 10:00 Building FIT images with different initramfs images vladimir.motyka
2020-03-24 11:53 ` Stefano Babic [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76da1b39-7e96-c7ec-ef30-21b7d2b6ccba@denx.de \
    --to=sbabic@denx.de \
    --cc=vladimir.motyka@kistler.com \
    --cc=yocto@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.