This patch modifies the upstream platform port makefiles to use the new
xlat_tables library files. This patch also makes mmap region setup common
between AArch64 and AArch32 for FVP platform port. The file `fvp_common.c`
is moved from the `plat/arm/board/fvp/aarch64` folder to the parent folder
as it is not specific to AArch64.
Change-Id: Id2e9aac45e46227b6f83cccfd1e915404018ea0b
This patch adds support for non-volatile counter authentication to
the Authentication Module. This method consists of matching the
counter values provided in the certificates with the ones stored
in the platform. If the value from the certificate is lower than
the platform, the boot process is aborted. This mechanism protects
the system against rollback.
The TBBR CoT has been updated to include this method as part of the
authentication process. Two counters are used: one for the trusted
world images and another for the non trusted world images.
** NEW PLATFORM APIs (mandatory when TBB is enabled) **
int plat_get_nv_ctr(void *cookie, unsigned int *nv_ctr);
This API returns the non-volatile counter value stored
in the platform. The cookie in the first argument may be
used to select the counter in case the platform provides
more than one (i.e. TBSA compliant platforms must provide
trusted and non-trusted counters). This cookie is specified
in the CoT.
int plat_set_nv_ctr(void *cookie, unsigned int nv_ctr);
This API sets a new counter value. The cookie may be
used to select the counter to be updated.
An implementation of these new APIs for ARM platforms is also
provided. The values are obtained from the Trusted Non-Volatile
Counters peripheral. The cookie is used to pass the extension OID.
This OID may be interpreted by the platform to know which counter
must return. On Juno, The trusted and non-trusted counter values
have been tied to 31 and 223, respectively, and cannot be modified.
** IMPORTANT **
THIS PATCH BREAKS THE BUILD WHEN TRUSTED_BOARD_BOOT IS ENABLED. THE
NEW PLATFORM APIs INTRODUCED IN THIS PATCH MUST BE IMPLEMENTED IN
ORDER TO SUCCESSFULLY BUILD TF.
Change-Id: Ic943b76b25f2a37f490eaaab6d87b4a8b3cbc89a
This patch adds an option to the ARM common platforms to load BL31 in the
TZC secured DRAM instead of the default secure SRAM.
To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
If TSP is present, then setting this option also sets the TSP location
to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
To use this feature, BL2 platform code must map in the DRAM used by
BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
Currently, only the FVP BL2 platform code maps in this DRAM.
Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
Added a new platform porting function plat_panic_handler, to allow
platforms to handle unexpected error situations. It must be
implemented in assembly as it may be called before the C environment
is initialized. A default implementation is provided, which simply
spins.
Corrected all dead loops in generic code to call this function
instead. This includes the dead loop that occurs at the end of the
call to panic().
All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
been removed.
Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
`board_arm_def.h` contains multiple definitions of
`PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
memory usage depending upon the chosen build configuration. To ease
maintenance of these constants, this patch replaces their multiple
definitions with a single set of definitions that will work on all ARM
platforms.
Platforms can override the defaults with optimal values by enabling the
`ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
the Juno ADP port.
Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
future ARM platforms.
Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
The common topology description helper funtions and macros for
ARM Standard platforms assumed a dual cluster system. This is not
flexible enough to scale to multi cluster platforms. This patch does
the following changes for more flexibility in defining topology:
1. The `plat_get_power_domain_tree_desc()` definition is moved from
`arm_topology.c` to platform specific files, that is `fvp_topology.c`
and `juno_topology.c`. Similarly the common definition of the porting
macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
specific `platform_def.h` header.
2. The ARM common layer porting macros which were dual cluster specific
are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
which must be defined by each ARM standard platform.
3. A new mandatory ARM common layer porting API
`plat_arm_get_cluster_core_count()` is introduced to enable the common
implementation of `arm_check_mpidr()` to validate MPIDR.
4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
introduced which allows the user to specify the cluster count to be
used to build the topology tree within Trusted Firmare. This enables
Trusted Firmware to be built for multi cluster FVP models.
Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
The shared memory region on ARM platforms contains the mailboxes and,
on Juno, the payload area for communication with the SCP. This shared
memory may be configured as normal memory or device memory at build
time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
When set as normal memory, the platform port performs the corresponding
cache maintenance operations. From a functional point of view, this is
the equivalent of setting the shared memory as device memory, so there
is no need to maintain both options.
This patch removes the option to specify the shared memory as normal
memory on ARM platforms. Shared memory is always treated as device
memory. Cache maintenance operations are no longer needed and have
been replaced by data memory barriers to guarantee that payload and
MHU are accessed in the right order.
Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
ARM Trusted Firmware supports 2 different interconnect peripheral
drivers: CCI and CCN. ARM platforms are implemented using either of the
interconnect peripherals.
This patch adds a layer of abstraction to help ARM platform ports to
choose the right interconnect driver and corresponding platform support.
This is as described below:
1. A set of ARM common functions have been implemented to initialise an
interconnect and for entering/exiting a cluster from coherency. These
functions are prefixed as "plat_arm_interconnect_". Weak definitions of
these functions have been provided for each type of driver.
2.`plat_print_interconnect_regs` macro used for printing CCI registers is
moved from a common arm_macros.S to cci_macros.S.
3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure
is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.
Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
Prior to this patch, it was assumed that on all ARM platforms the bare
minimal security setup required is to program TrustZone protection. This
would always be done by programming the TZC-400 which was assumed to be
present in all ARM platforms. The weak definition of
platform_arm_security_setup() in plat/arm/common/arm_security.c
reflected these assumptions.
In reality, each ARM platform either decides at runtime whether
TrustZone protection needs to be programmed (e.g. FVPs) or performs
some security setup in addition to programming TrustZone protection
(e.g. NIC setup on Juno). As a result, the weak definition of
plat_arm_security_setup() is always overridden.
When a platform needs to program TrustZone protection and implements the
TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is
also possible to program TrustZone protection through other peripherals
that include a TrustZone controller e.g. DMC-500. The programmer's
interface is slightly different across these various peripherals.
In order to satisfy the above requirements, this patch makes the
following changes to the way security setup is done on ARM platforms.
1. arm_security.c retains the definition of arm_tzc_setup() and has been
renamed to arm_tzc400.c. This is to reflect the reliance on the
TZC-400 peripheral to perform TrustZone programming. The new file is
not automatically included in all platform ports through
arm_common.mk. Each platform must include it explicitly in a platform
specific makefile if needed.
This approach enables introduction of similar library code to program
TrustZone protection using a different peripheral. This code would be
used by the subset of ARM platforms that implement this peripheral.
2. Due to #1 above, existing platforms which implements the TZC-400 have been
updated to include the necessary files for both BL2, BL2U and BL31
images.
Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
cater for future ARM platforms this is made platform specific.
Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
platform specific.
Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
Each ARM Compute Subsystem based platform implements a System Security
Control (SSC) Registers Unit. The SSC_VERSION register inside it carries
information to identify the platform. This enables ARM Trusted Firmware
to compile in support for multiple ARM platforms and choose one at
runtime. This patch adds macros to enable access to this register.
Each platform is expected to export its PART_NUMBER separately.
Additionally, it also adds juno part number.
Change-Id: I2b1d5f5b65a9c7b76c6f64480cc7cf0aef019422
This patch moves the definition of some macros used only on
ARM platforms from common headers to platform specific headers.
It also forces all ARM standard platforms to have distinct
definitions (even if they are usually the same).
1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
moved from `css_def.h` to `platform_def.h`.
2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
to platform specific header `platform_def.h` on Juno and
renamed as `PLAT_ARM_MHU_BASE`.
3. To cater for different sizes of BL images, new macros like
`PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
ARM platforms need to define them for each image.
Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP.
This allows the same TF binaries to run on a Cortex-A72 based FVP
without recompiling them.
Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47
This patch adds support for ARM Cortex-A35 processor in the CPU
specific framework, as described in the Cortex-A35 TRM (r0p0).
Change-Id: Ief930a0bdf6cd82f6cb1c3b106f591a71c883464
fvp_pwr_domain_on() used to program the CPUs mailbox. This changed
with commit 804040d10 but the comment documenting this code still
refers to the mailbox programming. This patch removes this out-dated
information.
Change-Id: Ibfe2a426bdda6e71f20c83a99cb223ceca9c559c
The current FWU_SMC_UPDATE_DONE implementation incorrectly passes
an unused framework cookie through to the 1st argument in the
platform function `bl1_plat_fwu_done`. The intent is to allow
the SMC caller to pass a cookie through to this function.
This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller
through to `bl1_plat_fwu_done`. The argument names are updated
for clarity.
Upstream platforms currently do not use this argument so no
impact is expected.
Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
This patch removes the dash character from the image name, to
follow the image terminology in the Trusted Firmware Wiki page:
https://github.com/ARM-software/arm-trusted-firmware/wiki
Changes apply to output messages, comments and documentation.
non-ARM platform files have been left unmodified.
Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
This patch adds support for Firmware update in BL2U for ARM
platforms such that TZC initialization is performed on all
ARM platforms and (optionally) transfer of SCP_BL2U image on
ARM CSS platforms.
BL2U specific functions are added to handle early_platform and
plat_arch setup. The MMU is configured to map in the BL2U
code/data area and other required memory.
Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
This patch adds Firmware Update support for ARM platforms.
New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
platform specific Firmware update code.
BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
authenticating NS_BL2U image(For both FVP and JUNO platform).
Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
This patch overrides the default weak definition of
`bl31_plat_runtime_setup()` for ARM Standard platforms to
specify a BL31 runtime console. ARM Standard platforms are
now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
`PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
by `arm_bl31_plat_runtime_setup()` to initialize the runtime
console.
The system suspend resume helper `arm_system_pwr_domain_resume()`
is fixed to initialize the runtime console rather than the boot
console on resumption from system suspend.
FixesARM-software/tf-issues#220
Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
separate drivers instead of providing a single driver that can work on both
versions of the GIC architecture. These drivers correspond to the following
software use cases:
1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
e.g. GIC-400
2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
3. A deprecated GICv3 driver that operates in legacy mode. This driver can
operate only in the GICv2 mode in the secure world. On a GICv3 system, this
driver allows normal world to run in either GICv3 mode (asymmetric mode)
or in the GICv2 mode. Both modes of operation are deprecated on GICv3
systems.
ARM platforms implement both versions of the GIC architecture. This patch adds a
layer of abstraction to help ARM platform ports chose the right GIC driver and
corresponding platform support. This is as described below:
1. A set of ARM common functions have been introduced to initialise the GIC and
the driver during cold and warm boot. These functions are prefixed as
"plat_arm_gic_". Weak definitions of these functions have been provided for
each type of driver.
2. Each platform includes the sources that implement the right functions
directly into the its makefile. The FVP can be instantiated with different
versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
to specify which of the three drivers should be included in the build.
3. A list of secure interrupts has to be provided to initialise each of the
three GIC drivers. For GIC v3.0 the interrupt ids have to be further
categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
types are merged and treated as Group 0 interrupts.
The two lists of interrupts are exported from the platform_def.h. The lists
are constructed by adding a list of board specific interrupt ids to a list of
ids common to all ARM platforms and Compute sub-systems.
This patch also makes some fields of `arm_config` data structure in FVP redundant
and these unused fields are removed.
Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
This patch adds platform helpers for the new GICv2 and GICv3 drivers in
plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
file in their build according to the GIC driver to be used. The existing
plat_gic.c is only meant for the legacy GIC driver.
In the case of ARM platforms, the major changes are as follows:
1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU
interface register values has been modified to detect the type of CPU
interface being used (System register or memory mappped interface) before
using the right interface to print the registers.
2. The power management helper function that is called after a core is powered
up has been further refactored. This is to highlight that the per-cpu
distributor interface should be initialised only when the core was originally
powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API
was used.
3. In the case of CSS platforms, the system power domain restore helper
`arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish`
handler as the system power domain is always expected to be initialized when
the `on_finish` handler is invoked.
Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
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
This patch adds watchdog support on ARM platforms (FVP and Juno).
A secure instance of SP805 is used as Trusted Watchdog. It is
entirely managed in BL1, being enabled in the early platform setup
hook and disabled in the exit hook. By default, the watchdog is
enabled in every build (even when TBB is disabled).
A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
has been introduced to allow the user to disable the watchdog at
build time. This feature may be used for testing or debugging
purposes.
Specific error handlers for Juno and FVP are also provided in this
patch. These handlers will be called after an image load or
authentication error. On FVP, the Table of Contents (ToC) in the FIP
is erased. On Juno, the corresponding error code is stored in the
V2M Non-Volatile flags register. In both cases, the CPU spins until
a watchdog reset is generated after 256 seconds (as specified in
the TBBR document).
Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
FVP and Juno platforms include a NOR flash memory to store and
load the FIP, the kernel or a ramdisk. This NOR flash is arranged
as 2 x 16 bit flash devices and can be programmed using CFI
standard commands.
This patch provides a basic API to write single 32 bit words of
data into the NOR flash. Functions to lock/unlock blocks against
erase or write operations are also provided.
Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
Normally, in the FVP port, secondary CPUs are immediately powered
down if they are powered on at reset. However, when booting an EL3
payload, we need to keep them powered on as the requirement is for
all CPUs to enter the EL3 payload image. This patch puts them in a
holding pen instead of powering them off.
Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
The default reset values for the L2 Data & Tag RAM latencies on the
Cortex-A72 on Juno R2 are not suitable. This patch modifies
the Juno platform reset handler to configure the right settings
on Juno R2.
Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8
This patch splits the Juno reset handler in 4 distinct pieces:
- Detection of the board revision;
- Juno R0 specific handler;
- Juno R1 specific handler;
- Juno R2 specific handler.
Depending on the board revision, the appropriate handler is called.
This makes the code easier to understand and maintain.
This patch is mainly cosmetic. The only functional change introduced
is that the Juno platform reset handler will now spin infinitely if
the board revision is not recognised. Previously, it would have
assumed that it was running on Juno R1 in this case.
Change-Id: I54ed77c4665085ead9d1573316c9c884d7d3ffa0
Cortex-A72 library support is now compiled into the Juno platform port to go
with the existing A53/A57 support. This enables a single set of Juno TF
binaries to run on Juno R0, R1 and R2 boards.
Change-Id: I4a601dc4f671e98bdb19d98bbb66f02f0d8b7fc7
Patch 7e26fe1f deprecates IO specific return definitions in favour
of standard errno codes. This patch removes those definitions
and its usage from the IO framework, IO drivers and IO platform
layer. Following this patch, standard errno codes must be used
when checking the return value of an IO function.
Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
This patch adds the capability to power down at system power domain level
on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers
are modified to add support for power management operations at system
power domain level. A new helper for populating `get_sys_suspend_power_state`
handler in plat_psci_ops is defined. On entering the system suspend state,
the SCP powers down the SYSTOP power domain on the SoC and puts the memory
into retention mode. On wakeup from the power down, the system components
on the CSS will be reinitialized by the platform layer and the PSCI client
is responsible for restoring the context of these system components.
According to PSCI Specification, interrupts targeted to cores in PSCI CPU
SUSPEND should be able to resume it. On Juno, when the system power domain
is suspended, the GIC is also powered down. The SCP resumes the final core
to be suspend when an external wake-up event is received. But the other
cores cannot be woken up by a targeted interrupt, because GIC doesn't
forward these interrupts to the SCP. Due to this hardware limitation,
we down-grade PSCI CPU SUSPEND requests targeted to the system power domain
level to cluster power domain level in `juno_validate_power_state()`
and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c.
A system power domain resume helper `arm_system_pwr_domain_resume()` is
defined for ARM standard platforms which resumes/re-initializes the
system components on wakeup from system suspend. The security setup also
needs to be done on resume from system suspend, which means
`plat_arm_security_setup()` must now be included in the BL3-1 image in
addition to previous BL images if system suspend need to be supported.
Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
This patch implements the necessary topology changes for supporting
system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
specific. In addition, the `arm_power_domain_tree_desc[]` and
`arm_pm_idle_states[]` are modified to support the system power domain
at level 2. With this patch, even though the power management operations
involving the system power domain will not return any error, the platform
layer will silently ignore any operations to the power domain. The actual
power management support for the system power domain will be added later.
Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
Currently all ARM CSS platforms which include css_helpers.S use the same
strong definition of `plat_arm_calc_core_pos`. This patch allows these CSS
platforms to define their own strong definition of this function.
* Replace the strong definition of `plat_arm_calc_core_pos` in
css_helpers.S with a utility function `css_calc_core_pos_swap_cluster`
does the same thing (swaps cluster IDs). ARM CSS platforms may choose
to use this function or not.
* Add a Juno strong definition of `plat_arm_calc_core_pos`, which uses
`css_calc_core_pos_swap_cluster`.
Change-Id: Ib5385ed10e44adf6cd1398a93c25973eb3506d9d
This patch does the following reorganization to psci power management (PM)
handler setup for ARM standard platform ports :
1. The mailbox programming required during `plat_setup_psci_ops()` is identical
for all ARM platforms. Hence the implementation of this API is now moved
to the common `arm_pm.c` file. Each ARM platform now must define the
PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
as ARM_SHARED_RAM_BASE.
2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
exported via `plat_arm_psci_pm_ops`. This allows the common implementation
of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
In the case of CSS platforms, a default weak implementation of the same is
provided in `css_pm.c` which can be overridden by each CSS platform.
3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
made library functions and a new header file `css_pm.h` is added to export
these generic PM handlers. This allows the platform to reuse the
adequate CSS PM handlers and redefine others which need to be customized
when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.
Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
Currently, on ARM platforms(ex. Juno) non-secure access to specific
peripheral regions, config registers which are inside and outside CSS
is done in the soc_css_security_setup(). This patch separates the CSS
security setup from the SOC security setup in the css_security_setup().
The CSS security setup involves programming of the internal NIC to
provide access to regions inside the CSS. This is needed only in
Juno, hence Juno implements it in its board files as css_init_nic400().
Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
On Juno and FVP platforms, the Non-Secure System timer corresponds
to frame 1. However, this is a platform-specific decision and it
shouldn't be hard-coded. Hence, this patch introduces
PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms
to specify the correct non-secure timer frame.
Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba
This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
support different TrustZone Controller base addresses across ARM platforms.
Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd
ARM TF configures all interrupts as non-secure except those which
are present in irq_sec_array. This patch updates the irq_sec_array
with the missing secure interrupts for ARM platforms.
It also updates the documentation to be inline with the latest
implementation.
FixesARM-software/tf-issues#312
Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
This patch adds the necessary documentation updates to porting_guide.md
for the changes in the platform interface mandated as a result of the new
PSCI Topology and power state management frameworks. It also adds a
new document `platform-migration-guide.md` to aid the migration of existing
platform ports to the new API.
The patch fixes the implementation and callers of
plat_is_my_cpu_primary() to use w0 as the return parameter as implied by
the function signature rather than x0 which was used previously.
Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b
This patch implements the platform power managment handler to verify
non secure entrypoint for ARM platforms. The handler ensures that the
entry point specified by the normal world during CPU_SUSPEND, CPU_ON
or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
DRAM.
Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
Now that the FVP mailbox is no longer zeroed, the function
platform_mem_init() does nothing both on FVP and on Juno. Therefore,
this patch pools it as the default implementation on ARM platforms.
Change-Id: I007220f4531f15e8b602c3368a1129a5e3a38d91
Since there is a unique warm reset entry point, the FVP and Juno
port can use a single mailbox instead of maintaining one per core.
The mailbox gets programmed only once when plat_setup_psci_ops()
is invoked during PSCI initialization. This means mailbox is not
zeroed out during wakeup.
Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
This patch adds support to the Juno and FVP ports for composite power states
with both the original and extended state-id power-state formats. Both the
platform ports use the recommended state-id encoding as specified in
Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
ARM_RECOM_STATE_ID_ENC is used to include this support.
By default, to maintain backwards compatibility, the original power state
parameter format is used and the state-id field is expected to be zero.
Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
This patch migrates ARM reference platforms, Juno and FVP, to the new platform
API mandated by the new PSCI power domain topology and composite power state
frameworks. The platform specific makefiles now exports the build flag
ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.
Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.
Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto module and the image parser module to
authenticate the images in the Chain of Trust.
A new function 'load_auth_image()' has been implemented. When TBB
is enabled, this function will call the authentication module to
authenticate parent images following the CoT up to the root of
trust to finally load and authenticate the requested image.
The platform is responsible for picking up the right makefiles to
build the corresponding cryptographic and image parser libraries.
ARM platforms use the mbedTLS based libraries.
The platform may also specify what key algorithm should be used
to sign the certificates. This is done by declaring the 'KEY_ALG'
variable in the platform makefile. FVP and Juno use ECDSA keys.
On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
each to accommodate the ECDSA code.
REMOVED BUILD OPTIONS:
* 'AUTH_MOD'
Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
This patch extends the platform port by adding an API that returns
either the Root of Trust public key (ROTPK) or its hash. This is
usually stored in ROM or eFUSE memory. The ROTPK returned must be
encoded in DER format according to the following ASN.1 structure:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
In case the platform returns a hash of the key:
DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
keyDigest OCTET STRING
}
An implementation for ARM development platforms is provided in this
patch. When TBB is enabled, the ROTPK hash location must be specified
using the build option 'ARM_ROTPK_LOCATION'. Available options are:
- 'regs' : return the ROTPK hash stored in the Trusted
root-key storage registers.
- 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
BL2 binaries. This hash has been obtained from the development
RSA public key located in 'plat/arm/board/common/rotpk'.
On FVP, the number of MMU tables has been increased to map and
access the ROTPK registers.
A new file 'board_common.mk' has been added to improve code sharing
in the ARM develelopment platforms.
Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in the platform function plat_get_image_source(). For
a given image name, it returns the handle to the image file which
involves comparing images names. In addition, if the image is
packaged in a FIP, a name comparison is required to find the UUID
for the image. This method is not optimal.
This patch changes the interface between the generic and platform
code with regard to identifying images. The platform port must now
allocate a unique number (ID) for every image. The generic code will
use the image ID instead of the name to access its attributes.
As a result, the plat_get_image_source() function now takes an image
ID as an input parameter. The organisation of data structures within
the IO framework has been rationalised to use an image ID as an index
into an array which contains attributes of the image such as UUID and
name. This prevents the name comparisons.
A new type 'io_uuid_spec_t' has been introduced in the IO framework
to specify images identified by UUID (i.e. when the image is contained
in a FIP file). There is no longer need to maintain a look-up table
[iname_name --> uuid] in the io_fip driver code.
Because image names are no longer mandatory in the platform port, the
debug messages in the generic code will show the image identifier
instead of the file name. The platforms that support semihosting to
load images (i.e. FVP) must provide the file names as definitions
private to the platform.
The ARM platform ports and documentation have been updated accordingly.
All ARM platforms reuse the image IDs defined in the platform common
code. These IDs will be used to access other attributes of an image in
subsequent patches.
IMPORTANT: applying this patch breaks compatibility for platforms that
use TF BL1 or BL2 images or the image loading code. The platform port
must be updated to match the new interface.
Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
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>
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required between the first and subsequent invocations
of the reset handling code, this should be detected at runtime.
On Juno, the platform reset handler is now always compiled in.
This means it is now executed twice on the cold boot path, first in
BL1 then in BL3-1, and it has the same behavior in both cases. It is
also executed twice on the warm boot path, first in BL1 then in the
PSCI entrypoint code.
Also update the documentation to reflect this change.
NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.
Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
This patch fixes the incorrect bit width used to extract the wakeup
reason from PSYSR in platform_get_entrypoint() function. This defect
did not have any observed regression.
Change-Id: I42652dbffc99f5bf50cc86a5878f28d730720d9a
On ARM standard platforms, snoop and DVM requests used to be enabled
for the primary CPU's cluster only in the first EL3 bootloader.
In other words, if the platform reset into BL1 then CCI coherency
would be enabled by BL1 only, and not by BL3-1 again.
However, this doesn't cater for platforms that use BL3-1 along with
a non-TF ROM bootloader that doesn't enable snoop and DVM requests.
In this case, CCI coherency is never enabled.
This patch modifies the function bl31_early_platform_setup() on
ARM standard platforms so that it always enables snoop and DVM
requests regardless of whether earlier bootloader stages have
already done it. There is no harm in executing this code twice.
ARM Trusted Firmware Design document updated accordingly.
Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c
Fix the return type of the FVP `plat_arm_topology_setup` function
to be `void` instead of `int` to match the declaration in
`plat_arm.h`.
This does not result in any change in behavior.
Change-Id: I62edfa7652b83bd26cffb7d167153959b38e37e7
Move the Juno port from plat/juno to plat/arm/board/juno. Also rename
some of the files so they are consistently prefixed with juno_.
Update the platform makefiles accordingly.
Change-Id: I0af6cb52a5fee7ef209107a1188b76a3c33a2a9f
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
This major change pulls out the common functionality from the
FVP and Juno platform ports into the following categories:
* (include/)plat/common. Common platform porting functionality that
typically may be used by all platforms.
* (include/)plat/arm/common. Common platform porting functionality
that may be used by all ARM standard platforms. This includes all
ARM development platforms like FVP and Juno but may also include
non-ARM-owned platforms.
* (include/)plat/arm/board/common. Common platform porting
functionality for ARM development platforms at the board
(off SoC) level.
* (include/)plat/arm/css/common. Common platform porting
functionality at the ARM Compute SubSystem (CSS) level. Juno
is an example of a CSS-based platform.
* (include/)plat/arm/soc/common. Common platform porting
functionality at the ARM SoC level, which is not already defined
at the ARM CSS level.
No guarantees are made about the backward compatibility of
functionality provided in (include/)plat/arm.
Also remove any unnecessary variation between the ARM development
platform ports, including:
* Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
Juno implementation, which copies the information from BL2 memory
instead of expecting it to persist in shared memory.
* Unify the TZC configuration. There is no need to add a region
for SCP in Juno; it's enough to simply not allow any access to
this reserved region. Also set region 0 to provide no access by
default instead of assuming this is the case.
* Unify the number of memory map regions required for ARM
development platforms, although the actual ranges mapped for each
platform may be different. For the FVP port, this reduces the
mapped peripheral address space.
These latter changes will only be observed when the platform ports
are migrated to use the new common platform code in subsequent
patches.
Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
Soby Mathew
danh-arm
Juan Castillo
David Wang
Antonio Nino Diaz
Vikram Kanigiri
Sandrine Bailleux
Yatharth Kochar
Achin Gupta
Brendan Jackman
Ryan Harkin