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
<no comment on use>:
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
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
