2014-05-23 |
Remove unused data declarations
...
Some data variables were declared but not used. These have been
removed.
Change-Id: I038632af3c32d88984cd25b886c43ff763269bf9
Dan Handley
authored
on 14 May 2014
Andrew Thoelke
committed
on 23 May 2014
|
Remove extern keyword from function declarations
...
Function declarations implicitly have external linkage so do not
need the extern keyword.
Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32
Dan Handley
authored
on 14 May 2014
Andrew Thoelke
committed
on 23 May 2014
|
Merge pull request #101 from sandrine-bailleux:sb/tf-issue-81-v2
Andrew Thoelke
committed
on 23 May 2014
|
Make the memory layout more flexible
...
Currently the platform code gets to define the base address of each
boot loader image. However, the linker scripts couteract this
flexibility by enforcing a fixed overall layout of the different
images. For example, they require that the BL3-1 image sits below
the BL2 image. Choosing BL3-1 and BL2 base addresses in such a way
that it violates this constraint makes the build fail at link-time.
This patch requires the platform code to now define a limit address
for each image. The linker scripts check that the image fits within
these bounds so they don't rely anymore on the position of a given
image in regard to the others.
Fixes ARM-software/tf-issues#163
Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c
Sandrine Bailleux
committed
on 23 May 2014
|
Make BL1 RO and RW base addresses configurable
...
BL1 RO and RW base address used to be fixed, respectively to the first
address of the Trusted ROM and the first address of the Trusted RAM.
Introduce new platform defines to configure the BL1 RO and RW base
addresses.
Change-Id: If26616513a47798593a4bb845a4b0fb37c867cd6
Sandrine Bailleux
committed
on 23 May 2014
|
Merge pull request #102 from achingupta:ag/tf-issues#104-v2
Andrew Thoelke
committed
on 23 May 2014
|
Merge pull request #100 from jcastillo-arm:jc/tf-issues/149-v4
Andrew Thoelke
committed
on 23 May 2014
|
2014-05-22 |
Introduce platform api to access an ARM GIC
...
This patch introduces a set of functions which allow generic firmware
code e.g. the interrupt management framework to access the platform
interrupt controller. APIs for finding the type and id of the highest
pending interrupt, acknowledging and EOIing an interrupt and finding
the security state of an interrupt have been added. It is assumed that
the platform interrupt controller implements the v2.0 of the ARM GIC
architecture specification. Support for v3.0 of the specification for
managing interrupts in EL3 and the platform port will be added in the
future.
Change-Id: Ib3a01c2cf3e3ab27806930f1be79db2b29f91bcf
Achin Gupta
committed
on 22 May 2014
|
Introduce interrupt registration framework in BL3-1
...
This patch introduces a framework for registering interrupts routed to
EL3. The interrupt routing model is governed by the SCR_EL3.IRQ and
FIQ bits and the security state an interrupt is generated in. The
framework recognizes three type of interrupts depending upon which
exception level and security state they should be handled in
i.e. Secure EL1 interrupts, Non-secure interrupts and EL3
interrupts. It provides an API and macros that allow a runtime service
to register an handler for a type of interrupt and specify the routing
model. The framework validates the routing model and uses the context
management framework to ensure that it is applied to the SCR_EL3 prior
to entry into the target security state. It saves the handler in
internal data structures. An API is provided to retrieve the handler
when an interrupt of a particular type is asserted. Registration is
expected to be done once by the primary CPU. The same handler and
routing model is used for all CPUs.
Support for EL3 interrupts will be added to the framework in the
future. A makefile flag has been added to allow the FVP port choose
between ARM GIC v2 and v3 support in EL3. The latter version is
currently unsupported.
A framework for handling interrupts in BL3-1 will be introduced in
subsequent patches. The default routing model in the absence of any
handlers expects no interrupts to be routed to EL3.
Change-Id: Idf7c023b34fcd4800a5980f2bef85e4b5c29e649
Achin Gupta
committed
on 22 May 2014
|
fvp: Move TSP from Secure DRAM to Secure SRAM
...
The TSP used to execute from secure DRAM on the FVPs because there was
not enough space in Trusted SRAM to fit it in. Thanks to recent RAM
usage enhancements being implemented, we have made enough savings for
the TSP to execute in SRAM.
However, there is no contiguous free chunk of SRAM big enough to hold
the TSP. Therefore, the different bootloader images need to be moved
around to reduce memory fragmentation. This patch keeps the overall
memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and
BL3-1 in between) but moves the base addresses of all the bootloader
images in such a way that:
- memory fragmentation is reduced enough to fit BL3-2 in;
- new base addresses are suitable for release builds as well as debug
ones;
- each image has a few extra kilobytes for future growth.
BL3-1 and BL3-2 are the images which received the biggest slice
of the cake since they will most probably grow the most.
A few useful numbers for reference (valid at the time of this patch):
|-----------------------|-------------------------------
| image size (debug) | extra space for the future
--------|-----------------------|-------------------------------
BL1 R/W | 20 KB | 4 KB
BL2 | 44 KB | 4 KB
BL3-1 | 108 KB | 12 KB
BL3-2 | 56 KB | 8 KB
--------|-----------------------|-------------------------------
Total | 228 KB | 28 KB = 256 KB
--------|-----------------------|-------------------------------
Although on FVPs the TSP now executes from Trusted SRAM by default,
this patch keeps the option to execute it from Trusted DRAM. This is
controlled by the build configuration 'TSP_RAM_LOCATION'.
Fixes ARM-Software/tf-issues#81
Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94
Sandrine Bailleux
committed
on 22 May 2014
|
TSP: Let the platform decide which secure memory to use
...
The TSP's linker script used to assume that the TSP would
execute from secure DRAM. Although it is currently the case
on FVPs, platforms are free to use any secure memory they wish.
This patch introduces the flexibility to load the TSP into any
secure memory. The platform code gets to specify the extents of
this memory in the platform header file, as well as the BL3-2 image
limit address. The latter definition allows to check in a generic way
that the BL3-2 image fits in its bounds.
Change-Id: I9450f2d8b32d74bd00b6ce57a0a1542716ab449c
Sandrine Bailleux
committed
on 22 May 2014
|
Reserve some DDR DRAM for secure use on FVP platforms
...
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.
Fixes ARM-software/tf-issues#149
Change-Id: Ia5d070244aae6c5288ea0e6c8e89d92859522bfe
Juan Castillo
committed
on 22 May 2014
|
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
Vikram Kanigiri
committed
on 22 May 2014
|
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
Vikram Kanigiri
committed
on 22 May 2014
|
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
Vikram Kanigiri
committed
on 22 May 2014
|
2014-05-16 |
Merge pull request #69 from sandrine-bailleux:sb/split-mmu-fcts-per-el
Andrew Thoelke
committed
on 16 May 2014
|
2014-05-12 |
Fixes for TZC configuration on FVP
...
The TZC configuration on FVP was incorrectly allowing both secure
and non-secure accesses to the DRAM, which can cause aliasing
problems for software. It was also not enabling virtio access on
some models.
This patch fixes both of those issues. The patch also enabless
non-secure access to the DDR RAM for all devices with defined IDs.
The third region of DDR RAM has been removed from the configuration
as this is not used in any of the FVP models.
Fixes ARM-software/tf-issues#150
Fixes ARM-software/tf-issues#151
Change-Id: I60ad5daaf55e14f178affb8afd95d17e7537abd7
Andrew Thoelke
committed
on 12 May 2014
|
2014-05-09 |
fvp: Provide per-EL MMU setup functions
...
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
Sandrine Bailleux
committed
on 9 May 2014
|
2014-05-08 |
Merge pull request #60 from athoelke/disable-mmu-v2
...
Replace disable_mmu with assembler version v2
danh-arm
committed
on 8 May 2014
|
Remove unused 'PL011_BASE' macro
...
'PL011_BASE' macro is no longer used because the right UART base
address is now directly given to the 'console_init()' function.
This patch removes it.
Change-Id: I94759c99602df4876291a56f9f6a75de337a65ec
Sandrine Bailleux
committed
on 8 May 2014
|
2014-05-07 |
Replace disable_mmu with assembler version
...
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.
Fixes ARM-software/tf-issues#147
Change-Id: I0cf394d2579a125a23c2f2989c2e92ace6ddb1a6
Andrew Thoelke
committed
on 7 May 2014
|
2014-05-06 |
Remove variables from .data section
...
Update code base to remove variables from the .data section,
mainly by using const static data where possible and adding
the const specifier as required. Most changes are to the IO
subsystem, including the framework APIs. The FVP power
management code is also affected.
Delay initialization of the global static variable,
next_image_type in bl31_main.c, until it is realy needed.
Doing this moves the variable from the .data to the .bss
section.
Also review the IO interface for inconsistencies, using
uintptr_t where possible instead of void *. Remove the
io_handle and io_dev_handle typedefs, which were
unnecessary, replacing instances with uintptr_t.
Fixes ARM-software/tf-issues#107.
Change-Id: I085a62197c82410b566e4698e5590063563ed304
Dan Handley
committed
on 6 May 2014
|
Reduce deep nesting of header files
...
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.
Fixes ARM-software/tf-issues#31
Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
Dan Handley
committed
on 6 May 2014
|
Always use named structs in header files
...
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
Dan Handley
committed
on 6 May 2014
|
Make use of user/system includes more consistent
...
Make codebase consistent in its use of #include "" syntax for
user includes and #include <> syntax for system includes.
Fixes ARM-software/tf-issues#65
Change-Id: If2f7c4885173b1fd05ac2cde5f1c8a07000c7a33
Dan Handley
committed
on 6 May 2014
|
2014-04-24 |
Enable secure memory support for FVPs
...
- 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
Harry Liebel
committed
on 24 Apr 2014
|
2014-04-15 |
Allocate single stacks for BL1 and BL2
...
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.
Fixes ARM-software/tf-issues#76
Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632
Andrew Thoelke
committed
on 15 Apr 2014
|
2014-04-08 |
Define frequency of system counter in platform code
...
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 fixes ARM-software/tf-issues#24
Change-Id: If95639b279f75d66ac0576c48a6614b5ccb0e84b
Sandrine Bailleux
committed
on 8 Apr 2014
|
2014-03-10 |
Remove unused 'CPU present' flag
...
This patch removes the 'CPU present' flag that's being set but not
referred or used anywhere else.
Change-Id: Iaf82bdb354134e0b33af16c7ba88eb2259b2682a
Jeenu Viswambharan
authored
on 7 Jan 2014
Dan Handley
committed
on 10 Mar 2014
|
2014-03-05 |
fvp: Make use of the generic MMU translation table setup code
...
Change-Id: I559c5a4d86cad55ce3f6ad71285b538d3cfd76dc
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Jon Medhurst
authored
on 26 Feb 2014
Dan Handley
committed
on 5 Mar 2014
|