From: Yehuda Yitschak [mailto:yehuday@marvell.com] Sent: Wednesday, November 04, 2015 9:56 PM
Hi Bhupesh
Hi ,
Thanks for sharing your experience
On 4 November 2015 at 14:31, Yehuda Yitschak yehuday@marvell.com wrote:
Hello everyone
I am in the process of porting EDK2 to a Quad core Aarch64 based
SOC.
The SOC has a built-in BootROM running in EL3. When the BootROM completes loading The image it transfers control to the loaded image in EL3 to allow installing a secure monitor Since we have an on chip primary loader (i.e. BootROM) I used the 2nd stage template as a basis for my port
So in my flow BootROM loads FD image to main memory and jumps to the entry point in EL3 I quickly found out however that EDK2 expects to be executed in EL2 or EL1.
It was a bit surprising actually. I expected EDK2 to also act is a secure monitor and handle the PSCI calls as well.
I guess I am missing something in the functional partition.
To get to the point I would like to ask;
Who handles PSCI in Juno. I noticed the existence ofATF
binaries
such as bl0 and bl3 under Juno. Does it mean Juno works with combination of ATF and EDK2 ?
Indeed. On the Juno reference platform, UEFI is merely an intermediate stage bootloader that gets loaded to DRAM by the secure firmware and executed in EL2
Is there a simple way to switch to EL2 using EDK2packages. I
guess the Sec part is supposed to do that, right ?
Yes. ArmPlatformPkg/Sec/Sec.c should cover everything you need, although I must stress that a) this code is unused and thus untested, and b) it is not the recommended approach.
Thanks, I will use the Sec as an intermediate solution.
What is the suggested approach? using ATF together with EDK2 ? I'm just a bit worried about the flow of generating a boot image. It looks like it would require constantly syncing ATF binaries into EDK2 source. It might not be a real issue if you actually load edk2 from flash but if you compile them together .... im not sure.
Using ATF is recommended, though not mandatory. For e.g. we are booting
We will probably go with an ATF solution eventually since we need ATF for other FW solutions
UEFI in EL3 mode on our ARMv8 SoC without using ATF upfront. We have a custom implementation of platform & run-time security firmware (something similar to ATF) which runs in EL3. Both UEFI and custom FW are placed on NOR flash.
So we don't have the SEC stage, PEI starts up in EL3 and calls the custom FW which runs in EL3 then it transitions the DXE phase to EL2.
Just wondering, Is there a reason you don’t use " ArmPlatformPkg/Sec/Sec.c" as a solution ? Even though its unsupported it looks like it has some useful secure initialization like the GIC security settings, etc.
It depends on the overall solution you want to build. ATF and similar platform & run-time security firmware can have different platform policies for different boards/customers of the same SoC. For e.g. some board might have a 2GB DDR connected to it, while the others built around the same SoC might have 4GB DDR connected to it.
So, changing the security policy for e.g. of the TrustZone Address Space Controller (TZASC) connected before the DDR and used to define secure regions in the DDR memory might require changing the uefi image everytime, if you use the SEC component to call the TZASC helper APIs, for various board/customer use-cases.
It makes more sense to have this taken care of in a ATF/similar EL3 firmware, thus making the uefi image similar on each board, so that the customer can modify the ATF-like FW on the NOR flash as per his/her needs, without touching the UEFI image.
Broadly speaking, the SEC stage performs a sub-set of what the ATF already does. So why not instead use the super-set from the very start..
Regards, Bhupesh