When a platform port does not define PLAT_PERCPU_BAKERY_LOCK_SIZE, the total
memory that should be allocated per-cpu to accommodate all bakery locks is
calculated by the linker in bl31.ld.S. The linker stores this value in the
__PERCPU_BAKERY_LOCK_SIZE__ linker symbol. The runtime value of this symbol is
different from the link time value as the symbol is relocated into the current
section (.bss). This patch fixes this issue by marking the symbol as ABSOLUTE
which allows it to retain its correct value even at runtime.
The description of PLAT_PERCPU_BAKERY_LOCK_SIZE in the porting-guide.md has been
made clearer as well.
Change-Id: Ia0cfd42f51deaf739d792297e60cad5c6e6e610b
On the ARMv8 architecture, cache maintenance operations by set/way on the last
level of integrated cache do not affect the system cache. This means that such a
flush or clean operation could result in the data being pushed out to the system
cache rather than main memory. Another CPU could access this data before it
enables its data cache or MMU. Such accesses could be serviced from the main
memory instead of the system cache. If the data in the sysem cache has not yet
been flushed or evicted to main memory then there could be a loss of
coherency. The only mechanism to guarantee that the main memory will be updated
is to use cache maintenance operations to the PoC by MVA(See section D3.4.11
(System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G).
This patch removes the reliance of Trusted Firmware on the flush by set/way
operation to ensure visibility of data in the main memory. Cache maintenance
operations by MVA are now used instead. The following are the broad category of
changes:
1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is
initialised. This ensures that any stale cache lines at any level of cache
are removed.
2. Updates to global data in runtime firmware (BL31) by the primary CPU are made
visible to secondary CPUs using a cache clean operation by MVA.
3. Cache maintenance by set/way operations are only used prior to power down.
NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN
ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES.
FixesARM-software/tf-issues#205
Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
This patch unifies the bakery lock api's across coherent and normal
memory implementation of locks by using same data type `bakery_lock_t`
and similar arguments to functions.
A separate section `bakery_lock` has been created and used to allocate
memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are
allocated in normal memory, each lock for a core has to spread
across multiple cache lines. By using the total size allocated in a
separate cache line for a single core at compile time, the memory for
other core locks is allocated at link time by multiplying the single
core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock
algorithm now uses lock address instead of the `id` in the per_cpu_data.
For locks allocated in coherent memory, it moves locks from
tzfw_coherent_memory to bakery_lock section.
The bakery locks are allocated as part of bss or in coherent memory
depending on usage of coherent memory. Both these regions are
initialised to zero as part of run_time_init before locks are used.
Hence, bakery_lock_init() is made an empty function as the lock memory
is already initialised to zero.
The above design lead to the removal of psci bakery locks from
non_cpu_power_pd_node to psci_locks.
NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED.
THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY
LOCKS IN NORMAL MEMORY.
Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b
This patch extends the build option `USE_COHERENT_MEMORY` to
conditionally remove coherent memory from the memory maps of
all boot loader stages. The patch also adds necessary
documentation for coherent memory removal in firmware-design,
porting and user guides.
FixesARM-Software/tf-issues#106
Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
This patch fixes the incorrect value of the LENGTH attribute in
the linker scripts. This attribute must define the memory size, not
the limit address.
FixesARM-software/tf-issues#252
Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46
This patch introduces a framework which will allow CPUs to perform
implementation defined actions after a CPU reset, during a CPU or cluster power
down, and when a crash occurs. CPU specific reset handlers have been implemented
in this patch. Other handlers will be implemented in subsequent patches.
Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/.
Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
BLn_BASE and BLn_LIMIT definitions have been updated and are based on
these new memory regions.
The available memory for each bootloader in the linker script is
defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
region.
TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
the platform porting.
FVP common definitions are defined in fvp_def.h while platform_def.h
contains exclusively (with a few exceptions) the definitions that are
mandatory in the porting guide. Therefore, platform_def.h now includes
fvp_def.h instead of the other way around.
Porting guide has been updated to reflect these changes.
Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
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.
FixesARM-software/tf-issues#117
Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
Previously, platform.h contained many declarations and definitions
used for different purposes. This file has been split so that:
* Platform definitions used by common code that must be defined
by the platform are now in platform_def.h. The exact include
path is exported through $PLAT_INCLUDES in the platform makefile.
* Platform definitions specific to the FVP platform are now in
/plat/fvp/fvp_def.h.
* Platform API declarations specific to the FVP platform are now
in /plat/fvp/fvp_private.h.
* The remaining platform API declarations that must be ported by
each platform are still in platform.h but this file has been
moved to /include/plat/common since this can be shared by all
platforms.
Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a
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.
FixesARM-software/tf-issues#163
Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c
All common functions are being built into all binary images,
whether or not they are actually used. This change enables the
use of -ffunction-sections, -fdata-sections and --gc-sections
in the compiler and linker to remove unused code and data from
the images.
Change-Id: Ia9f78c01054ac4fa15d145af38b88a0d6fb7d409
At present, the entry point for each BL image is specified via the
Makefiles and provided on the command line to the linker. When using a
link script the entry point should rather be specified via the ENTRY()
directive in the link script.
This patch updates linker scripts of all BL images to specify the entry
point using the ENTRY() directive. It also removes the --entry flag
passed to the linker through Makefile.
Fixes issue ARM-software/tf-issues#66
Change-Id: I1369493ebbacea31885b51185441f6b628cf8da0
The BL31 and BL2 linker scripts ended up having duplicate descriptions
for xlat_tables section. This patch removes those duplicate
descriptions.
Change-Id: Ibbdda0902c57fca5ea4e91e0baefa6df8f0a9bb1
This patch factors out the ARM FVP specific code to create MMU
translation tables so that it is possible for a boot loader stage to
create a different set of tables instead of using the default ones.
The default translation tables are created with the assumption that
the calling boot loader stage executes out of secure SRAM. This might
not be true for the BL3_2 stage in the future.
A boot loader stage can define the `fill_xlation_tables()` function as
per its requirements. It returns a reference to the level 1
translation table which is used by the common platform code to setup
the TTBR_EL3.
This patch is a temporary solution before a larger rework of
translation table creation logic is introduced.
Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6
This patch introduces the framework to enable registration and
initialisation of runtime services. PSCI is registered and initialised
as a runtime service. Handling of runtime service requests will be
implemented in subsequent patches.
Change-Id: Id21e7ddc5a33d42b7d6e455b41155fc5441a9547
This patch ensures that VBAR_EL3 points to the simple stack-less
'early_exceptions' when the C runtime stack is not correctly setup to
use the more complex 'runtime_exceptions'. It is initialised to
'runtime_exceptions' once this is done.
This patch also moves all exception vectors into a '.vectors' section
and modifies linker scripts to place all such sections together. This
will minimize space wastage from alignment restrictions.
Change-Id: I8c3e596ea3412c8bd582af9e8d622bb1cb2e049d
This patch moves the translation tables into their own section. This
saves space that would otherwise have been lost in padding due to page
table alignment constraints. The BL31 and BL32 bases have been
consequently adjusted.
Change-Id: Ibd65ae8a5ce4c4ea9a71a794c95bbff40dc63e65
- Add instructions for contributing to ARM Trusted Firmware.
- Update copyright text in all files to acknowledge contributors.
Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
- Check at link-time that bootloader images will fit in memory
at run time and that they won't overlap each other.
- Remove text and rodata orphan sections.
- Define new linker symbols to remove the need for platform setup
code to know the order of sections.
- Reduce the size of the raw binary images by cutting some sections
out of the disk image and allocating them at load time, whenever
possible.
- Rework alignment constraints on sections.
- Remove unused linker symbols.
- Homogenize linker symbols names across all BLs.
- Add some comments in the linker scripts.
Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9