| 0500f447 | 11-Aug-2021 |
Manish V Badarkhe <Manish.Badarkhe@arm.com> |
feat(plat/fvp): pass Event Log addr and size from BL1 to BL2
Introduced functions to set and get Event log information
(tpm_event_log address and its size).
In FVP platform case, measured boot with
feat(plat/fvp): pass Event Log addr and size from BL1 to BL2
Introduced functions to set and get Event log information
(tpm_event_log address and its size).
In FVP platform case, measured boot with Event Log backend flow
work as below
1. event_log_init function called by BL1 to initialize Event Log
module
2. arm_set_tb_fw_info function called by BL1 to set the
'tpm_event_log_addr' and 'tpm_event_log_size' properties
in tb_fw_config
3. arm_get_tb_fw_info function called by BL2 to get tpm Event Log
parameters set by BL1. These parameters used by the BL2 to
extend the tpm Event Log records, and use these parameters
to initialize Event Log using event_log_init function
4. arm_set_nt_fw_info and arm_set_tos_fw_info function called by
BL2 to set 'tpm_event_log' address and its size properties in
nt_fw_config and tos_fw_config respectively
Alongside, this patch created a separate instances of plat_mboot_init
and plat_mboot_finish APIs for BL1 and BL2.
This patch is tested using the existing measured boot test configuration
in jenkins CI.
Change-Id: Ib9eca092afe580df014541c937868f921dff9c37
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
show more ...
|
| efa65218 | 14-Sep-2021 |
Manish V Badarkhe <Manish.Badarkhe@arm.com> |
refactor(measured boot): remove platform calls from Event Log driver
Currently, the Event Log driver does platform layer work by invoking
a few platform functions in the 'event_log_finalise' call. D
refactor(measured boot): remove platform calls from Event Log driver
Currently, the Event Log driver does platform layer work by invoking
a few platform functions in the 'event_log_finalise' call. Doing
platform work does not seem to be the driver's responsibility, hence
moved 'event_log_finalise' function's implementation to the platform
layer.
Alongside, introduced few Event Log driver functions and done
some cosmetic changes.
Change-Id: I486160e17e5b0677c734fd202af7ccd85476a551
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
show more ...
|
| f19dc624 | 16-Jun-2021 |
johpow01 <john.powell@arm.com> |
refactor(gpt): productize and refactor GPT library
This patch updates and refactors the GPT library and fixes bugs.
- Support all combinations of PGS, PPS, and L0GPTSZ parameters.
- PPS and PGS are
refactor(gpt): productize and refactor GPT library
This patch updates and refactors the GPT library and fixes bugs.
- Support all combinations of PGS, PPS, and L0GPTSZ parameters.
- PPS and PGS are set at runtime, L0GPTSZ is read from GPCCR_EL3.
- Use compiler definitions to simplify code.
- Renaming functions to better suit intended uses.
- MMU enabled before GPT APIs called.
- Add comments to make function usage more clear in GPT library.
- Added _rme suffix to file names to differentiate better from the
GPT file system code.
- Renamed gpt_defs.h to gpt_rme_private.h to better separate private
and public code.
- Renamed gpt_core.c to gpt_rme.c to better conform to TF-A precedent.
Signed-off-by: John Powell <john.powell@arm.com>
Change-Id: I4cbb23b0f81e697baa9fb23ba458aa3f7d1ed919
show more ...
|
| deb4b3a6 | 13-Jul-2021 |
Zelalem Aweke <zelalem.aweke@arm.com> |
feat(plat/arm): add GPT initialization code for Arm platforms
When RME is enabled, during configuration of the TrustZone controller,
Root regions are initially configured as Secure regions, and Real
feat(plat/arm): add GPT initialization code for Arm platforms
When RME is enabled, during configuration of the TrustZone controller,
Root regions are initially configured as Secure regions, and Realm
regions as Non-secure regions. Then later these regions are configured
as Root and Realm regions respectively in the GPT. According to the RME
architecture reference manual, Root firmware must ensure that Granule
Protection Check is enabled before enabling any stage of translation.
Therefore initializations are done as follows when RME is enabled :
Initialize/enable the TrustZone controller (plat_arm_security_setup) -->
Initialize/enable GPC (arm_bl2_plat_gpt_setup) -->
enable MMU (enable_mmu_el3)
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I91094e8259079437bee02de1f65edb9ad51e43cf
show more ...
|
| c8720729 | 13-Jul-2021 |
Zelalem Aweke <zelalem.aweke@arm.com> |
feat(plat/fvp): add memory map for FVP platform for FEAT_RME
When FEAT_RME is enabled, memory is divided into four Physical
Address Spaces (PAS): Root, Realm, Secure and Non-secure.
This patch intro
feat(plat/fvp): add memory map for FVP platform for FEAT_RME
When FEAT_RME is enabled, memory is divided into four Physical
Address Spaces (PAS): Root, Realm, Secure and Non-secure.
This patch introduces new carveouts for the Trusted SRAM and DRAM
for the FVP platform accordingly.
The following new regions are introduced with this change:
ARM_MAP_L0_GPT_REGION: Trusted SRAM region used to store Level 0
Granule Protection Table (GPT). This region resides in the Root PAS.
ARM_MAP_GPT_L1_DRAM: DRAM region used to store Level 1 GPT. It
resides in the Root PAS.
ARM_MAP_RMM_DRAM: DRAM region used to store RMM image. It
resides in the Realm PAS.
The L0 GPT is stored on Trusted SRAM next to firmware configuration
memory. The DRAM carveout when RME is enable is modified as follow:
--------------------
| |
| AP TZC (~28MB) |
--------------------
| |
| REALM (32MB) |
--------------------
| |
| EL3 TZC (3MB) |
--------------------
| L1 GPT + SCP TZC |
| (~1MB) |
0xFFFF_FFFF --------------------
During initialization of the TrustZone controller, Root regions
are configured as Secure regions. Then they are later reconfigured
to Root upon GPT initialization.
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: If2e257141d51f51f715b70d4a06f18af53607254
show more ...
|