| 8b779620 | 24-Mar-2015 |
Kévin Petit <kevin.petit@arm.com> |
Add support to indicate size and end of assembly functions
In order for the symbol table in the ELF file to contain the size of functions written in assembly, it is necessary to report it to the ass
Add support to indicate size and end of assembly functions
In order for the symbol table in the ELF file to contain the size of functions written in assembly, it is necessary to report it to the assembler using the .size directive.
To fulfil the above requirements, this patch introduces an 'endfunc' macro which contains the .endfunc and .size directives. It also adds a .func directive to the 'func' assembler macro.
The .func/.endfunc have been used so the assembler can fail if endfunc is omitted.
Fixes ARM-Software/tf-issues#295
Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc Signed-off-by: Kévin Petit <kevin.petit@arm.com>
show more ...
|
| 541d7881 | 17-Mar-2015 |
danh-arm <dan.handley@arm.com> |
Merge pull request #269 from vikramkanigiri/vk/common-cci
Common driver for ARM cache coherent Interconnects |
| a7e98ad5 | 04-Mar-2015 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Add macro to calculate number of elements in an array
This patch defines the ARRAY_SIZE macro for calculating number of elements in an array and uses it where appropriate.
Change-Id: I72746a9229f0b
Add macro to calculate number of elements in an array
This patch defines the ARRAY_SIZE macro for calculating number of elements in an array and uses it where appropriate.
Change-Id: I72746a9229f0b259323972b498b9a3999731bc9b
show more ...
|
| dad25049 | 05-Feb-2015 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Enable type-checking of arguments passed to printf() et al.
This patch modifies the declarations of the functions printf() et al. and adds the right GCC attribute to request the compiler to check th
Enable type-checking of arguments passed to printf() et al.
This patch modifies the declarations of the functions printf() et al. and adds the right GCC attribute to request the compiler to check the type of the arguments passed to these functions against the given format string. This will ensure that the compiler outputs warning messages like the following whenever it detects an inconsistency:
file.c:42: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’
It also fixes the type mismatch inconsistencies that it revealed across the code base.
NOTE: THIS PATCH MAY FORCE PLATFORM PORTS OR SP/SPDS THAT USE THE PRINTF FAMILY OF FUNCTIONS TO FIX ANY TYPE MISMATCH INCONSISTENCIES.
Change-Id: If36bb54ec7d6dd2cb4791d89b02a24ac13fd2df6
show more ...
|
| 40febc3a | 13-Jan-2015 |
Juan Castillo <juan.castillo@arm.com> |
TBB: add authentication module interface
This patch provides an API to access the authentication module that will be used to verify the authenticity of the images loaded into memory as part of the T
TBB: add authentication module interface
This patch provides an API to access the authentication module that will be used to verify the authenticity of the images loaded into memory as part of the Trusted Board Boot process.
To include the authentication module as part of the build, set the boolean build option TRUSTED_BOARD_BOOT. One single authentication module must be registered at build time by setting the build option AUTH_MOD=<mod_name>. All authentication modules will be located in 'common/auth/<mod_name>' and must present the <mod_name>.mk file that will be included by the build system to compile the module sources.
To create an authentication module, an instance of auth_mod_t called 'auth_mod' must be declared in the module sources. The initialization and verification functions provided by the module will be exported through the function pointers specified when declaring this instance.
If an authentication module includes third party sources that do not adhere to the C99 standard, the -pedantic option may be removed from the build options by setting the flag DISABLE_PEDANTIC in the module file <mod_name>.mk.
Change-Id: I080bb04bd421029bcdf22ec2c63807afbf061dcd
show more ...
|
| b7124ea7 | 04-Nov-2014 |
Juan Castillo <juan.castillo@arm.com> |
TBB: add support to include certificates in a FIP image
This patch extends the FIP tool to include the certificates generated by the 'cert_create' tool.
If GENERATE_COT build option is enabled, the
TBB: add support to include certificates in a FIP image
This patch extends the FIP tool to include the certificates generated by the 'cert_create' tool.
If GENERATE_COT build option is enabled, the Makefile adds the certificates as dependencies to create the FIP file. Thus, make target 'fip' will also build the certificates as part of the Trusted Firmware build process.
Change-Id: I5eee500da7f7be6cfb6e3df0423599739d260074
show more ...
|
| 79a97b2e | 20-Nov-2014 |
Yatharth Kochar <yatharth.kochar@arm.com> |
Call reset handlers upon BL3-1 entry.
This patch adds support to call the reset_handler() function in BL3-1 in the cold and warm boot paths when another Boot ROM reset_handler() has already run.
Th
Call reset handlers upon BL3-1 entry.
This patch adds support to call the reset_handler() function in BL3-1 in the cold and warm boot paths when another Boot ROM reset_handler() has already run.
This means the BL1 and BL3-1 versions of the CPU and platform specific reset handlers may execute different code to each other. This enables a developer to perform additional actions or undo actions already performed during the first call of the reset handlers e.g. apply additional errata workarounds.
Typically, the reset handler will be first called from the BL1 Boot ROM. Any additional functionality can be added to the reset handler when it is called from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used to identify whether this is the first version of the reset handler code to be executed or an overridden version of the code.
The Cortex-A57 errata workarounds are applied only if they have not already been applied.
Fixes ARM-software/tf-issue#275
Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
show more ...
|
| aecc0840 | 19-Aug-2014 |
Soby Mathew <soby.mathew@arm.com> |
Rework use of labels in assembly macros.
This patch provides a workaround for the ASM_ASSERT label issue and also reworks the use of labels in assembly macros. If the caller of the ASM_ASSERT macro
Rework use of labels in assembly macros.
This patch provides a workaround for the ASM_ASSERT label issue and also reworks the use of labels in assembly macros. If the caller of the ASM_ASSERT macro happened to use the label '1' to jump past the ASM_ASSERT macro, it would not have worked since the ASM_ASSERT macro internally used the same label. Hence, as a workaround, this patch makes the label a high number in the expectation that the caller will never use it.
Also updated the other assembly macros using numerical labels to named lables.
Change-Id: Iec892359db84f2391ad2a83a92141c4d7049776a
show more ...
|
| 289c28a8 | 08-Aug-2014 |
Dan Handley <dan.handley@arm.com> |
Add concept of console output log levels
Create new LOG_LEVEL build option, which controls the amount of console output compiled into the build. This should be one of the following:
0 (LOG_LEV
Add concept of console output log levels
Create new LOG_LEVEL build option, which controls the amount of console output compiled into the build. This should be one of the following:
0 (LOG_LEVEL_NONE) 10 (LOG_LEVEL_NOTICE) 20 (LOG_LEVEL_ERROR) 30 (LOG_LEVEL_WARNING) 40 (LOG_LEVEL_INFO) 50 (LOG_LEVEL_VERBOSE)
All log output up to and including the log level is compiled into the build. The default value is 40 in debug builds and 20 in release builds.
Complement the existing INFO, WARN and ERROR console output macros with NOTICE and VERBOSE macros, which are conditionally compiled in depending on the value of LOG_LEVEL.
Fixes ARM-software/tf-issues#232
Change-Id: I951e2f333e7b90fc4b1060741d9a6db699d5aa72
show more ...
|
| dd2bdee6 | 28-Jul-2014 |
danh-arm <dan.handley@arm.com> |
Merge pull request #177 from jcastillo-arm/jc/tf-issues/096
Rework incorrect use of assert() and panic() in codebase |
| d3280beb | 05-Jun-2014 |
Juan Castillo <juan.castillo@arm.com> |
Rework incorrect use of assert() and panic() in codebase
Assert a valid security state using the macro sec_state_is_valid(). Replace assert() with panic() in those cases that might arise because of
Rework incorrect use of assert() and panic() in codebase
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.
Fixes ARM-software/tf-issues#96
Change-Id: I51e9ef0439fd5ff5e0edfef49050b69804bf14d5
show more ...
|
| 626ed510 | 25-Jun-2014 |
Soby Mathew <soby.mathew@arm.com> |
Rework the crash reporting in BL3-1 to use less stack
This patch reworks the crash reporting mechanism to further optimise the stack and code size. The reporting makes use of assembly console functi
Rework the crash reporting in BL3-1 to use less stack
This patch reworks the crash reporting mechanism to further optimise the stack and code size. The reporting makes use of assembly console functions to avoid calling C Runtime to report the CPU state. The crash buffer requirement is reduced to 64 bytes with this implementation. The crash buffer is now part of per-cpu data which makes retrieving the crash buffer trivial.
Also now panic() will use crash reporting if invoked from BL3-1.
Fixes ARM-software/tf-issues#199
Change-Id: I79d27a4524583d723483165dc40801f45e627da5
show more ...
|
| bc920128 | 14-Jul-2014 |
Soby Mathew <soby.mathew@arm.com> |
Implement an assert() callable from assembly code
The patch implements a macro ASM_ASSERT() which can be invoked from assembly code. When assertion happens, file name and line number of the check is
Implement an assert() callable from assembly code
The patch implements a macro ASM_ASSERT() which can be invoked from assembly code. When assertion happens, file name and line number of the check is written to the crash console.
Fixes ARM-software/tf-issues#95
Change-Id: I6f905a068e1c0fa4f746d723f18df60daaa00a86
show more ...
|
| c67b09bd | 14-Jul-2014 |
Soby Mathew <soby.mathew@arm.com> |
Introduce crash console APIs for crash reporting
This patch introduces platform APIs to initialise and print a character on a designated crash console. For the FVP platform, PL011_UART0 is the desig
Introduce crash console APIs for crash reporting
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
show more ...
|
| aaa3e722 | 30-Jun-2014 |
Juan Castillo <juan.castillo@arm.com> |
Add support for printing version at runtime
Print out Trusted Firmware version at runtime at each BL stage. Message consists of TF version as defined statically in the Makefile (e.g. v0.4), build mo
Add support for printing version at runtime
Print out Trusted Firmware version at runtime at each BL stage. Message consists of TF version as defined statically in the Makefile (e.g. v0.4), build mode (debug|release) and a customizable build string:
1. By defining BUILD_STRING in command line when building TF 2. Default string is git commit ID 3. Empty if git meta-data is not available
Fixes ARM-software/tf-issues#203
Change-Id: I5c5ba438f66ab68810427d76b49c5b9177a957d6
show more ...
|
| b79af934 | 12-Jun-2014 |
Soby Mathew <soby.mathew@arm.com> |
Implement a leaner printf for Trusted Firmware
This patch implements a "tf_printf" which supports only the commonly used format specifiers in Trusted Firmware, which uses a lot less stack space than
Implement a leaner printf for Trusted Firmware
This patch implements a "tf_printf" which supports only the commonly used format specifiers in Trusted Firmware, which uses a lot less stack space than the stdlib printf function.
Fixes ARM-software/tf-issues#116
Change-Id: I7dfa1944f4c1e634b3e2d571f49afe02d109a351
show more ...
|
| 8f55dfb4 | 24-Jun-2014 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Remove concept of top/bottom image loading
This concept is no longer required since we now support loading of images at fixed addresses only.
The image loader now automatically detects the position
Remove concept of top/bottom image loading
This concept is no longer required since we now support loading of images at fixed addresses only.
The image loader now automatically detects the position of the image inside the current memory layout and updates the layout such that memory fragmentation is minimised.
The 'attr' field of the meminfo data structure, which used to hold the bottom/top loading information, has been removed. Also the 'next' field has been removed as it wasn't used anywhere.
The 'init_bl2_mem_layout()' function has been moved out of common code and put in BL1-specific code. It has also been renamed into 'bl1_init_bl2_mem_layout'.
Fixes ARM-software/tf-issues#109
Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d
show more ...
|
| 167a9357 | 04-Jun-2014 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Initialise CPU contexts from entry_point_info
Consolidate all BL3-1 CPU context initialization for cold boot, PSCI and SPDs into two functions: * The first uses entry_point_info to initialize the r
Initialise CPU contexts from entry_point_info
Consolidate all BL3-1 CPU context initialization for cold boot, PSCI and SPDs into two functions: * The first uses entry_point_info to initialize the relevant cpu_context for first entry into a lower exception level on a CPU * The second populates the EL1 and EL2 system registers as needed from the cpu_context to ensure correct entry into the lower EL
This patch alters the way that BL3-1 determines which exception level is used when first entering EL1 or EL2 during cold boot - this is now fully determined by the SPSR value in the entry_point_info for BL3-3, as set up by the platform code in BL2 (or otherwise provided to BL3-1).
In the situation that EL1 (or svc mode) is selected for a processor that supports EL2, the context management code will now configure all essential EL2 register state to ensure correct execution of EL1. This allows the platform code to run non-secure EL1 payloads directly without requiring a small EL2 stub or OS loader.
Change-Id: If9fbb2417e82d2226e47568203d5a369f39d3b0f
show more ...
|
| dec5e0d1 | 15-May-2014 |
Dan Handley <dan.handley@arm.com> |
Move BL porting functions into platform.h
Some platform porting functions were in BL specific header files. These have been moved to platform.h so that all porting functions are in the same place. T
Move BL porting functions into platform.h
Some platform porting functions were in BL specific header files. These have been moved to platform.h so that all porting functions are in the same place. The functions are now grouped by BL. Obsolete BL headers files have been removed.
Also, the weak declaration of the init_bl2_mem_layout() function has been moved out the header file and into the source file (bl_common.c) using the more succinct #pragma syntax. This mitigates the risk of 2 weak definitions being created and the wrong one being picked up by the compiler.
Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83
show more ...
|
| c6bc0710 | 14-May-2014 |
Dan Handley <dan.handley@arm.com> |
Remove extern keyword from function declarations
Function declarations implicitly have external linkage so do not need the extern keyword.
Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32 |
| dbad1bac | 24-Apr-2014 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Add support for BL3-1 as a reset vector
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 b
Add support for BL3-1 as a reset vector
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
Fixes ARM-software/TF-issues#133 Fixes ARM-software/TF-issues#20
Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570
show more ...
|
| 6871c5d3 | 16-May-2014 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Rework memory information passing to BL3-x images
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
Rework memory information passing to BL3-x images
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
show more ...
|
| 4112bfa0 | 15-Apr-2014 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Populate BL31 input parameters as per new spec
This patch is based on spec published at https://github.com/ARM-software/tf-issues/issues/133
It rearranges the bl31_args struct into bl31_params and
Populate BL31 input parameters as per new spec
This patch is based on spec published at https://github.com/ARM-software/tf-issues/issues/133
It rearranges the bl31_args struct into bl31_params and bl31_plat_params which provide the information needed for Trusted firmware and platform specific data via x0 and x1
On the FVP platform BL3-1 params and BL3-1 plat params and its constituents are stored at the start of TZDRAM.
The information about memory availability and size for BL3-1, BL3-2 and BL3-3 is moved into platform specific data.
Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9
show more ...
|
| 29fb905d | 15-May-2014 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Rework handover interface between BL stages
This patch reworks the handover interface from: BL1 to BL2 and BL2 to BL3-1. It removes the raise_el(), change_el(), drop_el() and run_image() functions a
Rework handover interface between BL stages
This patch reworks the handover interface from: BL1 to BL2 and BL2 to BL3-1. It removes the raise_el(), change_el(), drop_el() and run_image() functions as they catered for code paths that were never exercised. BL1 calls bl1_run_bl2() to jump into BL2 instead of doing the same by calling run_image(). Similarly, BL2 issues the SMC to transfer execution to BL3-1 through BL1 directly. Only x0 and x1 are used to pass arguments to BL31. These arguments and parameters for running BL3-1 are passed through a reference to a 'el_change_info_t' structure. They were being passed value in general purpose registers earlier.
Change-Id: Id4fd019a19a9595de063766d4a66295a2c9307e1
show more ...
|
| 23ff9baa | 13-May-2014 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Introduce macros to manipulate the SPSR
This patch introduces macros (SPSR_64 and SPSR_32) to create a SPSR for both aarch32 and aarch64 execution states. These macros allow the user to set fields i
Introduce macros to manipulate the SPSR
This patch introduces macros (SPSR_64 and SPSR_32) to create a SPSR for both aarch32 and aarch64 execution states. These macros allow the user to set fields in the SPSR depending upon its format. The make_spsr() function which did not allow manipulation of all the fields in the aarch32 SPSR has been replaced by these new macros.
Change-Id: I9425dda0923e8d5f03d03ddb8fa0e28392c4c61e
show more ...
|