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: http://tianocore.sourceforge.net/wiki/ArmPlatformPkg 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. - 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. Thanks, Olivier > -----Original Message----- > From: Laszlo Ersek [mailto:[email protected]] > Sent: 08 July 2014 15:30 > To: Olivier Martin; Michael Casadevall > Cc: edk2-devel list; Peter Maydell; Christoffer Dall; Drew Jones; Mark > Langsdorf; [email protected]; 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 > > <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
