Commit 4731e8f0 authored by danh-arm's avatar danh-arm
Browse files

Merge pull request #295 from danh-arm/dh/plat-port-reorg

ARM platform port reorganization
parents 6403a306 4a75b84a
#
# Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
# Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
......@@ -126,9 +126,14 @@ BL_COMMON_SOURCES := common/bl_common.c \
BUILD_BASE := ./build
BUILD_PLAT := ${BUILD_BASE}/${PLAT}/${BUILD_TYPE}
PLATFORMS := $(shell ls -I common plat/)
PLAT_MAKEFILE := platform.mk
# Generate the platforms list by recursively searching for all directories
# under /plat containing a PLAT_MAKEFILE. Append each platform with a `|`
# char and strip out the final '|'.
PLATFORMS := $(shell find plat/ -name '${PLAT_MAKEFILE}' -print0 | \
sed -r 's%[^\x00]*\/([^/]*)\/${PLAT_MAKEFILE}\x00%\1|%g' | \
sed -r 's/\|$$//')
SPDS := $(shell ls -I none services/spd)
HELP_PLATFORMS := $(shell echo ${PLATFORMS} | sed 's/ /|/g')
# Convenience function for adding build definitions
# $(eval $(call add_define,FOO)) will have:
......@@ -144,9 +149,10 @@ $(and $(patsubst 0,,$(value $(1))),$(patsubst 1,,$(value $(1))),$(error $(1) mus
endef
ifeq (${PLAT},)
$(error "Error: Unknown platform. Please use PLAT=<platform name> to specify the platform.")
$(error "Error: Unknown platform. Please use PLAT=<platform name> to specify the platform")
endif
ifeq ($(findstring ${PLAT},${PLATFORMS}),)
PLAT_MAKEFILE_FULL := $(shell find plat/ -wholename '*/${PLAT}/${PLAT_MAKEFILE}')
ifeq ($(PLAT_MAKEFILE_FULL),)
$(error "Error: Invalid platform. The following platforms are available: ${PLATFORMS}")
endif
......@@ -155,7 +161,7 @@ all: msg_start
msg_start:
@echo "Building ${PLAT}"
include plat/${PLAT}/platform.mk
include ${PLAT_MAKEFILE_FULL}
# Include the CPU specific operations makefile. By default all CPU errata
# workarounds and CPU specifc optimisations are disabled. This can be
......@@ -225,6 +231,9 @@ CFLAGS += -g
ASFLAGS += -g -Wa,--gdwarf-2
endif
# Process PLAT flag
$(eval $(call add_define,PLAT_${PLAT}))
# Process NS_TIMER_SWITCH flag
$(eval $(call assert_boolean,NS_TIMER_SWITCH))
$(eval $(call add_define,NS_TIMER_SWITCH))
......@@ -633,7 +642,7 @@ cscope:
${Q}cscope -b -q -k
help:
@echo "usage: ${MAKE} PLAT=<${HELP_PLATFORMS}> [OPTIONS] [TARGET]"
@echo "usage: ${MAKE} PLAT=<${PLATFORMS}> [OPTIONS] [TARGET]"
@echo ""
@echo "PLAT is used to specify which platform you wish to build."
@echo "If no platform is specified, PLAT defaults to: ${DEFAULT_PLAT}"
......
/*
* Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -114,21 +114,36 @@ void bl1_main(void)
INFO("BL1: RAM 0x%lx - 0x%lx\n", BL1_RAM_BASE, BL1_RAM_LIMIT);
#if DEBUG
unsigned long sctlr_el3 = read_sctlr_el3();
#endif
image_info_t bl2_image_info = { {0} };
entry_point_info_t bl2_ep = { {0} };
meminfo_t *bl1_tzram_layout;
meminfo_t *bl2_tzram_layout = 0x0;
int err;
#if DEBUG
unsigned long val;
/*
* Ensure that MMU/Caches and coherency are turned on
*/
assert(sctlr_el3 | SCTLR_M_BIT);
assert(sctlr_el3 | SCTLR_C_BIT);
assert(sctlr_el3 | SCTLR_I_BIT);
val = read_sctlr_el3();
assert(val | SCTLR_M_BIT);
assert(val | SCTLR_C_BIT);
assert(val | SCTLR_I_BIT);
/*
* Check that Cache Writeback Granule (CWG) in CTR_EL0 matches the
* provided platform value
*/
val = (read_ctr_el0() >> CTR_CWG_SHIFT) & CTR_CWG_MASK;
/*
* If CWG is zero, then no CWG information is available but we can
* at least check the platform value is less than the architectural
* maximum.
*/
if (val != 0)
assert(CACHE_WRITEBACK_GRANULE == SIZE_FROM_LOG2_WORDS(val));
else
assert(CACHE_WRITEBACK_GRANULE <= MAX_CACHE_LINE_SIZE);
#endif
/* Perform remaining generic architectural setup from EL3 */
bl1_arch_setup();
......
......@@ -52,7 +52,7 @@ $(eval $(call add_define,TSP_INIT_ASYNC))
# Include the platform-specific TSP Makefile
# If no platform-specific TSP Makefile exists, it means TSP is not supported
# on this platform.
TSP_PLAT_MAKEFILE := plat/${PLAT}/tsp/tsp-${PLAT}.mk
TSP_PLAT_MAKEFILE := $(shell find plat/ -wholename '*/${PLAT}/tsp/tsp-${PLAT}.mk')
ifeq (,$(wildcard ${TSP_PLAT_MAKEFILE}))
$(error TSP is not supported on platform ${PLAT})
else
......
/*
* Copyright (c) 2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -58,9 +58,9 @@ void tsp_update_sync_fiq_stats(uint32_t type, uint64_t elr_el3)
#if LOG_LEVEL >= LOG_LEVEL_VERBOSE
spin_lock(&console_lock);
VERBOSE("TSP: cpu 0x%x sync fiq request from 0x%llx\n",
VERBOSE("TSP: cpu 0x%lx sync fiq request from 0x%lx\n",
mpidr, elr_el3);
VERBOSE("TSP: cpu 0x%x: %d sync fiq requests, %d sync fiq returns\n",
VERBOSE("TSP: cpu 0x%lx: %d sync fiq requests, %d sync fiq returns\n",
mpidr,
tsp_stats[linear_id].sync_fiq_count,
tsp_stats[linear_id].sync_fiq_ret_count);
......@@ -104,9 +104,9 @@ int32_t tsp_fiq_handler(void)
tsp_stats[linear_id].fiq_count++;
#if LOG_LEVEL >= LOG_LEVEL_VERBOSE
spin_lock(&console_lock);
VERBOSE("TSP: cpu 0x%x handled fiq %d\n",
VERBOSE("TSP: cpu 0x%lx handled fiq %d\n",
mpidr, id);
VERBOSE("TSP: cpu 0x%x: %d fiq requests\n",
VERBOSE("TSP: cpu 0x%lx: %d fiq requests\n",
mpidr, tsp_stats[linear_id].fiq_count);
spin_unlock(&console_lock);
#endif
......@@ -121,8 +121,8 @@ int32_t tsp_irq_received(void)
tsp_stats[linear_id].irq_count++;
#if LOG_LEVEL >= LOG_LEVEL_VERBOSE
spin_lock(&console_lock);
VERBOSE("TSP: cpu 0x%x received irq\n", mpidr);
VERBOSE("TSP: cpu 0x%x: %d irq requests\n",
VERBOSE("TSP: cpu 0x%lx received irq\n", mpidr);
VERBOSE("TSP: cpu 0x%lx: %d irq requests\n",
mpidr, tsp_stats[linear_id].irq_count);
spin_unlock(&console_lock);
#endif
......
......@@ -38,12 +38,6 @@
#include <tsp.h>
#include "tsp_private.h"
/*******************************************************************************
* Declarations of linker defined symbols which will help us find the layout
* of trusted SRAM
******************************************************************************/
extern unsigned long __RO_START__;
extern unsigned long __BL32_END__;
/*******************************************************************************
* Lock to control access to the console
......
/*
* Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -137,7 +137,7 @@ void reserve_mem(uint64_t *free_base, size_t *free_size,
if (pos == BOTTOM)
*free_base = addr + size;
VERBOSE("Reserved %u bytes (discarded %u bytes %s)\n",
VERBOSE("Reserved 0x%lx bytes (discarded 0x%lx bytes %s)\n",
reserved_size, discard_size,
pos == TOP ? "above" : "below");
}
......
......@@ -88,13 +88,9 @@ This stage begins execution from the platform's reset vector at EL3. The reset
address is platform dependent but it is usually located in a Trusted ROM area.
The BL1 data section is copied to trusted SRAM at runtime.
On the ARM FVP port, BL1 code starts execution from the reset vector at address
`0x00000000` (trusted ROM). The BL1 data section is copied to the start of
trusted SRAM at address `0x04000000`.
On the Juno ARM development platform port, BL1 code starts execution at
`0x0BEC0000` (FLASH). The BL1 data section is copied to trusted SRAM at address
`0x04001000.
On the ARM development platforms, BL1 code starts execution from the reset
vector defined by the constant `BL1_RO_BASE`. The BL1 data section is copied
to the top of trusted SRAM as defined by the constant `BL1_RW_BASE`.
The functionality implemented by this stage is as follows.
......@@ -189,9 +185,9 @@ BL1 performs minimal architectural initialization as follows.
#### Platform initialization
BL1 enables issuing of snoop and DVM (Distributed Virtual Memory) requests from
the CCI-400 slave interface corresponding to the cluster that includes the
primary CPU. BL1 also initializes UART0 (PL011 console), which enables access to
the `printf` family of functions in BL1.
the CCI slave interface corresponding to the cluster that includes the
primary CPU. BL1 also initializes a UART (PL011 console), which enables access
to the `printf` family of functions in BL1.
#### BL2 image load and execution
......@@ -247,7 +243,7 @@ platform-specific mechanism. It calculates the limits of DRAM (main memory)
to determine whether there is enough space to load the BL3-3 image. A platform
defined base address is used to specify the load address for the BL3-1 image.
It also defines the extents of memory available for use by the BL3-2 image.
BL2 also initializes UART0 (PL011 console), which enables access to the
BL2 also initializes a UART (PL011 console), which enables access to the
`printf` family of functions in BL2. Platform security is initialized to allow
access to controlled components. The storage abstraction layer is initialized
which is used to load further bootloader images.
......@@ -258,8 +254,8 @@ Some systems have a separate System Control Processor (SCP) for power, clock,
reset and system control. BL2 loads the optional BL3-0 image from platform
storage into a platform-specific region of secure memory. The subsequent
handling of BL3-0 is platform specific. For example, on the Juno ARM development
platform port the image is transferred into SCP memory using the SCPI protocol
after being loaded in the trusted SRAM memory at address `0x04009000`. The SCP
platform port the image is transferred into SCP's internal memory using the Boot
Over MHU (BOM) protocol after being loaded in the trusted SRAM memory. The SCP
executes BL3-0 and signals to the Application Processor (AP) for BL2 execution
to continue.
......@@ -338,7 +334,7 @@ the clock frequency of the system counter, which is provided by the platform.
BL3-1 performs detailed platform initialization, which enables normal world
software to function correctly. It also retrieves entrypoint information for
the BL3-3 image loaded by BL2 from the platform defined memory address populated
by BL2. BL3-1 also initializes UART0 (PL011 console), which enables
by BL2. BL3-1 also initializes a UART (PL011 console), which enables
access to the `printf` family of functions in BL3-1. It enables the system
level implementation of the generic timer through the memory mapped interface.
......@@ -460,7 +456,8 @@ the CPU caches if it is provided by an earlier boot stage and then accessed by
BL3-1 platform code before the caches are enabled.
ARM Trusted Firmware's BL2 implementation passes a `bl31_params` structure in
`X0` and the FVP port interprets this in the BL3-1 platform code.
`X0` and the ARM development platforms interpret this in the BL3-1 platform
code.
##### MMU, Data caches & Coherency
......@@ -490,7 +487,7 @@ BL3-1 to detect which information is present and respond appropriately. The
The structures using this format are `entry_point_info`, `image_info` and
`bl31_params`. The code that allocates and populates these structures must set
the header fields appropriately, and the `SET_PARA_HEAD()` a macro is defined
the header fields appropriately, and the `SET_PARAM_HEAD()` a macro is defined
to simplify this action.
#### Required CPU state for BL3-1 Warm boot initialization
......@@ -870,10 +867,10 @@ before returning through EL3 and running the non-trusted firmware (BL3-3):
6. Crash Reporting in BL3-1
----------------------------
The BL3-1 implements a scheme for reporting the processor state when an unhandled
BL3-1 implements a scheme for reporting the processor state when an unhandled
exception is encountered. The reporting mechanism attempts to preserve all the
register contents and report it via the default serial output. The general purpose
registers, EL3, Secure EL1 and some EL2 state registers are reported.
register contents and report it via a dedicated UART (PL011 console). BL3-1
reports the general purpose, EL3, Secure EL1 and some EL2 state registers.
A dedicated per-CPU crash stack is maintained by BL3-1 and this is retrieved via
the per-CPU pointer cache. The implementation attempts to minimise the memory
......@@ -1253,27 +1250,37 @@ on FVP, BL3-1 and TSP need to know the limit address that their PROGBITS
sections must not overstep. The platform code must provide those.
#### Memory layout on ARM FVPs
#### Memory layout on ARM development platforms
The following list describes the memory layout on the ARM development platforms:
The following list describes the memory layout on the FVP:
* A 4KB page of shared memory is used for communication between Trusted
Firmware and the platform's power controller. This is located at the base of
Trusted SRAM. The amount of Trusted SRAM available to load the bootloader
images is reduced by the size of the shared memory.
* A 4KB page of shared memory is used to store the entrypoint mailboxes
and the parameters passed between bootloaders. The shared memory is located
at the base of the Trusted SRAM. The amount of Trusted SRAM available to
load the bootloader images will be reduced by the size of the shared memory.
The shared memory is used to store the entrypoint mailboxes for each CPU.
On Juno, this is also used for the MHU payload when passing messages to and
from the SCP.
* BL1 is originally sitting in the Trusted ROM at address `0x0`. Its
read-write data are relocated at the top of the Trusted SRAM at runtime.
* On FVP, BL1 is originally sitting in the Trusted ROM at address `0x0`. On
Juno, BL1 resides in flash memory at address `0x0BEC0000`. BL1 read-write
data are relocated to the top of Trusted SRAM at runtime.
* BL3-1 is loaded at the top of the Trusted SRAM, such that its NOBITS
sections will overwrite BL1 R/W data.
sections will overwrite BL1 R/W data. This implies that BL1 global variables
remain valid only until execution reaches the BL3-1 entry point during
a cold boot.
* BL2 is loaded below BL3-1.
* On Juno, BL3-0 is loaded temporarily into the BL3-1 memory region and
transfered to the SCP before being overwritten by BL3-1.
* BL3-2 can be loaded in one of the following locations:
* Trusted SRAM
* Trusted DRAM
* Trusted DRAM (FVP only)
* Secure region of DRAM (top 16MB of DRAM configured by the TrustZone
controller)
......@@ -1282,9 +1289,13 @@ overlay BL2. This memory layout is designed to give the BL3-2 image as much
memory as possible when it is loaded into Trusted SRAM.
The location of the BL3-2 image will result in different memory maps. This is
illustrated in the following diagrams using the TSP as an example.
illustrated for both FVP and Juno in the following diagrams, using the TSP as
an example.
Note: Loading the BL3-2 image in TZC secured DRAM doesn't change the memory
layout of the other images in Trusted SRAM.
**TSP in Trusted SRAM (default option):**
**FVP with TSP in Trusted SRAM (default option):**
Trusted SRAM
0x04040000 +----------+ loaded by BL2 ------------------
......@@ -1305,7 +1316,7 @@ illustrated in the following diagrams using the TSP as an example.
0x00000000 +----------+
**TSP in Trusted DRAM:**
**FVP with TSP in Trusted DRAM:**
Trusted DRAM
0x08000000 +----------+
......@@ -1330,7 +1341,7 @@ illustrated in the following diagrams using the TSP as an example.
| BL1 (ro) |
0x00000000 +----------+
**TSP in the TZC-Secured DRAM:**
**FVP with TSP in TZC-Secured DRAM:**
DRAM
0xffffffff +----------+
......@@ -1359,43 +1370,8 @@ illustrated in the following diagrams using the TSP as an example.
| BL1 (ro) |
0x00000000 +----------+
Moving the TSP image out of the Trusted SRAM doesn't change the memory layout
of the other boot loader images in Trusted SRAM.
#### Memory layout on Juno ARM development platform
The following list describes the memory layout on Juno:
* Trusted SRAM at 0x04000000 contains the MHU page, BL1 r/w section, BL2
image, BL3-1 image and, optionally, the BL3-2 image.
* The MHU 4 KB page is used as communication channel between SCP and AP. It
also contains the entrypoint mailboxes for the AP. Mailboxes are stored in
the first 128 bytes of the MHU page.
* BL1 resides in flash memory at address `0x0BEC0000`. Its read-write data
section is relocated to the top of the Trusted SRAM at runtime.
* BL3-1 is loaded at the top of the Trusted SRAM, such that its NOBITS
sections will overwrite BL1 R/W data. This implies that BL1 global variables
will remain valid only until execution reaches the BL3-1 entry point during
a cold boot.
* BL2 is loaded below BL3-1.
* BL3-0 is loaded temporarily into the BL3-1 memory region and transfered to
the SCP before being overwritten by BL3-1.
* The BL3-2 image is optional and can be loaded into one of these two
locations: Trusted SRAM (right after the MHU page) or DRAM (14 MB starting
at 0xFF000000 and secured by the TrustZone controller). When loaded into
Trusted SRAM, its NOBITS sections are allowed to overlap BL2.
Depending on the location of the BL3-2 image, it will result in different memory
maps, illustrated by the following diagrams.
**BL3-2 in Trusted SRAM (default option):**
**Juno with BL3-2 in Trusted SRAM (default option):**
Flash0
0x0C000000 +----------+
......@@ -1420,7 +1396,7 @@ maps, illustrated by the following diagrams.
0x04000000 +----------+
**BL3-2 in the secure region of DRAM:**
**Juno with BL3-2 in TZC-secured DRAM:**
DRAM
0xFFE00000 +----------+
......@@ -1453,9 +1429,6 @@ maps, illustrated by the following diagrams.
| MHU |
0x04000000 +----------+
Loading the BL3-2 image in DRAM doesn't change the memory layout of the other
images in Trusted SRAM.
10. Firmware Image Package (FIP)
---------------------------------
......@@ -1524,15 +1497,16 @@ The tool can be found in `tools/fip_create`.
### Loading from a Firmware Image Package (FIP)
The Firmware Image Package (FIP) driver can load images from a binary package on
non-volatile platform storage. For the FVPs this is currently NOR FLASH.
non-volatile platform storage. For the ARM development platforms, this is
currently NOR FLASH.
Bootloader images are loaded according to the platform policy as specified in
`plat/<platform>/plat_io_storage.c`. For the FVPs this means the platform will
attempt to load images from a Firmware Image Package located at the start of NOR
FLASH0.
Bootloader images are loaded according to the platform policy as specified by
the function `plat_get_image_source()`. For the ARM development platforms, this
means the platform will attempt to load images from a Firmware Image Package
located at the start of NOR FLASH0.
Currently the FVP's policy only allows loading of a known set of images. The
platform policy can be modified to allow additional images.
The ARM development platforms' policy is to only allow loading of a known set of
images. The platform policy can be modified to allow additional images.
11. Use of coherent memory in Trusted Firmware
......@@ -1743,7 +1717,6 @@ Trusted Firmware code is logically divided between the three boot loader
stages mentioned in the previous sections. The code is also divided into the
following categories (present as directories in the source code):
* **Architecture specific.** This could be AArch32 or AArch64.
* **Platform specific.** Choice of architecture specific code depends upon
the platform.
* **Common code.** This is platform and architecture agnostic code.
......@@ -1761,7 +1734,6 @@ categories. Based upon the above, the code layout looks like this:
bl1 Yes No No
bl2 No Yes No
bl31 No No Yes
arch Yes Yes Yes
plat Yes Yes Yes
drivers Yes No Yes
common Yes Yes Yes
......@@ -1795,7 +1767,7 @@ kernel at boot time. These can be found in the `fdts` directory.
- - - - - - - - - - - - - - - - - - - - - - - - - -
_Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved._
_Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._
[ARM ARM]: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.e/index.html "ARMv8-A Reference Manual (ARM DDI0487A.E)"
[PSCI]: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf "Power State Coordination Interface PDD (ARM DEN 0022C)"
......
......@@ -33,13 +33,21 @@ Modifications consist of:
* Setting up the execution context in a certain way, or
* Defining certain constants (for example #defines).
The platform-specific functions and variables are all declared in
The platform-specific functions and variables are declared in
[include/plat/common/platform.h]. The firmware provides a default implementation
of variables and functions to fulfill the optional requirements. These
implementations are all weakly defined; they are provided to ease the porting
effort. Each platform port can override them with its own implementation if the
default implementation is inadequate.
Platform ports that want to be aligned with standard ARM platforms (for example
FVP and Juno) may also use [include/plat/arm/common/plat_arm.h] and the
corresponding source files in `plat/arm/common/`. These provide standard
implementations for some of the required platform porting functions. However,
using these functions requires the platform port to implement additional
ARM standard platform porting functions. These additional functions are not
documented here.
Some modifications are common to all Boot Loader (BL) stages. Section 2
discusses these in detail. The subsequent sections discuss the remaining
modifications for each BL stage in detail.
......@@ -60,8 +68,8 @@ either mandatory or optional.
----------------------------------
A platform port must enable the Memory Management Unit (MMU) with identity
mapped page tables, and enable both the instruction and data caches for each BL
stage. In the ARM FVP port, each BL stage configures the MMU in its platform-
specific architecture setup function, for example `blX_plat_arch_setup()`.
stage. In ARM standard platforms, each BL stage configures the MMU in
the platform-specific architecture setup function, `blX_plat_arch_setup()`.
If the build option `USE_COHERENT_MEM` is enabled, each platform must allocate a
block of identity mapped secure memory with Device-nGnRE attributes aligned to
......@@ -87,18 +95,28 @@ for the firmware to work correctly.
Each platform must ensure that a header file of this name is in the system
include path with the following constants defined. This may require updating the
list of `PLAT_INCLUDES` in the `platform.mk` file. In the ARM FVP port, this
file is found in [plat/fvp/include/platform_def.h].
list of `PLAT_INCLUDES` in the `platform.mk` file. In the ARM development
platforms, this file is found in `plat/arm/board/<plat_name>/include/`.
Platform ports may optionally use the file [include/plat/common/common_def.h],
which provides typical values for some of the constants below. These values are
likely to be suitable for all platform ports.
Platform ports that want to be aligned with standard ARM platforms (for example
FVP and Juno) may also use [include/plat/arm/common/arm_def.h], which provides
standard values for some of the constants below. However, this requires the
platform port to define additional platform porting constants in
`platform_def.h`. These additional constants are not documented here.
* **#define : PLATFORM_LINKER_FORMAT**
Defines the linker format used by the platform, for example
`elf64-littleaarch64` used by the FVP.
`elf64-littleaarch64`.
* **#define : PLATFORM_LINKER_ARCH**
Defines the processor architecture for the linker by the platform, for
example `aarch64` used by the FVP.
example `aarch64`.
* **#define : PLATFORM_STACK_SIZE**
......@@ -106,6 +124,11 @@ file is found in [plat/fvp/include/platform_def.h].
by [plat/common/aarch64/platform_mp_stack.S] and
[plat/common/aarch64/platform_up_stack.S].
* **define : CACHE_WRITEBACK_GRANULE**
Defines the size in bits of the largest cache line across all the cache
levels in the platform.
* **#define : FIRMWARE_WELCOME_STR**
Defines the character string printed by BL1 upon entry into the `bl1_main()`
......@@ -156,26 +179,11 @@ file is found in [plat/fvp/include/platform_def.h].
Name of the BL3-3 Content certificate on the host file-system (mandatory
when Trusted Board Boot is enabled).
* **#define : PLATFORM_CACHE_LINE_SIZE**
Defines the size (in bytes) of the largest cache line across all the cache
levels in the platform.
* **#define : PLATFORM_CLUSTER_COUNT**
Defines the total number of clusters implemented by the platform in the
system.
* **#define : PLATFORM_CORE_COUNT**
Defines the total number of CPUs implemented by the platform across all
clusters in the system.
* **#define : PLATFORM_MAX_CPUS_PER_CLUSTER**
Defines the maximum number of CPUs that can be implemented within a cluster
on the platform.
* **#define : PLATFORM_NUM_AFFS**
Defines the total number of nodes in the affinity heirarchy at all affinity
......@@ -301,6 +309,16 @@ platform, the following constants must also be defined:
Defines the ID of the secure physical generic timer interrupt used by the
TSP's interrupt handling code.
If the platform port uses the translation table library code, the following
constant must also be defined:
* **#define : MAX_XLAT_TABLES**
Defines the maximum number of translation tables that are allocated by the
translation table library code. To minimize the amount of runtime memory
used, choose the smallest value needed to map the required virtual addresses
for each BL stage.
If the platform port uses the IO storage framework, the following constants
must also be defined:
......@@ -328,7 +346,7 @@ memory within the the per-cpu data to minimize wastage.
structure for use by the platform layer.
The following constants are optional. They should be defined when the platform
memory layout implies some image overlaying like on FVP.
memory layout implies some image overlaying like in ARM standard platforms.
* **#define : BL31_PROGBITS_LIMIT**
......@@ -342,8 +360,8 @@ memory layout implies some image overlaying like on FVP.
### File : plat_macros.S [mandatory]
Each platform must ensure a file of this name is in the system include path with
the following macro defined. In the ARM FVP port, this file is found in
[plat/fvp/include/plat_macros.S].
the following macro defined. In the ARM development platforms, this file is
found in `plat/arm/board/<plat_name>/include/plat_macros.S`.
* **Macro : plat_print_gic_regs**
......@@ -354,25 +372,11 @@ the following macro defined. In the ARM FVP port, this file is found in
* **Macro : plat_print_interconnect_regs**
This macro allows the crash reporting routine to print interconnect registers
in case of an unhandled exception in BL3-1. This aids in debugging and
this macro can be defined to be empty in case interconnect register reporting
is not desired. In the ARM FVP port, the CCI snoop control registers are
reported.
### Other mandatory modifications
The following mandatory modifications may be implemented in any file
the implementer chooses. In the ARM FVP port, they are implemented in
[plat/fvp/aarch64/plat_common.c].
* **Function : uint64_t plat_get_syscnt_freq(void)**
This function is used by the architecture setup code to retrieve the
counter frequency for the CPU's generic timer. This value will be
programmed into the `CNTFRQ_EL0` register.
In the ARM FVP port, it returns the base frequency of the system counter,
which is retrieved from the first entry in the frequency modes table.
This macro allows the crash reporting routine to print interconnect
registers in case of an unhandled exception in BL3-1. This aids in debugging
and this macro can be defined to be empty in case interconnect register
reporting is not desired. In ARM standard platforms, the CCI snoop
control registers are reported.
2.2 Handling Reset
......@@ -564,7 +568,7 @@ specific errata workarounds could also be implemented here. The api should
preserve the values of callee saved registers x19 to x29.
The default implementation doesn't do anything. If a platform needs to override
the default implementation, refer to the [Firmware Design Guide] for general
the default implementation, refer to the [Firmware Design] for general
guidelines regarding placement of code in a reset handler.
### Function : plat_disable_acp()
......@@ -626,18 +630,27 @@ The following functions need to be implemented by the platform port to enable
BL1 to perform the above tasks.
### Function : bl1_early_platform_setup() [mandatory]
Argument : void
Return : void
This function executes with the MMU and data caches disabled. It is only called
by the primary CPU.
In ARM standard platforms, this function initializes the console and enables
snoop requests into the primary CPU's cluster.
### Function : bl1_plat_arch_setup() [mandatory]
Argument : void
Return : void
This function performs any platform-specific and architectural setup that the
platform requires. Platform-specific setup might include configuration of
memory controllers, configuration of the interconnect to allow the cluster
to service cache snoop requests from another cluster, and so on.
platform requires. Platform-specific setup might include configuration of
memory controllers and the interconnect.
In the ARM FVP port, this function enables CCI snoops into the cluster that the
primary CPU is part of. It also enables the MMU.
In ARM standard platforms, this function enables the MMU.
This function helps fulfill requirement 2 above.
......@@ -651,8 +664,8 @@ This function executes with the MMU and data caches enabled. It is responsible
for performing any remaining platform-specific setup that can occur after the
MMU and data cache have been enabled.
This function is also responsible for initializing the storage abstraction layer
which is used to load further bootloader images.
In ARM standard platforms, this function initializes the storage abstraction
layer used to load the next bootloader image.
This function helps fulfill requirement 3 above.
......@@ -692,8 +705,9 @@ structure.
Depending upon where BL2 has been loaded in secure RAM (determined by
`BL2_BASE`), BL1 calculates the amount of free memory available for BL2 to use.
BL1 also ensures that its data sections resident in secure RAM are not visible
to BL2. An illustration of how this is done in the ARM FVP port is given in the
[User Guide], in the Section "Memory layout on Base FVP".
to BL2. An illustration of how this is done in ARM standard platforms is given
in the **Memory layout on ARM development platforms** section in the
[Firmware Design].
### Function : bl1_plat_set_bl2_ep_info() [mandatory]
......@@ -705,8 +719,6 @@ This function is called after loading BL2 image and it can be used to overwrite
the entry point set by loader and also set the security state and SPSR which
represents the entry point system state for BL2.
On FVP, we are setting the security state and the SPSR for the BL2 entrypoint
3.2 Boot Loader Stage 2 (BL2)
-----------------------------
......@@ -772,6 +784,11 @@ variable as the original memory may be subsequently overwritten by BL2. The
copied structure is made available to all BL2 code through the
`bl2_plat_sec_mem_layout()` function.
In ARM standard platforms, this function also initializes the storage
abstraction layer used to load further bootloader images. It is necessary to do
this early on platforms with a BL3-0 image, since the later `bl2_platform_setup`
must be done after BL3-0 is loaded.
### Function : bl2_plat_arch_setup() [mandatory]
......@@ -796,14 +813,11 @@ port does the necessary initialization in `bl2_plat_arch_setup()`. It is only
called by the primary CPU.
The purpose of this function is to perform any platform initialization
specific to BL2. Platform security components are configured if required.
For the Base FVP the TZC-400 TrustZone controller is configured to only
grant non-secure access to DRAM. This avoids aliasing between secure and
non-secure accesses in the TLB and cache - secure execution states can use
the NS attributes in the MMU translation tables to access the DRAM.
specific to BL2.
This function is also responsible for initializing the storage abstraction layer
which is used to load further bootloader images.
In ARM standard platforms, this function performs security setup, including
configuration of the TrustZone controller to allow non-secure masters access
to most of DRAM. Part of DRAM is reserved for secure world use.
### Function : bl2_plat_sec_mem_layout() [mandatory]
......@@ -878,8 +892,8 @@ BL2 platform code returns a pointer which is used to populate the entry point
information for BL3-1 entry point. The location pointed by it should be
accessible from BL1 while processing the synchronous exception to run to BL3-1.
On FVP this is allocated inside an bl2_to_bl31_params_mem structure which
is allocated at an address pointed by PARAMS_BASE.
In ARM standard platforms this is allocated inside a bl2_to_bl31_params_mem
structure in BL2 memory.
### Function : bl2_plat_set_bl31_ep_info() [mandatory]
......@@ -891,8 +905,6 @@ This function is called after loading BL3-1 image and it can be used to
overwrite the entry point set by loader and also set the security state
and SPSR which represents the entry point system state for BL3-1.
On FVP, we are setting the security state and the SPSR for the BL3-1
entrypoint.
### Function : bl2_plat_set_bl32_ep_info() [mandatory]
......@@ -903,8 +915,6 @@ This function is called after loading BL3-2 image and it can be used to
overwrite the entry point set by loader and also set the security state
and SPSR which represents the entry point system state for BL3-2.
On FVP, we are setting the security state and the SPSR for the BL3-2
entrypoint
### Function : bl2_plat_set_bl33_ep_info() [mandatory]
......@@ -915,8 +925,6 @@ This function is called after loading BL3-3 image and it can be used to
overwrite the entry point set by loader and also set the security state
and SPSR which represents the entry point system state for BL3-3.
On FVP, we are setting the security state and the SPSR for the BL3-3
entrypoint
### Function : bl2_plat_get_bl32_meminfo() [mandatory]
......@@ -1012,12 +1020,10 @@ sub-structures into private variables if the original memory may be
subsequently overwritten by BL3-1 and similarly the `void *` pointing
to the platform data also needs to be saved.
On the ARM FVP port, BL2 passes a pointer to a `bl31_params` structure populated
in the secure DRAM at address `0x6000000` in the bl31_params * argument and it
does not use opaque pointer mentioned earlier. BL3-1 does not copy this
information to internal data structures as it guarantees that the secure
DRAM memory will not be overwritten. It maintains an internal reference to this
information in the `bl2_to_bl31_params` variable.
In ARM standard platforms, BL2 passes a pointer to a `bl31_params` structure
in BL2 memory. BL3-1 copies the information in this pointer to internal data
structures.
### Function : bl31_plat_arch_setup() [mandatory]
......@@ -1044,12 +1050,11 @@ called by the primary CPU.
The purpose of this function is to complete platform initialization so that both
BL3-1 runtime services and normal world software can function correctly.
The ARM FVP port does the following:
In ARM standard platforms, this function does the following:
* Initializes the generic interrupt controller.
* Configures the CLCD controller.
* Enables system-level implementation of the generic timer counter.
* Grants access to the system counter timer module
* Initializes the FVP power controller device
* Initializes the power controller device
* Detects the system topology.
......@@ -1068,6 +1073,17 @@ state. This function must return a pointer to the `entry_point_info` structure
(that was copied during `bl31_early_platform_setup()`) if the image exists. It
should return NULL otherwise.
### Function : plat_get_syscnt_freq() [mandatory]
Argument : void
Return : uint64_t
This function is used by the architecture setup code to retrieve the counter
frequency for the CPU's generic timer. This value will be programmed into the
`CNTFRQ_EL0` register. In ARM standard platforms, it returns the base frequency
of the system counter, which is retrieved from the first entry in the frequency
modes table.
3.3 Power State Coordination Interface (in BL3-1)
------------------------------------------------
......@@ -1156,10 +1172,10 @@ handler routines for platform-specific power management actions by populating
the passed pointer with a pointer to BL3-1's private `plat_pm_ops` structure.
A description of each member of this structure is given below. Please refer to
the ARM FVP specific implementation of these handlers in [plat/fvp/fvp_pm.c]
as an example. A platform port is expected to implement these handlers if the
corresponding PSCI operation is to be supported and these handlers are expected
to succeed if the return type is `void`.
the ARM FVP specific implementation of these handlers in
[plat/arm/board/fvp/fvp_pm.c] as an example. A platform port is expected to
implement these handlers if the corresponding PSCI operation is to be supported
and these handlers are expected to succeed if the return type is `void`.
#### plat_pm_ops.affinst_standby()
......@@ -1268,10 +1284,11 @@ state or EL3/S-EL1 in the secure state. The design of this framework is
described in the [IMF Design Guide]
A platform should export the following APIs to support the IMF. The following
text briefly describes each api and its implementation on the FVP port. The API
implementation depends upon the type of interrupt controller present in the
platform. The FVP implements an ARM Generic Interrupt Controller (ARM GIC) as
per the version 2.0 of the [ARM GIC Architecture Specification]
text briefly describes each api and its implementation in ARM standard
platforms. The API implementation depends upon the type of interrupt controller
present in the platform. ARM standard platforms implements an ARM Generic
Interrupt Controller (ARM GIC) as per the version 2.0 of the
[ARM GIC Architecture Specification].
### Function : plat_interrupt_type_to_line() [mandatory]
......@@ -1291,8 +1308,8 @@ security state of the originating execution context. The return result is the
bit position in the `SCR_EL3` register of the respective interrupt trap: IRQ=1,
FIQ=2.
The FVP port configures the ARM GIC to signal S-EL1 interrupts as FIQs and
Non-secure interrupts as IRQs from either security state.
ARM standard platforms configure the ARM GIC to signal S-EL1 interrupts
as FIQs and Non-secure interrupts as IRQs from either security state.
### Function : plat_ic_get_pending_interrupt_type() [mandatory]
......@@ -1306,9 +1323,9 @@ handler function. `INTR_TYPE_INVAL` is returned when there is no interrupt
pending. The valid interrupt types that can be returned are `INTR_TYPE_EL3`,
`INTR_TYPE_S_EL1` and `INTR_TYPE_NS`.
The FVP port reads the _Highest Priority Pending Interrupt Register_
(`GICC_HPPIR`) to determine the id of the pending interrupt. The type of interrupt
depends upon the id value as follows.
ARM standard platforms read the _Highest Priority Pending Interrupt
Register_ (`GICC_HPPIR`) to determine the id of the pending interrupt. The type
of interrupt depends upon the id value as follows.
1. id < 1022 is reported as a S-EL1 interrupt
2. id = 1022 is reported as a Non-secure interrupt.
......@@ -1325,9 +1342,9 @@ platform IC. The IMF passes the id returned by this API to the registered
handler for the pending interrupt if the `IMF_READ_INTERRUPT_ID` build time flag
is set. INTR_ID_UNAVAILABLE is returned when there is no interrupt pending.
The FVP port reads the _Highest Priority Pending Interrupt Register_
(`GICC_HPPIR`) to determine the id of the pending interrupt. The id that is
returned by API depends upon the value of the id read from the interrupt
ARM standard platforms read the _Highest Priority Pending Interrupt
Register_ (`GICC_HPPIR`) to determine the id of the pending interrupt. The id
that is returned by API depends upon the value of the id read from the interrupt
controller as follows.
1. id < 1022. id is returned as is.
......@@ -1346,10 +1363,11 @@ This API is used by the CPU to indicate to the platform IC that processing of
the highest pending interrupt has begun. It should return the id of the
interrupt which is being processed.
The FVP port reads the _Interrupt Acknowledge Register_ (`GICC_IAR`). This
changes the state of the highest priority pending interrupt from pending to
active in the interrupt controller. It returns the value read from the
`GICC_IAR`. This value is the id of the interrupt whose state has been changed.
This function in ARM standard platforms reads the _Interrupt Acknowledge
Register_ (`GICC_IAR`). This changes the state of the highest priority pending
interrupt from pending to active in the interrupt controller. It returns the
value read from the `GICC_IAR`. This value is the id of the interrupt whose
state has been changed.
The TSP uses this API to start processing of the secure physical timer
interrupt.
......@@ -1365,7 +1383,7 @@ the interrupt corresponding to the id (passed as the parameter) has
finished. The id should be the same as the id returned by the
`plat_ic_acknowledge_interrupt()` API.
The FVP port writes the id to the _End of Interrupt Register_
ARM standard platforms write the id to the _End of Interrupt Register_
(`GICC_EOIR`). This deactivates the corresponding interrupt in the interrupt
controller.
......@@ -1384,10 +1402,12 @@ interrupt type (one of `INTR_TYPE_EL3`, `INTR_TYPE_S_EL1` and `INTR_TYPE_NS`) is
returned depending upon how the interrupt has been configured by the platform
IC.
The FVP port configures S-EL1 interrupts as Group0 interrupts and Non-secure
interrupts as Group1 interrupts. It reads the group value corresponding to the
interrupt id from the relevant _Interrupt Group Register_ (`GICD_IGROUPRn`). It
uses the group value to determine the type of interrupt.
This function in ARM standard platforms configures S-EL1 interrupts
as Group0 interrupts and Non-secure interrupts as Group1 interrupts. It reads
the group value corresponding to the interrupt id from the relevant _Interrupt
Group Register_ (`GICD_IGROUPRn`). It uses the group value to determine the
type of interrupt.
3.5 Crash Reporting mechanism (in BL3-1)
----------------------------------------------
......@@ -1409,9 +1429,6 @@ This API is used by the crash reporting mechanism to initialize the crash
console. It should only use the general purpose registers x0 to x2 to do the
initialization and returns 1 on success.
The FVP port designates the `PL011_UART0` as the crash console and calls the
console_core_init() to initialize the console.
### Function : plat_crash_console_putc
Argument : int
......@@ -1422,9 +1439,6 @@ designated crash console. It should only use general purpose registers x1 and
x2 to do its work. The parameter and the return value are in general purpose
register x0.
The FVP port designates the `PL011_UART0` as the crash console and calls the
console_core_putc() to print the character on the console.
4. Build flags
---------------
......@@ -1493,11 +1507,11 @@ required in their respective `blx_platform_setup()` functions. Currently
storage access is only required by BL1 and BL2 phases. The `load_image()`
function uses the storage layer to access non-volatile platform storage.
It is mandatory to implement at least one storage driver. For the FVP the
Firmware Image Package(FIP) driver is provided as the default means to load data
from storage (see the "Firmware Image Package" section in the [User Guide]).
The storage layer is described in the header file
`include/drivers/io/io_storage.h`. The implementation of the common library
It is mandatory to implement at least one storage driver. For the ARM
development platforms the Firmware Image Package (FIP) driver is provided as
the default means to load data from storage (see the "Firmware Image Package"
section in the [User Guide]). The storage layer is described in the header file
`include/drivers/io/io_storage.h`. The implementation of the common library
is in `drivers/io/io_storage.c` and the driver files are located in
`drivers/io/`.
......@@ -1533,20 +1547,20 @@ amount of open resources per driver.
- - - - - - - - - - - - - - - - - - - - - - - - - -
_Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved._
_Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._
[ARM GIC Architecture Specification]: http://arminfo.emea.arm.com/help/topic/com.arm.doc.ihi0048b/IHI0048B_gic_architecture_specification.pdf
[IMF Design Guide]: interrupt-framework-design.md
[User Guide]: user-guide.md
[FreeBSD]: http://www.freebsd.org
[Firmware Design Guide]: firmware-design.md
[Firmware Design]: firmware-design.md
[plat/common/aarch64/platform_mp_stack.S]: ../plat/common/aarch64/platform_mp_stack.S
[plat/common/aarch64/platform_up_stack.S]: ../plat/common/aarch64/platform_up_stack.S
[plat/fvp/include/platform_def.h]: ../plat/fvp/include/platform_def.h
[plat/fvp/include/plat_macros.S]: ../plat/fvp/include/plat_macros.S
[plat/fvp/aarch64/plat_common.c]: ../plat/fvp/aarch64/plat_common.c
[plat/fvp/plat_pm.c]: ../plat/fvp/plat_pm.c
[plat/arm/board/fvp/fvp_pm.c]: ../plat/arm/board/fvp/fvp_pm.c
[include/runtime_svc.h]: ../include/runtime_svc.h
[include/plat/arm/common/arm_def.h]: ../include/plat/arm/common/arm_def.h
[include/plat/common/common_def.h]: ../include/plat/common/common_def.h
[include/plat/common/platform.h]: ../include/plat/common/platform.h
[include/plat/arm/common/plat_arm.h]: ../include/plat/arm/common/plat_arm.h]
......@@ -206,8 +206,8 @@ performed.
wants the timer registers to be saved and restored.
* `PLAT`: Choose a platform to build ARM Trusted Firmware for. The chosen
platform name must be the name of one of the directories under the `plat/`
directory other than `common`.
platform name must be subdirectory of any depth under `plat/`, and must
contain a platform makefile named `platform.mk`.
* `SPD`: Choose a Secure Payload Dispatcher component to be built into the
Trusted Firmware. The value should be the path to the directory containing
......@@ -320,21 +320,16 @@ performed.
* `BL33_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
file that contains the BL3-3 private key in PEM format.
#### FVP specific build options
#### ARM development platform specific build options
* `FVP_TSP_RAM_LOCATION`: location of the TSP binary. Options:
* `ARM_TSP_RAM_LOCATION_ID`: location of the TSP binary. Options:
- `tsram` : Trusted SRAM (default option)
- `tdram` : Trusted DRAM
- `tdram` : Trusted DRAM (if available)
- `dram` : Secure region in DRAM (configured by the TrustZone controller)
For a better understanding of FVP options, the FVP memory map is explained in
the [Firmware Design].
For a better understanding of these options, the ARM development platform memory
map is explained in the [Firmware Design].
#### Juno specific build options
* `PLAT_TSP_LOCATION`: location of the TSP binary. Options:
- `tsram` : Trusted SRAM (default option)
- `dram` : Secure region in DRAM (set by the TrustZone controller)
### Creating a Firmware Image Package
......@@ -409,8 +404,8 @@ When debugging logic problems it might also be useful to disable all compiler
optimizations by using `-O0`.
NOTE: Using `-O0` could cause output images to be larger and base addresses
might need to be recalculated (see the "Memory layout of BL images" section in
the [Firmware Design]).
might need to be recalculated (see the **Memory layout on ARM development
platforms** section in the [Firmware Design]).
Extra debug options can be passed to the build system by setting `CFLAGS`:
......@@ -461,7 +456,7 @@ FVP_AARCH64_EFI.fd as BL3-3 image:
The `cert_create` tool can be built separately through the following commands:
$ cd tools/cert_create
$ make [DEBUG=1] [V=1]
$ make PLAT=<platform> [DEBUG=1] [V=1]
`DEBUG=1` builds the tool in debug mode. `V=1` makes the build process more
verbose. The following command should be used to obtain help about the tool:
......
/*
* Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -31,40 +31,17 @@
#include <asm_macros.S>
#include <pl011.h>
.globl console_init
.globl console_putc
/*
* Pull in generic functions to provide backwards compatibility for
* platform makefiles
*/
#include "../../console/console.S"
.globl console_core_init
.globl console_core_putc
.globl console_getc
.globl console_core_getc
/*
* The console base is in the data section and not in .bss
* even though it is zero-init. In particular, this allows
* the console functions to start using this variable before
* the runtime memory is initialized for images which do not
* need to copy the .data section from ROM to RAM.
*/
.section .data.console_base ; .align 3
console_base: .quad 0x0
/* -----------------------------------------------
* int console_init(unsigned long base_addr,
* unsigned int uart_clk, unsigned int baud_rate)
* Function to initialize the console without a
* C Runtime to print debug information. It saves
* the console base to the data section.
* In: x0 - console base address
* w1 - Uart clock in Hz
* w2 - Baud rate
* out: return 1 on success.
* Clobber list : x1 - x3
* -----------------------------------------------
*/
func console_init
adrp x3, console_base
str x0, [x3, :lo12:console_base]
b console_core_init
endfunc console_init
/* -----------------------------------------------
* int console_core_init(unsigned long base_addr,
......@@ -76,16 +53,16 @@ endfunc console_init
* In: x0 - console base address
* w1 - Uart clock in Hz
* w2 - Baud rate
* Out: return 1 on success
* Out: return 1 on success else 0 on error
* Clobber list : x1, x2
* -----------------------------------------------
*/
func console_core_init
/* Check the input base address */
cbz x0, init_fail
cbz x0, core_init_fail
/* Check baud rate and uart clock for sanity */
cbz w1, init_fail
cbz w2, init_fail
cbz w1, core_init_fail
cbz w2, core_init_fail
/* Program the baudrate */
/* Divisor = (Uart clock * 4) / baudrate */
lsl w1, w1, #2
......@@ -106,28 +83,14 @@ func console_core_init
mov w1, #(PL011_UARTCR_RXE | PL011_UARTCR_TXE | PL011_UARTCR_UARTEN)
str w1, [x0, #UARTCR]
mov w0, #1
init_fail:
ret
core_init_fail:
mov w0, wzr
ret
endfunc console_core_init
/* ---------------------------------------------
* int console_putc(int c)
* Function to output a character over the
* console. It returns the character printed on
* success or -1 on error.
* In : x0 - character to be printed
* Out : return -1 on error else return character.
* Clobber list : x1, x2
* ---------------------------------------------
*/
func console_putc
adrp x2, console_base
ldr x1, [x2, :lo12:console_base]
b console_core_putc
endfunc console_putc
/* --------------------------------------------------------
* int console_core_putc(int c, unsigned int base_addr)
* int console_core_putc(int c, unsigned long base_addr)
* Function to output a character over the console. It
* returns the character printed on success or -1 on error.
* In : w0 - character to be printed
......@@ -160,24 +123,24 @@ putc_error:
endfunc console_core_putc
/* ---------------------------------------------
* int console_getc(void)
* int console_core_getc(unsigned long base_addr)
* Function to get a character from the console.
* It returns the character grabbed on success
* or -1 on error.
* In : x0 - console base address
* Clobber list : x0, x1
* ---------------------------------------------
*/
func console_getc
adrp x0, console_base
ldr x1, [x0, :lo12:console_base]
cbz x1, getc_error
func console_core_getc
cbz x0, getc_error
1:
/* Check if the receive FIFO is empty */
ldr w0, [x1, #UARTFR]
tbnz w0, #PL011_UARTFR_RXFE_BIT, 1b
ldr w0, [x1, #UARTDR]
ldr w1, [x0, #UARTFR]
tbnz w1, #PL011_UARTFR_RXFE_BIT, 1b
ldr w1, [x0, #UARTDR]
mov w0, w1
ret
getc_error:
mov w0, #-1
ret
endfunc console_getc
endfunc console_core_getc
/*
* Copyright (c) 2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -191,15 +191,41 @@ void tzc_init(uint64_t base)
BUILD_CONFIG_NR_MASK) + 1;
}
/*
* `tzc_configure_region0` is used to program region 0 into the TrustZone
* controller. Region 0 covers the whole address space that is not mapped
* to any other region, and is enabled on all filters; this cannot be
* changed. This function only changes the access permissions.
*/
void tzc_configure_region0(tzc_region_attributes_t sec_attr,
uint32_t ns_device_access)
{
assert(tzc.base);
VERBOSE("TZC : Configuring region 0 (sec_attr=0x%x, ns_devs=0x%x)\n",
sec_attr, ns_device_access);
assert(sec_attr <= TZC_REGION_S_RDWR);
/* Set secure attributes on region 0 */
tzc_write_region_attributes(tzc.base, 0,
sec_attr << REG_ATTR_SEC_SHIFT);
/*
* Specify which non-secure devices have permission to access
* region 0.
*/
tzc_write_region_id_access(tzc.base, 0, ns_device_access);
}
/*
* `tzc_configure_region` is used to program regions into the TrustZone
* controller. A region can be associated with more than one filter. The
* associated filters are passed in as a bitmap (bit0 = filter0).
* NOTE:
* The region 0 covers the whole address space and is enabled on all filters,
* this cannot be changed. It is, however, possible to change some region 0
* permissions.
* Region 0 is special; it is preferable to use tzc_configure_region0
* for this region (see comment for that function).
*/
void tzc_configure_region(uint32_t filters,
uint8_t region,
......@@ -210,6 +236,13 @@ void tzc_configure_region(uint32_t filters,
{
assert(tzc.base);
VERBOSE("TZC : Configuring region (filters=0x%x, region=%d, ...\n",
filters, region);
VERBOSE("TZC : ... base=0x%lx, top=0x%lx, ...\n",
region_base, region_top);
VERBOSE("TZC : ... sec_attr=0x%x, ns_devs=0x%x)\n",
sec_attr, ns_device_access);
/* Do range checks on filters and regions. */
assert(((filters >> tzc.num_filters) == 0) &&
(region < tzc.num_regions));
......
/*
* Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* Neither the name of ARM nor the names of its contributors may be used
* to endorse or promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include <asm_macros.S>
.globl console_init
.globl console_putc
.globl console_getc
/*
* The console base is in the data section and not in .bss
* even though it is zero-init. In particular, this allows
* the console functions to start using this variable before
* the runtime memory is initialized for images which do not
* need to copy the .data section from ROM to RAM.
*/
.section .data.console_base ; .align 3
console_base: .quad 0x0
/* -----------------------------------------------
* int console_init(unsigned long base_addr,
* unsigned int uart_clk, unsigned int baud_rate)
* Function to initialize the console without a
* C Runtime to print debug information. It saves
* the console base to the data section.
* In: x0 - console base address
* w1 - Uart clock in Hz
* w2 - Baud rate
* out: return 1 on success else 0 on error
* Clobber list : x1 - x3
* -----------------------------------------------
*/
func console_init
/* Check the input base address */
cbz x0, init_fail
adrp x3, console_base
str x0, [x3, :lo12:console_base]
b console_core_init
init_fail:
ret
endfunc console_init
/* ---------------------------------------------
* int console_putc(int c)
* Function to output a character over the
* console. It returns the character printed on
* success or -1 on error.
* In : x0 - character to be printed
* Out : return -1 on error else return character.
* Clobber list : x1, x2
* ---------------------------------------------
*/
func console_putc
adrp x2, console_base
ldr x1, [x2, :lo12:console_base]
b console_core_putc
endfunc console_putc
/* ---------------------------------------------
* int console_getc(void)
* Function to get a character from the console.
* It returns the character grabbed on success
* or -1 on error.
* Clobber list : x0, x1
* ---------------------------------------------
*/
func console_getc
adrp x1, console_base
ldr x0, [x1, :lo12:console_base]
b console_core_getc
endfunc console_getc
/*
* Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* Neither the name of ARM nor the names of its contributors may be used
* to endorse or promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include <asm_macros.S>
/*
* This file contains a skeleton console implementation that can
* be used as basis for a real console implementation by platforms
* that do not contain PL011 hardware.
*/
.globl console_core_init
.globl console_core_putc
.globl console_core_getc
/* -----------------------------------------------
* int console_core_init(unsigned long base_addr,
* unsigned int uart_clk, unsigned int baud_rate)
* Function to initialize the console without a
* C Runtime to print debug information. This
* function will be accessed by console_init and
* crash reporting.
* In: x0 - console base address
* w1 - Uart clock in Hz
* w2 - Baud rate
* Out: return 1 on success else 0 on error
* Clobber list : x1, x2
* -----------------------------------------------
*/
func console_core_init
/* Check the input base address */
cbz x0, core_init_fail
/* Check baud rate and uart clock for sanity */
cbz w1, core_init_fail
cbz w2, core_init_fail
/* Insert implementation here */
mov w0, #1
ret
core_init_fail:
mov w0, wzr
ret
endfunc console_core_init
/* --------------------------------------------------------
* int console_core_putc(int c, unsigned long base_addr)
* Function to output a character over the console. It
* returns the character printed on success or -1 on error.
* In : w0 - character to be printed
* x1 - console base address
* Out : return -1 on error else return character.
* Clobber list : x2
* --------------------------------------------------------
*/
func console_core_putc
/* Check the input parameter */
cbz x1, putc_error
/* Insert implementation here */
ret
putc_error:
mov w0, #-1
ret
endfunc console_core_putc
/* ---------------------------------------------
* int console_core_getc(unsigned long base_addr)
* Function to get a character from the console.
* It returns the character grabbed on success
* or -1 on error.
* In : x0 - console base address
* Clobber list : x0, x1
* ---------------------------------------------
*/
func console_core_getc
cbz x0, getc_error
/* Insert implementation here */
ret
getc_error:
mov w0, #-1
ret
endfunc console_core_getc
/*
* Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -27,6 +27,8 @@
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef __ASM_MACROS_S__
#define __ASM_MACROS_S__
#include <arch.h>
......@@ -204,3 +206,5 @@ wait_for_entrypoint:
_mov_imm16 \_reg, (\_val), 48
.endif
.endm
#endif /* __ASM_MACROS_S__ */
/*
* Copyright (c) 2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -27,6 +27,8 @@
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef __ASSERT_MACROS_S__
#define __ASSERT_MACROS_S__
/*
* Assembler macro to enable asm_assert. Use this macro wherever
......@@ -47,3 +49,5 @@
mov x1, __LINE__ ;\
b asm_assert ;\
300:
#endif /* __ASSERT_MACROS_S__ */
......@@ -110,6 +110,26 @@
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
/*
* Declarations of linker defined symbols to help determine memory layout of
* BL images
*/
extern unsigned long __RO_START__;
extern unsigned long __RO_END__;
#if IMAGE_BL2
extern unsigned long __BL2_END__;
#elif IMAGE_BL31
extern unsigned long __BL31_END__;
#elif IMAGE_BL32
extern unsigned long __BL32_END__;
#endif /* IMAGE_BLX */
#if USE_COHERENT_MEM
extern unsigned long __COHERENT_RAM_START__;
extern unsigned long __COHERENT_RAM_END__;
#endif
/*******************************************************************************
* Structure used for telling the next BL how much of a particular type of
* memory is available for its use and how much is already used.
......
/*
* Copyright (c) 2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -31,7 +31,6 @@
#ifndef __TZC400_H__
#define __TZC400_H__
#include <stdint.h>
#define BUILD_CONFIG_OFF 0x000
#define ACTION_OFF 0x004
......@@ -148,9 +147,13 @@
#define TZC_REGION_ACCESS_RDWR(id) \
(TZC_REGION_ACCESS_RD(id) | TZC_REGION_ACCESS_WR(id))
/* Filters are bit mapped 0 to 3. */
#define TZC400_COMPONENT_ID 0xb105f00d
#ifndef __ASSEMBLY__
#include <stdint.h>
/*******************************************************************************
* Function & variable prototypes
******************************************************************************/
......@@ -187,6 +190,8 @@ typedef enum {
void tzc_init(uint64_t base);
void tzc_configure_region0(tzc_region_attributes_t sec_attr,
uint32_t ns_device_access);
void tzc_configure_region(uint32_t filters,
uint8_t region,
uint64_t region_base,
......@@ -197,5 +202,6 @@ void tzc_enable_filters(void);
void tzc_disable_filters(void);
void tzc_set_action(tzc_action_t action);
#endif /* __ASSEMBLY__ */
#endif /* __TZC400__ */
/*
* Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -302,6 +302,23 @@
((endian) & SPSR_E_MASK) << SPSR_E_SHIFT | \
((aif) & SPSR_AIF_MASK) << SPSR_AIF_SHIFT)
/*
* CTR_EL0 definitions
*/
#define CTR_CWG_SHIFT 24
#define CTR_CWG_MASK 0xf
#define CTR_ERG_SHIFT 20
#define CTR_ERG_MASK 0xf
#define CTR_DMINLINE_SHIFT 16
#define CTR_DMINLINE_MASK 0xf
#define CTR_L1IP_SHIFT 14
#define CTR_L1IP_MASK 0x3
#define CTR_IMINLINE_SHIFT 0
#define CTR_IMINLINE_MASK 0xf
#define MAX_CACHE_LINE_SIZE 0x800 /* 2KB */
#define SIZE_FROM_LOG2_WORDS(n) (4 << (n))
/* Physical timer control register bit fields shifts and masks */
#define CNTP_CTL_ENABLE_SHIFT 0
......
/*
* Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -281,6 +281,8 @@ DEFINE_SYSREG_RW_FUNCS(vmpidr_el2)
DEFINE_SYSREG_READ_FUNC(isr_el1)
DEFINE_SYSREG_READ_FUNC(ctr_el0)
/* GICv3 System Registers */
DEFINE_RENAME_SYSREG_RW_FUNCS(icc_sre_el1, ICC_SRE_EL1)
......
/*
* Copyright (c) 2014, ARM Limited and Contributors. All rights reserved.
* Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
......@@ -27,6 +27,8 @@
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef __CPU_MACROS_S__
#define __CPU_MACROS_S__
#include <arch.h>
......@@ -80,3 +82,5 @@ CPU_OPS_SIZE = .
.quad \_name\()_cpu_reg_dump
#endif
.endm
#endif /* __CPU_MACROS_S__ */
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment