public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: edk2-devel-groups-io <devel@edk2.groups.io>,
	Rebecca Cran <quic_rcran@quicinc.com>,
	 Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Leif Lindholm <quic_llindhol@quicinc.com>
Subject: Re: [edk2-devel] ArmPlatformPkg: understanding PrePi vs PrePeiCore
Date: Tue, 3 May 2022 11:06:17 +0200	[thread overview]
Message-ID: <CAMj1kXGtCcLW3tnKdjkENHpEghuQf4NC+78w79g9TZ9MFWKUEA@mail.gmail.com> (raw)
In-Reply-To: <a6abeea0-6a91-5067-db49-147eddb5780b@quicinc.com>

On Tue, 12 Apr 2022 at 18:01, Rebecca Cran <quic_rcran@quicinc.com> wrote:
>
> I've been working on cleaning up some of the code in ArmPlatformPkg and
> have been trying to understand the differences between PrePi and PrePeiCore.
> It looks like PrePi was added to save space over PrePeiCore, but I'm
> wondering if we still need it?

Andrew should be able to answer this, as well as Eugene, I imagine.

The reason is that PEI is designed to execute in place from NOR flash,
and so it assumes that global variables are read-only, except for some
'temporary RAM' located in the cache running in no-evict mode, which
includes the stack as well. This permits PEI to configure and
initialize the DRAM controller and DRAM.

When EDK2 was ported to the BeagleBoard, it relied on a previous boot
stage that copied the image into DRAM and executed it from there. This
means PEI is unneeded, and SEC can launch the DXE core directly,
provided that it creates the minimal PEI context that the DXE core
relies on to be able to initialize itself.

This is why MemoryPeim, CpuPeim etc are all factored into libraries on
ARM, this permits the individual PEIMs to pull in the functionality,
but permits a single PrePi SEC stage to pull in those same libraries
and have the same functionality.

Unfortunately, for things like Capsule Update and measured boot, PrePi
is unsuitable unless we factor out those things into libraries as
well. Since PEI can happily execute from DRAM as well as NOR flash,
this means that for more complete implementations, PrePeiCore is a
better choice.

Note that SynQuacer also uses PrePeiCore, but actually does run it in
place from NOR flash, just like ArmVirtQemu does. Platforms such as
Seattle use PrePeiCore but rely on TF-A to copy the entire FD image
into DRAM first.


> I'm guessing most of the platforms below
> could use the latter, possibly with the exception of BeagleBoard and
> VExpress?
>
>
> Platforms using PrePi/Pei{Uni,MP}Core:
>
> RPi3
> RPi4
> HiKey
> BeagleBoard
> VExpress-FVP
> ArmJuno
> HiKey960
> DurianPkg
> VExpress-CTA15-A7
>
> --
> Rebecca Cran
>
>
>
> 
>
>

      reply	other threads:[~2022-05-03  9:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 16:01 ArmPlatformPkg: understanding PrePi vs PrePeiCore Rebecca Cran
2022-05-03  9:06 ` Ard Biesheuvel [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-list 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=CAMj1kXGtCcLW3tnKdjkENHpEghuQf4NC+78w79g9TZ9MFWKUEA@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /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