All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: "Ernst Sjöstrand" <ernst.sjostrand@verisure.com>
Cc: "jneanne@baylibre.com" <jneanne@baylibre.com>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>,
	"gpain@baylibre.com" <gpain@baylibre.com>
Subject: Re: Solving a circular dependency issue between the main image and initramfs
Date: Tue, 17 Mar 2020 15:05:15 +0100	[thread overview]
Message-ID: <CAMRc=MeoV1rVZDHv03SvPL4FvAT-G7X13nSznOcH8XN3eR76Fw@mail.gmail.com> (raw)
In-Reply-To: <e9e9a9c8fc2a1895ace0e4f9d57df0b0c1f3f86b.camel@verisure.com>

pon., 16 mar 2020 o 15:03 Ernst Sjöstrand
<ernst.sjostrand@verisure.com> napisał(a):
>
> Hi!
>
> I have done something very similar, here's what I did.
>
> My ramdisk is just a vanilla cpio.
> My kernel is just vanilla zImage.
>
> My main image does "inherit magic" and magic.bbclass does something like this, where create_custom_fitimage has a lot of kernel-fitimage.bbclass copied out.
> do_magic () {
> create_custom_fitimage
> install fitImage.bin ${IMAGE_ROOTFS}/boot/fitImage
> }
> do_magic[depends] += "my-ramdisk:do_image_complete  virtual/kernel"
> addtask magic before do_image after do_pre_image_task
>
> It does read a lot of stuff from deploy but so does the main kernel-fitimage.bbclass so I don't think that's a problem.
>
> Regards
> //Ernst
>

There are probably many workarounds for this, but if we can't do this
with upstream OE-core then something is broken/missing upstream and we
should fix it. This is what I'm trying to do. I'm just looking for the
right way. I don't want to carry some non-upstreamable workaround over
to every other project I'm working on - optimally this should be made
part of OE-core/meta-security.

Best regards,
Bartosz Golaszewski


      reply	other threads:[~2020-03-17 14:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 21:23 Solving a circular dependency issue between the main image and initramfs Bartosz Golaszewski
2020-03-10 21:33 ` Ayoub Zaki
2020-03-10 22:02   ` Bartosz Golaszewski
2020-03-10 22:54     ` Ayoub Zaki
2020-03-11  8:03       ` Bartosz Golaszewski
2020-03-16 10:48 ` Bartosz Golaszewski
2020-03-16 11:01   ` Richard Purdie
2020-03-17 13:26     ` Bartosz Golaszewski
2020-03-17 13:45       ` Quentin Schulz
2020-03-17 14:12         ` Bartosz Golaszewski
2020-03-16 14:02 ` Ernst Sjöstrand
2020-03-17 14:05   ` Bartosz Golaszewski [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='CAMRc=MeoV1rVZDHv03SvPL4FvAT-G7X13nSznOcH8XN3eR76Fw@mail.gmail.com' \
    --to=brgl@bgdev.pl \
    --cc=ernst.sjostrand@verisure.com \
    --cc=gpain@baylibre.com \
    --cc=jneanne@baylibre.com \
    --cc=openembedded-core@lists.openembedded.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.