Make enablement of the MMU more flexible

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

Make enablement of the MMU more flexible

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

show more ...

Define ARM_GIC_ARCH default value for all platforms

The ARM_GIC_ARCH build option was supposed to default to 2 on all
platforms. However, the default value was set in the FVP makefile
so for all oth

Define ARM_GIC_ARCH default value for all platforms

The ARM_GIC_ARCH build option was supposed to default to 2 on all
platforms. However, the default value was set in the FVP makefile
so for all other platforms it wasn't even defined.

This patch moves the default value to the main Makefile. The platform
port can then override it if needed.

Change-Id: I8e2da1cce7ffa3ed18814bbdcbcf2578101f18a6

show more ...

FVP: Ensure system reset wake-up results in cold boot

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.

FVP: Ensure system reset wake-up results in cold boot

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)

Fixes ARM-software/tf-issues#217

Change-Id: I65ae0a0f7a46548b575900a5aac107d352b0e2cd

show more ...

Merge pull request #163 from sandrine-bailleux/sb/tf-issue-117-v2

fvp: Reuse BL1 and BL2 memory through image overlaying (v2)

fvp: Reuse BL1 and BL2 memory through image overlaying

This patch re-organizes the memory layout on FVP as to give the
BL3-2 image as much memory as possible.

Considering these two facts:
- not al

fvp: Reuse BL1 and BL2 memory through image overlaying

This patch re-organizes the memory layout on FVP as to give the
BL3-2 image as much memory as possible.

Considering these two facts:
- not all images need to live in memory at the same time. Once
in BL3-1, the memory used by BL1 and BL2 can be reclaimed.
- when BL2 loads the BL3-1 and BL3-2 images, it only considers the
PROGBITS sections of those 2 images. The memory occupied by the
NOBITS sections will be touched only at execution of the BL3-x
images;
Then it is possible to choose the different base addresses such that
the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2.

On FVP we choose to put:
- BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS
sections overlaying BL1;
- BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections
overlaying BL2;

This is illustrated by the following diagram:

0x0404_0000 ------------ ------------------
| BL1 | <= | BL3-1 NOBITS |
------------ <= ------------------
| | <= | BL3-1 PROGBITS |
------------ ------------------
| BL2 | <= | BL3-2 NOBITS |
------------ <= ------------------
| | <= | BL3-2 PROGBITS |
0x0400_0000 ------------ ------------------

New platform-specific constants have been introduced to easily check
at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite
BL1 and BL2. These are optional and the platform code is free to define
them or not. If not defined, the linker won't attempt to check
image overlaying.

Fixes ARM-software/tf-issues#117

Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042

show more ...

Merge pull request #157 from sandrine-bailleux/sb/tf-issue-109

TF issue 109

Refactor fvp gic code to be a generic driver

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

Refactor fvp gic code to be a generic driver

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

Fixes ARM-software/tf-issues#182

Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21

show more ...

Refactor fvp_config into common platform header

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. Re

Refactor fvp_config into common platform header

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.

Fixes ARM-software/tf-issues#180

Change-Id: I58dd7b3c150f24f7ee230a26fd57c827853ba803

show more ...

fvp: Properly detect the location of BL1 R/W data

There was already a rudimentary mechanism to detect whether BL1
R/W data was loaded at the top or bottom of memory. Basically,
- either BL1 was loa

fvp: Properly detect the location of BL1 R/W data

There was already a rudimentary mechanism to detect whether BL1
R/W data was loaded at the top or bottom of memory. Basically,
- either BL1 was loaded at the very end of the trusted RAM
- in all other cases BL1 was considered sitting at the bottom of
the memory and the memory usage structure was updated accordingly,
potentially resulting in critical memory waste.
For instance, if BL1 R/W base address was set to
(TZRAM_END - 4096 - bl1_size), it would virtually occupy the whole
memory.

This patch improves the mechanism to detect the location of BL1
to avoid such scenarios.

Change-Id: I224a9edf0fe8d34208545d84b28b63f2bb830d03

show more ...

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 ...

Merge pull request #151 from vikramkanigiri/vk/t133-code-readability

Simplify entry point information generation code on FVP

Support later revisions of the Foundation FVP

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 th

Support later revisions of the Foundation FVP

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

show more ...

Merge pull request #154 from athoelke/at/inline-mmio

Inline the mmio accessor functions

Merge pull request #152 from jcastillo-arm/jc/tf-issues/073-v2

Remove all checkpatch errors from codebase

Merge pull request #150 from sandrine-bailleux/sb/fix-plat-print-gic-regs

fvp: Fix register name in 'plat_print_gic_regs' macro

Merge pull request #147 from athoelke/at/remove-bakery-mpidr

Remove calling CPU mpidr from bakery lock API

Inline the mmio accessor functions

Making the simple mmio_read_*() and mmio_write_*() functions inline
saves 360 bytes of code in FVP release build.

Fixes ARM-software/tf-issues#210

Change-Id: I65

Inline the mmio accessor functions

Making the simple mmio_read_*() and mmio_write_*() functions inline
saves 360 bytes of code in FVP release build.

Fixes ARM-software/tf-issues#210

Change-Id: I65134f9069f3b2d8821d882daaa5fdfe16355e2f

show more ...

Remove all checkpatch errors from codebase

Exclude stdlib files because they do not follow kernel code style.

Fixes ARM-software/tf-issues#73

Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab

Simplify entry point information generation code on FVP

This patch reworks FVP specific code responsible for determining
the entry point information for BL3-2 and BL3-3 stages when BL3-1
is configur

Simplify entry point information generation code on FVP

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

show more ...

fvp: Fix register name in 'plat_print_gic_regs' macro

The 'plat_print_gic_regs' macro was accessing the GICC_CTLR register
using the GICD_CTLR offset. This still generates the right code in
the end

fvp: Fix register name in 'plat_print_gic_regs' macro

The 'plat_print_gic_regs' macro was accessing the GICC_CTLR register
using the GICD_CTLR offset. This still generates the right code in
the end because GICD_CTLR == GICC_CTLR but this patch fixes it for
the logic of the code.

Change-Id: I7b17af50e587f07bec0e4c933e346088470c96f3

show more ...

Remove calling CPU mpidr from bakery lock API

The bakery lock code currently expects the calling code to pass
the MPIDR_EL1 of the current CPU.

This is not always done correctly. Also the change to

Remove calling CPU mpidr from bakery lock API

The bakery lock code currently expects the calling code to pass
the MPIDR_EL1 of the current CPU.

This is not always done correctly. Also the change to provide
inline access to system registers makes it more efficient for the
bakery lock code to obtain the MPIDR_EL1 directly.

This change removes the mpidr parameter from the bakery lock
interface, and results in a code reduction of 160 bytes for the
ARM FVP port.

Fixes ARM-software/tf-issues#213

Change-Id: I7ec7bd117bcc9794a0d948990fcf3336a367d543

show more ...

Merge pull request #145 from athoelke/at/psci-memory-optimization-v2

PSCI memory optimizations (v2)

Correctly dimension the PSCI aff_map_node array

The array of affinity nodes is currently allocated for 32 entries
with the PSCI_NUM_AFFS value defined in psci.h. This is not enough
for large systems

Correctly dimension the PSCI aff_map_node array

The array of affinity nodes is currently allocated for 32 entries
with the PSCI_NUM_AFFS value defined in psci.h. This is not enough
for large systems, and will substantially over allocate the array
for small systems.

This patch introduces an optional platform definition
PLATFORM_NUM_AFFS to platform_def.h. If defined this value is
used for PSCI_NUM_AFFS, otherwise a value of two times the number
of CPU cores is used.

The FVP port defines PLATFORM_NUM_AFFS to be 10 which saves
nearly 1.5KB of memory.

Fixes ARM-software/tf-issues#192

Change-Id: I68e30ac950de88cfbd02982ba882a18fb69c1445

show more ...

Merge pull request #143 from athoelke/at/remove-nsram

Remove NSRAM from FVP memory map

Remove NSRAM from FVP memory map

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

Remove NSRAM from FVP memory map

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.

Fixes ARM-software/tf-issues#196

Change-Id: I5b959e4fe92f5f892ed127c40dbe6c85eed3ed72

show more ...