* Create cci_init() function in CCI-400 driver to allow platform
to provide arguments needed by the driver (i.e. base address
and cluster indices for the ACE slave interfaces).
* Rename cci_(en|dis)able_coherency to
cci_(en|dis)able_cluster_coherency to make it clear that
the driver only enables/disables the coherency of CPU
clusters and not other devices connected to the CCI-400.
* Update FVP port to use new cci_init() function and remove
unnecessary CCI defintions from platform_def.h. Also rename
fvp_cci_setup() to fvp_cci_enable() to more clearly
differentiate between CCI initialization and enabling.
THIS CHANGE REQUIRES PLATFORM PORTS THAT USE THE CCI-400 DRIVER
TO BE UPDATED
FixesARM-software/tf-issues#168
Change-Id: I1946a51409b91217b92285b6375082619f607fec
This patch groups the current contents of the Trusted DRAM region at
address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in
a single shared memory area that may be allocated to Trusted SRAM
(default) or Trusted DRAM at build time by setting the
FVP_SHARED_DATA_LOCATION make variable. The size of this shared
memory is 4096 bytes.
The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM'
is not currently supported due to restrictions in the maximum number
of mmu tables that can be created.
Documentation has been updated to reflect these changes.
FixesARM-software/tf-issues#100
Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
BLn_BASE and BLn_LIMIT definitions have been updated and are based on
these new memory regions.
The available memory for each bootloader in the linker script is
defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
region.
TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
the platform porting.
FVP common definitions are defined in fvp_def.h while platform_def.h
contains exclusively (with a few exceptions) the definitions that are
mandatory in the porting guide. Therefore, platform_def.h now includes
fvp_def.h instead of the other way around.
Porting guide has been updated to reflect these changes.
Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
The purpose of platform_is_primary_cpu() is to determine after reset
(BL1 or BL3-1 with reset handler) if the current CPU must follow the
cold boot path (primary CPU), or wait in a safe state (secondary CPU)
until the primary CPU has finished the system initialization.
This patch removes redundant calls to platform_is_primary_cpu() in
subsequent bootloader entrypoints since the reset handler already
guarantees that code is executed exclusively on the primary CPU.
Additionally, this patch removes the weak definition of
platform_is_primary_cpu(), so the implementation of this function
becomes mandatory. Removing the weak symbol avoids other
bootloaders accidentally picking up an invalid definition in case the
porting layer makes the real function available only to BL1.
The define PRIMARY_CPU is no longer mandatory in the platform porting
because platform_is_primary_cpu() hides the implementation details
(for instance, there may be platforms that report the primary CPU in
a system register). The primary CPU definition in FVP has been moved
to fvp_def.h.
The porting guide has been updated accordingly.
FixesARM-software/tf-issues#219
Change-Id: If675a1de8e8d25122b7fef147cb238d939f90b5e
Assert a valid security state using the macro sec_state_is_valid().
Replace assert() with panic() in those cases that might arise
because of runtime errors and not programming errors.
Replace panic() with assert() in those cases that might arise
because of programming errors.
FixesARM-software/tf-issues#96
Change-Id: I51e9ef0439fd5ff5e0edfef49050b69804bf14d5
This patch introduces platform APIs to initialise and
print a character on a designated crash console.
For the FVP platform, PL011_UART0 is the designated
crash console. The platform porting guide is also updated
to document the new APIs.
Change-Id: I5e97d8762082e0c88c8c9bbb479353eac8f11a66
This patch adds a 'flags' parameter to each exception level specific function
responsible for enabling the MMU. At present only a single flag which indicates
whether the data cache should also be enabled is implemented. Subsequent patches
will use this flag when enabling the MMU in the warm boot paths.
Change-Id: I0eafae1e678c9ecc604e680851093f1680e9cefa
platform_get_entrypoint() did not consider that a wakeup due to
System Reset Pin (by reading the power controller's PSYSR) requires
a cold boot. As a result, the code would execute the warm boot path
and eventually panic because entrypoint mailboxes are empty.
This patch ensures that the following wake-up reasons result in cold
boot:
- Cold Power-on
- System Reset Pin (includes reset by software)
FixesARM-software/tf-issues#217
Change-Id: I65ae0a0f7a46548b575900a5aac107d352b0e2cd
Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM
GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform
specific inputs in the arm_gic_setup() function so that the driver
has no explicit dependency on platform code.
Provide weak implementations of the platform interrupt controller
API in a new file, plat/common/plat_gic.c. These simply call through
to the ARM GIC driver.
Move the only remaining FVP GIC function, fvp_gic_init() to
plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c
FixesARM-software/tf-issues#182
Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21
Changed the fvp_config array in fvp_common.c into a struct and
moved into a new optional common platform header,
include/plat/common/plat_config.h. Removed the config definitions
in fvp_def.h and updated all references to the platform config.
This makes the interface to the platform config cleaner and uses
a little less RAM.
FixesARM-software/tf-issues#180
Change-Id: I58dd7b3c150f24f7ee230a26fd57c827853ba803
The code in the FVP port which checks the platform type and
revision information in the SYS_ID register strictly supported
only the first revision of the Base and Foundation FVPs.
The current check also does not reflect the fact that the
board revision field is 'local' to the board type (HBI field).
Support for a new Foundation model is required now, and the
checking code is relaxed to allow execution (with a diagnostic)
on unrecognised revisions of the Base and Foundation FVP.
Change-Id: I7cd3519dfb56954aafe5f52ce1fcea0ee257ba9f
This patch reworks FVP specific code responsible for determining
the entry point information for BL3-2 and BL3-3 stages when BL3-1
is configured as the reset handler.
Change-Id: Ia661ff0a6a44c7aabb0b6c1684b2e8d3642d11ec
This memory is not used by the FVP port and requires an additional
4KB translation table.
This patch removes the entry from the memory map and reduces the
number of allocated translation tables.
FixesARM-software/tf-issues#196
Change-Id: I5b959e4fe92f5f892ed127c40dbe6c85eed3ed72
Current ATF uses a direct physical-to-virtual mapping, that is, a physical
address is mapped to the same address in the virtual space. For example,
physical address 0x8000_0000 is mapped to 0x8000_0000 virtual. This
approach works fine for FVP as all its physical addresses fall into 0 to
4GB range. But for other platform where all I/O addresses are 48-bit long,
If we follow the same direct mapping, we would need virtual address range
from 0 to 0x8fff_ffff_ffff, which is about 144TB. This requires a
significant amount of memory for MMU tables and it is not necessary to use
that much virtual space in ATF.
The patch is to enable mapping a physical address range to an arbitrary
virtual address range (instead of flat mapping)
Changed "base" to "base_va" and added "base_pa" in mmap_region_t and
modified functions such as mmap_add_region and init_xlation_table etc.
FixesARM-software/tf-issues#158
Previously, the enable_mmu_elX() functions were implicitly part of
the platform porting layer since they were included by generic
code. These functions have been placed behind 2 new platform
functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu().
These are weakly defined so that they can be optionally overridden
by platform ports.
Also, the enable_mmu_elX() functions have been moved to
lib/aarch64/xlat_tables.c for optional re-use by platform ports.
These functions are tightly coupled with the translation table
initialization code.
FixesARM-software/tf-issues#152
Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c
FVP specific files and functions containing the word "plat" have been
renamed to use the word "fvp" to distinguish them from the common
platform functionality and porting functions.
Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
Previously, platform.h contained many declarations and definitions
used for different purposes. This file has been split so that:
* Platform definitions used by common code that must be defined
by the platform are now in platform_def.h. The exact include
path is exported through $PLAT_INCLUDES in the platform makefile.
* Platform definitions specific to the FVP platform are now in
/plat/fvp/fvp_def.h.
* Platform API declarations specific to the FVP platform are now
in /plat/fvp/fvp_private.h.
* The remaining platform API declarations that must be ported by
each platform are still in platform.h but this file has been
moved to /include/plat/common since this can be shared by all
platforms.
Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a
TZC-400 is configured to set the last 16MB of DRAM1 as secure memory and
the rest of DRAM as non-secure. Non-secure software must not attempt to
access the 16MB secure area.
Device tree files (sources and binaries) have been updated to match this
configuration, removing that memory from the Linux physical memory map.
To use UEFI and Linux with this patch, the latest version of UEFI and
the updated device tree files are required. Check the user guide in the
documentation for more details.
Replaced magic numbers with #define for memory region definition in the
platform security initialization function.
FixesARM-software/tf-issues#149
Change-Id: Ia5d070244aae6c5288ea0e6c8e89d92859522bfe
This change adds optional reset vector support to BL3-1
which means BL3-1 entry point can detect cold/warm boot,
initialise primary cpu, set up cci and mail box.
When using BL3-1 as a reset vector it is assumed that
the BL3-1 platform code can determine the location of
the BL3-2 images, or load them as there are no parameters
that can be passed to BL3-1 at reset.
It also fixes the incorrect initialisation of mailbox
registers on the FVP platform
This feature can be enabled by building the code with
make variable RESET_TO_BL31 set as 1
FixesARM-software/TF-issues#133FixesARM-software/TF-issues#20
Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570
The issues addressed in this patch are:
1. Remove meminfo_t from the common interfaces in BL3-x,
expecting that platform code will find a suitable mechanism
to determine the memory extents in these images and provide
it to the BL3-x images.
2. Remove meminfo_t and bl31_plat_params_t from all FVP BL3-x
code as the images use link-time information to determine
memory extents.
meminfo_t is still used by common interface in BL1/BL2 for
loading images
Change-Id: I4e825ebf6f515b59d84dc2bdddf6edbf15e2d60f
Instead of having a single version of the MMU setup functions for all
bootloader images that can execute either in EL3 or in EL1, provide
separate functions for EL1 and EL3. Each bootloader image can then
call the appropriate version of these functions. The aim is to reduce
the amount of code compiled in each BL image by embedding only what's
needed (e.g. BL1 to embed only EL3 variants).
Change-Id: Ib86831d5450cf778ae78c9c1f7553fe91274c2fa
The goal of these macros is to improve code readability by providing
a concise way to check whether we are running in the expected
exception level.
Change-Id: If9aebadfb6299a5196e9a582b442f0971d9909b1
Instead of using the system register helper functions to read
or write system registers, assembler coded functions should
use MRS/MSR instructions. This results in faster and more
compact code.
This change replaces all usage of the helper functions with
direct register accesses.
Change-Id: I791d5f11f257010bb3e6a72c6c5ab8779f1982b3
disable_mmu() cannot work as a C function as there is no control
over data accesses generated by the compiler between disabling and
cleaning the data cache. This results in reading stale data from
main memory.
As assembler version is provided for EL3, and a variant that also
disables the instruction cache which is now used by the BL1
exception handling function.
FixesARM-software/tf-issues#147
Change-Id: I0cf394d2579a125a23c2f2989c2e92ace6ddb1a6
The current code does not always use data and instruction
barriers as required by the architecture and frequently uses
barriers excessively due to their inclusion in all of the
write_*() helper functions.
Barriers should be used explicitly in assembler or C code
when modifying processor state that requires the barriers in
order to enable review of correctness of the code.
This patch removes the barriers from the helper functions and
introduces them as necessary elsewhere in the code.
PORTING NOTE: check any port of Trusted Firmware for use of
system register helper functions for reliance on the previous
barrier behaviour and add explicit barriers as necessary.
FixesARM-software/tf-issues#92
Change-Id: Ie63e187404ff10e0bdcb39292dd9066cb84c53bf
Reduce the number of header files included from other header
files as much as possible without splitting the files. Use forward
declarations where possible. This allows removal of some unnecessary
"#ifndef __ASSEMBLY__" statements.
Also, review the .c and .S files for which header files really need
including and reorder the #include statements alphabetically.
FixesARM-software/tf-issues#31
Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
Add tag names to all unnamed structs in header files. This
allows forward declaration of structs, which is necessary to
reduce header file nesting (to be implemented in a subsequent
commit).
Also change the typedef names across the codebase to use the _t
suffix to be more conformant with the Linux coding style. The
coding style actually prefers us not to use typedefs at all but
this is considered a step too far for Trusted Firmware.
Also change the IO framework structs defintions to use typedef'd
structs to be consistent with the rest of the codebase.
Change-Id: I722b2c86fc0d92e4da3b15e5cab20373dd26786f
Move the function prototypes from gic.h into either gic_v2.h or
gic_v3.h as appropriate. Update the source files to include the
correct headers.
Change-Id: I368cfda175cdcbd3a68f46e2332738ec49048e19
Make codebase consistent in its use of #include "" syntax for
user includes and #include <> syntax for system includes.
FixesARM-software/tf-issues#65
Change-Id: If2f7c4885173b1fd05ac2cde5f1c8a07000c7a33
Move the FVP power driver to a directory under the FVP platform
port as this is not a generically usable driver.
Change-Id: Ibc78bd88752eb3e3964336741488349ac345f4f0
- Use the TrustZone controller on Base FVP to program DRAM access
permissions. By default no access to DRAM is allowed if
'secure memory' is enabled on the Base FVP.
- The Foundation FVP does not have a TrustZone controller but instead
has fixed access permissions.
- Update FDTs for Linux to use timers at the correct security level.
- Starting the FVPs with 'secure memory' disabled is also supported.
Limitations:
Virtio currently uses a reserved NSAID. This will be corrected in
future FVP releases.
Change-Id: I0b6c003a7b5982267815f62bcf6eb82aa4c50a31
Remove redundant code in plat_secondary_cold_boot_setup() in
plat/fvp/aarch64/bl1_plat_helpers.S.
FixesARM-software/tf-issues#136
Change-Id: I98c0a46d95cfea33125e34e609c83dc2c97cd86e
The BL images share common stack management code which provides
one coherent and one cacheable stack for every CPU. BL1 and BL2
just execute on the primary CPU during boot and do not require
the additional CPU stacks. This patch provides separate stack
support code for UP and MP images, substantially reducing the
RAM usage for BL1 and BL2 for the FVP platform.
This patch also provides macros for declaring stacks and
calculating stack base addresses to improve consistency where
this has to be done in the firmware.
The stack allocation source files are now included via
platform.mk rather than the common BLx makefiles. This allows
each platform to select the appropriate MP/UP stack support
for each BL image.
Each platform makefile must be updated when including this
commit.
FixesARM-software/tf-issues#76
Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632
Rename the array "mmap" in plat/fvp/aarch64/plat_common.c to
"fvp_mmap", to avoid confusion with the array of the same name
in lib/arch/aarch64/xlat_tables.c
FixesARM-software/tf-issues#114
Change-Id: I61478c0070aa52d5dcf5d85af2f353f56c060cfb
BL3-1 architecture setup code programs the system counter frequency
into the CNTFRQ_EL0 register. This frequency is defined by the
platform, though. This patch introduces a new platform hook that
the architecture setup code can call to retrieve this information.
In the ARM FVP port, this returns the first entry of the frequency
modes table from the memory mapped generic timer.
All system counter setup code has been removed from BL1 as some
platforms may not have initialized the system counters at this stage.
The platform specific settings done exclusively in BL1 have been moved
to BL3-1. In the ARM FVP port, this consists in enabling and
initializing the System level generic timer. Also, the frequency change
request in the counter control register has been set to 0 to make it
explicit it's using the base frequency. The CNTCR_FCREQ() macro has been
fixed in this context to give an entry number rather than a bitmask.
In future, when support for firmware update is implemented, there
is a case where BL1 platform specific code will need to program
the counter frequency. This should be implemented at that time.
This patch also updates the relevant documentation.
It properly fixesARM-software/tf-issues#24
Change-Id: If95639b279f75d66ac0576c48a6614b5ccb0e84b
This extends the --gc-sections behaviour to the many assembler
support functions in the firmware images by placing each function
into its own code section. This is achieved by creating a 'func'
macro used to declare each function label.
FixesARM-software/tf-issues#80
Change-Id: I301937b630add292d2dec6d2561a7fcfa6fec690
Each ARM Trusted Firmware image should know in which EL it is running
and it should use the corresponding register directly instead of reading
currentEL and knowing which asm register to read/write
Change-Id: Ief35630190b6f07c8fbb7ba6cb20db308f002945
Remove the hard coding of all the MMU related registers with 0 and disable MMU
by clearing the M and C bit in SCTLR_ELx
Change-Id: I4a0b1bb14a604734b74c32eb31315d8504a7b8d8
This patch removes the 'CPU present' flag that's being set but not
referred or used anywhere else.
Change-Id: Iaf82bdb354134e0b33af16c7ba88eb2259b2682a
This patch adds a simple TSP as the BL3-2 image. The secure payload
executes in S-EL1. It paves the way for the addition of the TSP
dispatcher runtime service to BL3-1. The TSP and the dispatcher service
will serve as an example of the runtime firmware's ability to toggle
execution between the non-secure and secure states in response to SMC
request from the non-secure state. The TSP will be replaced by a
Trusted OS in a real system.
The TSP also exports a set of handlers which should be called in
response to a PSCI power management event e.g a cpu being suspended or
turned off. For now it runs out of Secure DRAM on the ARM FVP port and
will be moved to Secure SRAM later. The default translation table setup
code assumes that the caller is executing out of secure SRAM. Hence the
TSP exports its own translation table setup function.
The TSP only services Fast SMCs, is non-reentrant and non-interruptible.
It does arithmetic operations on two sets of four operands, one set
supplied by the non-secure client, and the other supplied by the TSP
dispatcher in EL3. It returns the result according to the Secure Monitor
Calling convention standard.
This TSP has two functional entry points:
- An initial, one-time entry point through which the TSP is initialized
and prepares for receiving further requests from secure
monitor/dispatcher
- A fast SMC service entry point through which the TSP dispatcher
requests secure services on behalf of the non-secure client
Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931
Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This patch factors out the ARM FVP specific code to create MMU
translation tables so that it is possible for a boot loader stage to
create a different set of tables instead of using the default ones.
The default translation tables are created with the assumption that
the calling boot loader stage executes out of secure SRAM. This might
not be true for the BL3_2 stage in the future.
A boot loader stage can define the `fill_xlation_tables()` function as
per its requirements. It returns a reference to the level 1
translation table which is used by the common platform code to setup
the TTBR_EL3.
This patch is a temporary solution before a larger rework of
translation table creation logic is introduced.
Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6
This patch moves the translation tables into their own section. This
saves space that would otherwise have been lost in padding due to page
table alignment constraints. The BL31 and BL32 bases have been
consequently adjusted.
Change-Id: Ibd65ae8a5ce4c4ea9a71a794c95bbff40dc63e65
Dan Handley
Juan Castillo
Soby Mathew
Achin Gupta
Andrew Thoelke
Vikram Kanigiri
Lin Ma
Sandrine Bailleux
Harry Liebel
Jeenu Viswambharan
Jon Medhurst