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 of ATF binaries such as bl0 and bl3 under Juno. Does it mean Juno works with combination of ATF and EDK2 ?
- Is there a simple way to switch to EL2 using EDK2 packages. I guess the Sec part is supposed to do that, right ?
Thanks
------------------- Yehuda Yitschak Marvell Semiconductor Ltd.
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 of ATF binariessuch 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 EDK2 packages. Iguess 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.
Regards, Ard.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Wednesday, November 04, 2015 15:51 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org; leif.lindholm@linaro.org; Shadi Ammouri Subject: Re: UEFI switch to EL2
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 of ATF binariessuch 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 EDK2 packages. Iguess 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.
Isn’t there an intention to make EDK2 a full solution (secure monitor + FW) for ARM platforms ?
Regards
Yehuda
Regards, Ard.
On 4 November 2015 at 14:33, Yehuda Yitschak yehuday@marvell.com wrote:
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Wednesday, November 04, 2015 15:51 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org; leif.lindholm@linaro.org; Shadi Ammouri Subject: Re: UEFI switch to EL2
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 of ATF binariessuch 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 EDK2 packages. Iguess 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 believe the official line here is yes. ARM are very keen that all Aarch64 devices use ARM-TF. But it isn't mandatory, of course. You'd want to re-sync periodically to make sure you pick up bug fixes either by rebasing your code to the latest or by cherry-picking fixes. But that's normal software engineering.
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.
Once you have a working set, you don't need to keep updating the ARM-TF binaries.
You do need to update the FIP with your UEFI binary as an extra step, but it's not a large overhead, IMO.
It might not be a real issue if you actually load edk2 from flash but if you compile them together .... im not sure.
Personally, I build them separately.
Isn’t there an intention to make EDK2 a full solution (secure monitor + FW) for ARM platforms ?
Regards
Yehuda
Regards, Ard.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
-----Original Message----- From: Linaro-uefi [mailto:linaro-uefi-bounces@lists.linaro.org] On Behalf Of Yehuda Yitschak Sent: Wednesday, November 04, 2015 8:03 PM To: Ard Biesheuvel Cc: Shadi Ammouri; Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] UEFI switch to EL2
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Wednesday, November 04, 2015 15:51 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org; leif.lindholm@linaro.org; Shadi Ammouri Subject: Re: UEFI switch to EL2
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 of ATFbinaries
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 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.
Regards, Bhupesh
Hi Bhupesh
Thanks for sharing your experience
-----Original Message----- From: Sharma Bhupesh [mailto:bhupesh.sharma@freescale.com] Sent: Wednesday, November 04, 2015 17:50 To: Yehuda Yitschak; Ard Biesheuvel Cc: Shadi Ammouri; Linaro-uefi@lists.linaro.org Subject: RE: UEFI switch to EL2
-----Original Message----- From: Linaro-uefi [mailto:linaro-uefi-bounces@lists.linaro.org] On Behalf Of Yehuda Yitschak Sent: Wednesday, November 04, 2015 8:03 PM To: Ard Biesheuvel Cc: Shadi Ammouri; Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] UEFI switch to EL2
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Wednesday, November 04, 2015 15:51 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org; leif.lindholm@linaro.org; Shadi Ammouri Subject: Re: UEFI switch to EL2
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 of ATFbinaries
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.
Regards Yehuda
Regards, Bhupesh
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
On Wed, Nov 04, 2015 at 02:33:26PM +0000, Yehuda Yitschak wrote:
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 ?
Yes.
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.
It's not necessarily that bad. You can have a look at the helper scripts in Linaro's UEFI-tools: https://git.linaro.org/uefi/uefi-tools.git
I use these both for development and for our binary releases, and for platforms using ATF it builds ATF and wraps the UEFI .fd into the ".fip" format consumed by ATF.
Just specify the path to your ATF checkout on the command line with -a <path>.
Isn’t there an intention to make EDK2 a full solution (secure monitor + FW) for ARM platforms ?
I'm not even sure that is possible. Certainly, ATF needs to support additional firmware solutions to UEFI.
/ Leif
-
Ard Biesheuvel -
Leif Lindholm -
Ryan Harkin -
Sharma Bhupesh -
Yehuda Yitschak