- Increase PPS for FVP from 64GB to 1TB.
- GPT L0 table for 1TB PPS requires 8KB memory.
- Set FVP_TRUSTED_SRAM_SIZE to 384 with ENABLE_RME=1
option.
- Add 256MB of PCIe memory region 1 and 3GB of
PCIe memory region 2 to FVP PAS regions array.
Change-Id: Icadd528576f53c55b5d461ff4dcd357429ba622a
Signed-off-by: AlexeiFedorov <Alexei.Fedorov@arm.com>
For FVP model define single Root PAS which
includes EL3 DRAM data, L1 GPTs and SCP TZC.
This allows to decrease the number of PAS
regions passed to GPT library and use GPT
mapping with Contiguous descriptor of
larger block size.
Change-Id: I70f6babaebc14e5e0bce033783ec423c8a26c542
Signed-off-by: AlexeiFedorov <Alexei.Fedorov@arm.com>
The initialization logic for the secure transfer list is currently
scattered and duplicated across platform setup code. This not only leads
to inefficiency but also complicates access to transfer lists from other
parts of the code without invoking setup functions. For instance,
arm_bl2_setup_next_ep_info acts as a thin wrapper in arm_bl2_setup.c to
provide access to the secure transfer list.
To streamline the interface, all setup code has been consolidated into a
central location.
Change-Id: I99d2a567ff39df88baa57e7e08607fccb8af189c
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Leverage the framework between BL1 and BL2. Migrate all handoff
structures to the TL.
Change-Id: I79ff3a319596b5656184cde10b5204b10a4d03bb
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Add support for the firmware handoff framework between BL2 and BL31.
Create a transfer list in trusted SRAM, leveraging the larger SRAM sizes
in recent models. Load the HW_CONFIG as a TE along with entry point
parameters for BL31 execution.
Change-Id: I7c4c6e8353ca978a13520fb3e15fb2803f0f1d0e
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
For RME-enabled platforms, initializing L0 and L1 tables and enabling
GPC checks is necessary. For systems using BL2 to load firmware images,
the GPT initialization has to be done in BL2 prior to the image load.
The common Arm platform code currently implements this in the
"arm_bl2_plat_gpt_setup" function, relying on the FVP platform's
specifications (PAS definitions, GPCCR_PPS, and GPCCR_PGS).
Different Arm platforms may have distinct PAS definitions, GPCCR_PPS,
GPCCR_PGS, L0/L1 base, and size. To accommodate these variations,
introduce the "plat_arm_get_gpt_info" API. Platforms must implement
this API to provide the necessary data for GPT setup on RME-enabled
platforms. It is essential to note that these additions are relevant to
platforms under the plat/arm hierarchy that will reuse the
"arm_bl2_plat_gpt_setup" function.
As a result of these new additions, migrate data related to the FVP
platform to its source and header files.
Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: I4f4c8894c1cda0adc1f83e7439eb372e923f6147
Post image handling of the HW_CONFIG is out-of-scope for
`plat_get_next_bl_params`. Move parts of the code responsible for post
processing of loaded images into `bl2_plat_handle_post_image_load` for code
reusability and maintainability.
Change-Id: I476b3d306ebcd4529f5e542ba1063e144920bb5f
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
In certain instances a platform may need to make modifications to an
image after it has been loaded by BL2. The existing common
implementation is a thin wrapper for a more generic arm post image
handler. To enable platforms to make changes to images when
they're loaded, move this into platform code.
Change-Id: I44025391056adb2d8a8eb4ea5984257b02027181
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
The firmware handoff framework is a light weight mechanism for sharing
information between bootloader stages. Add support for this framework at
the handoff boundary between runtime firmware BL31 and NS software on FVP.
Change-Id: Ib02e0e4c20a39e32e06da667caf2ce5a28de1e28
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
BL2_AT_EL3 is an overloaded macro which has two uses:
1. When BL2 is entry point into TF-A(no BL1)
2. When BL2 is running at EL3 exception level
These two scenarios are not exactly same even though first implicitly
means second to be true. To distinguish between these two use cases we
introduce new macros.
BL2_AT_EL3 is renamed to RESET_TO_BL2 to better convey both 1. and 2.
Additional macro BL2_RUNS_AT_EL3 is added to cover all scenarious where
BL2 runs at EL3 (including four world systems).
BREAKING CHANGE: BL2_AT_EL3 renamed to RESET_TO_BL2 across the
repository.
Change-Id: I477e1d0f843b44b799c216670e028fcb3509fb72
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Signed-off-by: Maksims Svecovs <maksims.svecovs@arm.com>
In line with the previous patch, the name of the member of the
hw_config DTB info structure has been renamed.
Change-Id: I6689e416fecd66faa515e820f1c4b23bcb65bfb1
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Currently, HW-config is loaded into non-secure memory, which mean
a malicious NS-agent could tamper with it. Ideally, this shouldn't
be an issue since no software runs in non-secure world at this time
(non-secure world has not been started yet).
It does not provide a guarantee though since malicious external
NS-agents can take control of this memory region for update/corruption
after BL2 loads it and before BL31/BL32/SP_MIN consumes it. The threat
is mapped to Threat ID#3 (Bypass authentication scenario) in threat
model [1].
Hence modified the code as below -
1. BL2 loads the HW_CONFIG into secure memory
2. BL2 makes a copy of the HW_CONFIG in the non-secure memory at an
address provided by the newly added property(ns-load-address) in
the 'hw-config' node of the FW_CONFIG
3. SP_MIN receives the FW_CONFIG address from BL2 via arg1 so that
it can retrieve details (address and size) of HW_CONFIG from
FW_CONFIG
4. A secure and non-secure HW_CONFIG address will eventually be used
by BL31/SP_MIN/BL32 and BL33 components respectively
5. BL31/SP_MIN dynamically maps the Secure HW_CONFIG region and reads
information from it to local variables (structures) and then
unmaps it
6. Reduce HW_CONFIG maximum size from 16MB to 1MB; it appears
sufficient, and it will also create a free space for any future
components to be added to memory
[1]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html
Change-Id: I1d431f3e640ded60616604b1c33aa638b9a1e55e
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Right now, the assumption is that the platform post-load hook takes
care of measuring the image that just got loaded. This is how it's
implemented on FVP.
This patch moves the measurement into the generic code
instead. load_auth_image() now calls plat_mboot_measure_image(),
which is a new platform interface introduced in this patch to measure
an image. This is called just after authenticating the image.
Implement plat_mboot_measure_image() for the Arm FVP platform. The code
is copied straight from the post-load hook.
As a result, the FVP specific implementation of
arm_bl2_plat_handle_post_image_load() is no longer needed. We can go
back to using the Arm generic implementation of it.
Change-Id: I7b4b8d28941a865e10af9d0eadaf2e4850942090
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Right now, the measured boot driver is strongly coupled with the TCG
event log driver. It would not be possible to push the measurements
somewhere else, for instance to a physical TPM.
To enable this latter use case, turn the driver's init and teardown
functions into platform hooks. Call them bl2_plat_mboot_init()/finish().
This allows each platform to implement them appropriately, depending on
the type of measured boot backend they use. For example, on a platform
with a physical TPM, the plat_mboot_init() hook would startup the TPM
and setup it underlying bus (e.g. SPI).
Move the current implementation of the init and teardown function to the
FVP platform layer.
Finally move the conditional compilation logic (#if MEASURED_BOOT) out
of bl2_main() to improve its readability. Provide a dummy implementation
in the case measured boot is not included in the build.
Change-Id: Ib6474cb5a9c1e3d4a30c7f228431b22d1a6e85e3
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
tpm_record_measurement() function name suggests that:
- It only records a measurement but does not compute it.
This is not the case, the function does both.
- It stores this measurement into a TPM (discrete chip or fTPM).
This is not the case either, the measurement is just stored into
the event log, which is a data structure hold in memory, there is
no TPM involvement here.
To better convey the intent of the function, rename it into
event_log_measure_and_record().
Change-Id: I0102eeda477d6c6761151ac96759b31b6997e9fb
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
This patch adds support for Measured Boot functionality
to FVP platform code. It also defines new properties
in 'tpm_event_log' node to store Event Log address and
it size
'tpm_event_log_sm_addr'
'tpm_event_log_addr'
'tpm_event_log_size'
in 'event_log.dtsi' included in 'fvp_tsp_fw_config.dts'
and 'fvp_nt_fw_config.dts'. The node and its properties
are described in binding document
'docs\components\measured_boot\event_log.rst'.
Change-Id: I087e1423afcb269d6cfe79c1af9c348931991292
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Passed the address of fw_config instead of soc_fw_config
as arg1 to BL31 from BL2 for ARM fvp platform.
BL31 then retrieve load-address of other device trees
from fw_config device tree.
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ib7e9581cd765d76111dcc3b7e0dafc12503c83c1
SMMUv3 driver functions which are called from BL1 and BL31
currently use counter-based poll method for testing status
bits. Adding Delay Timer driver to BL1 and BL31 is required
for timeout-based implementation using timer delay functions
for SMMU and other drivers.
This patch adds new function `fvp_timer_init()` which
initialises either System level generic or SP804 timer based on
FVP_USE_SP804_TIMER build flag.
In BL2U `bl2u_early_platform_setup()` function the call to
`arm_bl2u_early_platform_setup()` (which calls
`generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag),
is replaced with `arm_console_boot_init()` and `fvp_timer_init()`.
Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Use full include paths like it is done for common includes.
This cleanup was started in commit d40e0e08283a ("Sanitise includes
across codebase"), but it only cleaned common files and drivers. This
patch does the same to Arm platforms.
Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
From now on, platform_def.h must include any header with definitions that
are platform-specific (like arm_def.h) and the included headers mustn't
include back platform_def.h, and shouldn't be used by other files. Only
platform_def.h should be included in other files. This will ensure that all
needed definitions are present, rather than needing to include all the
headers in all the definitions' headers just in case.
This also prevents problems like cyclic dependencies.
Change-Id: I9d3cf4d1de4b956fa035c79545222697acdaf5ca
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}
The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).
For example, this patch had to be created because two headers were
called the same way: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.
Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.
Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The patch adds the necessary changes to load HW_CONFIG in BL2 for
ARM Platforms :
1. The load address of HW_CONFIG is specified via the `hw_config_addr`
property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size`
property defines the maximum size to be expected for the HW_CONFIG.
The `arm_dyn_cfg_helpers.c` and corresponding header implements
utility functions to parse these DT properties defined.
The `arm_dyn_cfg.c` implements wrappers to these helpers to enable
them to be invoked from ARM platform layer.
2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is
the list of images to be loaded by BL2.
3. The `libfdt` sources are now included when BL2 is built
4. A new helper `populate_next_bl_params_config()` is introduced in
desc_image_load.c to populate the subsequent executable BL images
with the `hw_config` and the corresponding `fw_config` if available.
The `plat_get_next_bl_params()` API for ARM platforms is modified to
invoke this new helper.
5. The implementation of `bl2_early_platform_setup2()` is modified to
consider `arg0` as well in addition to `arg1` passed from BL1.
6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt.
Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
This patch migrates the ARM Standard platforms to the new BL
handover interface. The arm_blx_early_platform_setup() functions
are also modified to take in 4 arguments. The `ARM_BL31_PLAT_PARAM_VAL`
value passed to BL31 from BL2 is now in arg3 in preparation of dynamic
configuration arguments.
Change-Id: I33e8e61325a19e7a7127b1ff203c3b86921bf153
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.
NOTE: Files that have been imported by FreeBSD have not been modified.
[0]: https://spdx.org/
Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Added a build flag to select the generic delay timer on FVP instead
of the SP804 timer. By default, the generic one will be selected. The
user guide has been updated.
Change-Id: Ica34425c6d4ed95a187b529c612f6d3b26b78bc6
This patch fixes several issues with the SP804 delay timer on FVP:
* By default, the SP804 dual timer on FVP runs at 32 KHz. In order
to run the timer at 35 MHz (as specified in the FVP user manual)
the Overwrite bit in the SP810 control register must be set.
* The CLKMULT and CLKDIV definitions are mixed up:
delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)
From the delay function:
delta_us = (delta * ops->clk_mult) / ops->clk_div;
Matching both expressions:
1 / f(MHz) = ops->clk_mult / ops->clk_div
And consequently:
f(MHz) = ops->clk_div / ops->clk_mult
Which, for a 35 MHz timer, translates to:
ops->clk_div = 35
ops->clk_mult = 1
* The comment in the delay timer header file has been corrected:
The ratio of the multiplier and the divider is the clock period
in microseconds, not the frequency.
Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
Add SP804 delay timer support to the FVP BSP.
This commit simply provides the 3 constants needed by the SP804
delay timer driver and calls sp804_timer_init() in
bl2_platform_setup(). The BSP does not currently use the delay
timer functions.
Note that the FVP SP804 is a normal world accessible peripheral
and should not be used by the secure world after transition
to the normal world.
Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39
Co-authored-by: Dan Handley <dan.handley@arm.com>
Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
some of the files so they are consistently prefixed with fvp_.
Update the platform makefiles accordingly.
Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
