public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: openembedded-core@lists.openembedded.org,
	Michelle Lin <michelle.linto91@gmail.com>,
	Erik Schilling <erik.schilling@linaro.org>
Subject: Re: [OE-core] [PATCH 2/2] uki.bbclass: add class for building Unified Kernel Images (UKI)
Date: Mon, 2 Sep 2024 16:15:21 +0300	[thread overview]
Message-ID: <ZtW6abFD67IrL28X@nuoska> (raw)
In-Reply-To: <CANNYZj-uXEDm2CuqtorwdZNABaZNPm4UtOFZvw4wMXdjhh+0ig@mail.gmail.com>

Hi,

On Mon, Sep 02, 2024 at 03:03:45PM +0200, Alexander Kanavin wrote:
> On Mon, 2 Sept 2024 at 14:25, Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
> > I've checked and I have not found matching examples. We have everything working
> > for UEFI secure boot for multiple ARM64 boards and qemu, including oeqa runtime tests.
> > Currently the qemu side changes to support UEFI secure boot are queued to meta-arm[1].
> > They could in theory be proposed to poky as well but there is no
> > matching machine config for that. meta-arm provides u-boot and many other
> > firmware SW components, including fTPM. ovmf seems to be only for x86,
> > same for the meta-secure-core side examples for UEFI secure boot.
> >
> > systemd uki support is really generic and not at all specific to arm
> > architectures. That's why I think it belongs to poky. Yes, the tests
> > need to be somewhere else currently unless test target HW already
> > has UEFI compatible firmware, but even with that the deployment of
> > signing keys/certs needs to be done separately.
> >
> > [1] https://lists.yoctoproject.org/g/meta-arm/topic/patch_v4_00_13/108164747
> 
> I've checked now. There is support for UKI in
> scripts/lib/wic/plugins/source/bootimg-efi.py
> 
> and there's a test for it in
> 
> meta/lib/oeqa/selftest/cases/wic.py (see
> test_efi_plugin_unified_kernel_image_qemu)
> meta-selftest/wic/test_efi_plugin.wks
> 
> Which begs the question: why add the class at all? Does it do
> something that can't be done by extending wic code? Can you adapt your
> work to use the wic plugin using the above as example?

Well, I wasn't aware of those implementations nor do I know how to use them.

I can try to figure out.

Cheers,

-Mikko


  reply	other threads:[~2024-09-02 13:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02 10:58 [PATCH 0/3] systemd uki support Mikko Rapeli
2024-09-02 10:58 ` [PATCH 1/2] systemd-boot-native: add runtime dependency to python3-pefile-native Mikko Rapeli
2024-09-02 10:58 ` [PATCH 2/2] uki.bbclass: add class for building Unified Kernel Images (UKI) Mikko Rapeli
2024-09-02 11:11   ` [OE-core] " Alexander Kanavin
2024-09-02 11:23     ` Mikko Rapeli
2024-09-02 12:01       ` Alexander Kanavin
2024-09-02 12:25         ` Mikko Rapeli
2024-09-02 13:03           ` Alexander Kanavin
2024-09-02 13:15             ` Mikko Rapeli [this message]
     [not found]             ` <17F16FAE8869E0F4.11433@lists.openembedded.org>
2024-09-02 14:14               ` Mikko Rapeli
2024-09-02 14:30                 ` Alexander Kanavin
2024-09-04  7:56                   ` Mikko Rapeli
2024-09-04  9:17                     ` Alexander Kanavin
2024-09-04 10:04                       ` Mikko Rapeli

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=ZtW6abFD67IrL28X@nuoska \
    --to=mikko.rapeli@linaro.org \
    --cc=alex.kanavin@gmail.com \
    --cc=erik.schilling@linaro.org \
    --cc=michelle.linto91@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox