Re: [edk2] various SEC/PEI flavors in ArmPlatformPkg

Subject: Re: [edk2] various SEC/PEI flavors in ArmPlatformPkg

From: Laszlo Ersek <>

To: Olivier Martin <>, Michael Casadevall <>

Date: 2014-07-09 06:13:59

On 07/08/14 16:51, Olivier Martin wrote:
> Hi Lazlo,
> I might have missed some of your questions. But here are the first answers.
> I have tried to clarify the differences between these different components
> ArmPlatformPkg/Sec, ArmPlatformPkg/PrePi, ArmPlatformPkg/PrePeiCore in this
> wikipage:
> Let me know if some information are missing. I would prefer to update the
> wikipage than to duplicate the information in emails.
> To summarize, the intention of:
> - ArmPlatformPkg/Sec: To potentially initialize ARM Secure world (Trustzone
> controllers, etc) and make the transition to Non-Secure world. This 'SEC'
> was the first open source version of a Trusted/Secure firmware. ARM
> recommendation is to use the ARM Trusted Firmware project as a
> Trusted/Secure firmware.

Is that ?

> - ArmPlatformPkg/PrePeiCore: Hand-off to the PEI Core
> - ArmPlatformPkg/PrePi: The PEI spec assumes PI is always started from XIP &
> temporary RAM. On most (all?) ARM platforms, PI & UEFI phases are started
> from permanent DRAM. PEI Core does not fit well in this scenario. I have on
> my long todo list to send a proposal to the PI working group to remove this
> hard dependency on the temporary memory.
> The reasons why these three modules are SEC is to make GenFv patch the FV to
> jump to the entrypoint of these modules.
> Also, on all the ARM platforms I know, there is no way to detect how much
> DRAM is present on the platform. This information needs to be hardcoded.
> Again, feel free to ask additional questions if I missed anything or I am
> not clear enough.

Although it is quite a bit to digest, I think you answered my questions.
I also found "ArmPlatformPkg/Documentation/ArmPlatformPkg.txt".

It's not immediately obvious which "branch" of your porting guide (ie.
"edk2 from cold boot" vs. "edk2 as 2nd stage boot loader") to pick,
because the design of the virtual board (== qemu-system-aarch64 -M virt)
is not final yet (as I understand).

Currently two flash chips appear to be preferred (one for the variable
store, the other one for the firmware binary). In addition, I think at
this point it would be best to minimize the "moving parts" (ie. the
number of independent projects one has to rely on).

I would opt for Case 1, ie. "EDK2 from cold boot".
- We'd only need to focus (build, test) on edk2.
- ArmPlatformPkg/Sec would run from one of the emulated flash chips.
- We should investigate PrePeiCore, and ignore PrePi, wrt. memory setup.

Looking at the porting steps for Case 1:

- How should we set PcdTrustzoneSupport?

- Re 4. "Define the Secure / Monitor / Normal Stacks positions":

  I think we could hardcode those the Secure and Normal stack
  positions (QEMU would always provide RAM at those addresses).

  We'd let the Monitor stack alias the Secure stack (although that only
  seems to matter if PcdTrustzoneSupport is TRUE).

  - Is the normal stack expected to fall into system RAM?

  - The Secure Stack is distinct from the system RAM, right?

  - When we speak about "normal stack position", does that mean the
    temporary SEC/PEI stack+heap, from where the temporary RAM migration
    takes place?

- Re 5. "Define the Base and the Size of your System Memory (RAM)":

  - PcdSystemMemoryBase could be hardcoded (again, QEMU could guarantee
    that guest RAM starts there).

  - PcdSystemMemorySize should be retrieved dynamically from the DTB.

    Now, Case 1 implies PrePeiCore (and excludes PrePi). Under
    PrePeiCore, the only module using "PcdSystemMemorySize" is
    "ArmPlatformPkg/MemoryInitPei". I think we should be able to modify
    this module to parse the DTB or to figure out the memory size in
    some other "paravirtual" way.

Does this make sense?

I'd like to understand how the memory is laid out in the eyes of
ArmPlatformPkg -- what may or may not overlap etc.

For example, under case 1 (--> "firmware has been shadowed in the System
Memory"), InitializeMemory() checks if the permanent PEI memory (at
UefiMemoryBase) will fit into system RAM above or below the shadowed
firmware. But it doesn't check the stacks in this function.

I apologize if these questions are a bit confused :) I'm trying to
operate with my OVMF knowledge / concepts (because that's all I can
reach back to). Ultimately we'd like to understand ArmPlatformPkg's view
of the system memory, overlapping ranges etc, and then sync that view
with QEMU's virt board (including the two flash devices, the variably
sized system RAM).


>> -----Original Message-----
>> From: Laszlo Ersek []
>> Sent: 08 July 2014 15:30
>> To: Olivier Martin; Michael Casadevall
>> Cc: edk2-devel list; Peter Maydell; Christoffer Dall; Drew Jones; Mark
>> Langsdorf;; Ilias Biris; Patricia Gaughen; Leif
>> Lindholm
>> Subject: various SEC/PEI flavors in ArmPlatformPkg
>> Hello Olivier, Michael,
>> I'm trying to understand the early (SEC/PEI) code flow in
>> ArmPlatformPkg, in particular with regard to the configuration of the
>> early (temporary) SEC/PEI stack+heap, and then how the permanent PEI
>> memory are determined.
>> The motivation for this is that in an aarch64 virtual machine, at least
>> the permanent PEI memory size should be determined dynamically. (The
>> temporary SEC/PEI stack+heap should live at a fixed address.)
>> (1) I can see *three* SEC/PEI entry points in ArmPlatformPkg:
>>   ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S
>>   ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>>   ArmPlatformPkg/Sec/AArch64/SecEntryPoint.S
>> Ultimately each of these seems to call a C function named
>> CEntryPoint().
>> This function has three variants as well (respectively):
>>   ArmPlatformPkg/PrePeiCore/PrePeiCore.c
>>   ArmPlatformPkg/PrePi/PrePi.c
>>   ArmPlatformPkg/Sec/Sec.c
>> These C files all belong to MODULE_TYPE=SEC modules, hence the thought
>> that they are alternatives, not modules transitioning to each other:
>>   "Hand-off to PEI Core in Normal World":
>>     ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf
>>     ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
>>   :
>>     ArmPlatformPkg/PrePi/PeiMPCore.inf
>>     ArmPlatformPkg/PrePi/PeiUniCore.inf
>>   "SEC - Reset vector code that jumps to C and starts the PEI phase":
>>     ArmPlatformPkg/Sec/Sec.inf
>> So what is the difference between these three flavors?
>> (2) Looking at the DSC files, the EDK2_SKIP_PEICORE macro emerges as
>> the
>> differentiator between PrePeiCore and PrePi at least.
>> Is "ArmPlatformPkg/Sec" actually shared / always there, and it jumps to
>> either "ArmPlatformPkg/PrePi" or "ArmPlatformPkg/PrePeiCore"?
>> If that's the case, why is it necessary to dive back into assembly?
>> (Ie.
>> from "ArmPlatformPkg/Sec/Sec.c" to, say,
>> "ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S".)
>> (3) What does "skip PEI core" mean, and why would you skip it? I found
>> two DSC files (ie. platforms) that actually define this macro:
>>   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
>>   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
>> What justifies this difference? Eg. the Foundation model does not set
>> EDK2_SKIP_PEICORE, while the FVP does.
>> My idea would be to work with a fixed RAM base address, and a
>> guaranteed
>> minimum RAM size, throughout SEC and early PEI (ie. until migrating
>> from
>> temporary RAM to permanent RAM). This would allow the guest firmware to
>> parse the DTB in C code, derive the precise amount of RAM from the DTB,
>> and then install the permanent PEI RAM in InitializeMemory()
>> [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c] accordingly.
>> In other words, memory configuration should be dynamic indeed,
>> dependent
>> on guest RAM size, but *only* wrt. permanent PEI memory. Temporary
>> SEC/PEI stack & heap should be fixed, even for a guest.
>> In order to be able to reason about code and to see how the above idea
>> would apply to current SEC/PEI code, I'd like to understand which
>> flavor
>> of the above three I should look at. (Ie. which one would be most
>> appropriate for a virtual machine.) Please enlighten me.
>> Thanks!
>> Laszlo

Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
edk2-devel mailing list