2015-12-01 |
Merge pull request #442 from soby-mathew/sm/remove_imf_read_intid
...
Remove the IMF_READ_INTERRUPT_ID build option
danh-arm
committed
on 1 Dec 2015
|
2015-11-27 |
Fix TZC-400 peripheral detection
...
The TZC-400 driver implementation incorrectly uses the component
ID registers to detect the TZC-400 peripheral. As all ARM
peripherals share the same component ID, it doesn't allow to
uniquely identify the TZC-400 peripheral. This patch fixes the
TZC-400 driver by relying on the `part_number_0` and
`part_number_1` fields in the `PID` registers instead.
The `tzc_read_component_id` function has been replaced by
`tzc_read_peripheral_id`, which reads the 'part_number' values
and compares them with the TZC-400 peripheral ID.
Also, it adds a debug assertion to detect when the TZC driver
initialisation function is called multiple times.
Change-Id: I35949f6501a51c0a794144cd1c3a6db62440dce6
Vikram Kanigiri
committed
on 27 Nov 2015
|
Add a simple ARM SP805 watchdog driver
...
Based on SP805 Programmer's model (ARM DDI 0270B). This driver
provides three public APIs:
void sp805_start(uintptr_t base, unsigned long ticks);
void sp805_stop(uintptr_t base);
void sp805_refresh(uintptr_t base, unsigned long ticks);
Upon start, the watchdog starts counting down from the number of
ticks specified. When the count reaches 0 an interrupt is triggered.
The watchdog restarts counting down from the number of ticks
specified. If the count reaches 0 again, the system is reset. A
mechanism to handle the interrupt has not been implemented. Instead,
the API to refresh the watchdog should be used instead to prevent a
system reset.
Change-Id: I799d53f8d1213b10b341a4a67fde6486e89a3dab
Juan Castillo
committed
on 27 Nov 2015
|
Add basic NOR flash driver for ARM platforms
...
FVP and Juno platforms include a NOR flash memory to store and
load the FIP, the kernel or a ramdisk. This NOR flash is arranged
as 2 x 16 bit flash devices and can be programmed using CFI
standard commands.
This patch provides a basic API to write single 32 bit words of
data into the NOR flash. Functions to lock/unlock blocks against
erase or write operations are also provided.
Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
Juan Castillo
committed
on 27 Nov 2015
|
2015-11-26 |
User Guide: Remove reference to porting guide
...
The implications of the 'PROGRAMMABLE_RESET_ADDRESS' build option on
the platform porting layer are simple enough to be described in the
User Guide directly. This patch removes the reference to the Porting
Guide.
Change-Id: I7f753b18abd20effc4fd30836609e1fd51d9221d
Sandrine Bailleux
authored
on 11 Nov 2015
Achin Gupta
committed
on 26 Nov 2015
|
Introduce COLD_BOOT_SINGLE_CPU build option
...
This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
which allows platforms that only release a single CPU out of reset to
slightly optimise their cold boot code, both in terms of code size
and performance.
COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform
may release several CPUs out of reset. In this case, the cold reset
code needs to coordinate all CPUs via the usual primary/secondary
CPU distinction.
If a platform guarantees that only a single CPU will ever be released
out of reset, there is no need to arbitrate execution ; the notion of
primary and secondary CPUs itself no longer exists. Such platforms
may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the
primary/secondary CPU identification in the cold reset code.
All ARM standard platforms can release several CPUs out of reset
so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like
Juno, bringing up more than one CPU at reset should only be attempted
when booting an EL3 payload, as it is not fully supported in the
normal boot flow.
For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform
APIs become optional:
- plat_secondary_cold_boot_setup();
- plat_is_my_cpu_primary().
The Porting Guide has been updated to reflect that.
User Guide updated as well.
Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b
Sandrine Bailleux
authored
on 30 Oct 2015
Achin Gupta
committed
on 26 Nov 2015
|
Document the EL3 payload support
...
- Document the new build option EL3_PAYLOAD_BASE
- Document the EL3 payload boot flow
- Document the FVP model parameters to boot an EL3 payload
Change-Id: Ie6535914a9a68626e4401659bee4fcfd53d4bd37
Sandrine Bailleux
authored
on 1 Oct 2015
Achin Gupta
committed
on 26 Nov 2015
|
FVP: Do not power off secondary CPUs when booting an EL3 payload
...
Normally, in the FVP port, secondary CPUs are immediately powered
down if they are powered on at reset. However, when booting an EL3
payload, we need to keep them powered on as the requirement is for
all CPUs to enter the EL3 payload image. This patch puts them in a
holding pen instead of powering them off.
Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
Sandrine Bailleux
authored
on 2 Oct 2015
Achin Gupta
committed
on 26 Nov 2015
|
CSS: Put secondary CPUs in a pen when booting an EL3 payload
...
By default, only the primary CPU is powered on by SCP on CSS
platforms. Secondary CPUs are then powered on later using PSCI
calls.
However, it is possible to power on more than one CPU at boot time
using platform specific settings. In this case, several CPUs will
enter the Trusted Firmware and execute the cold boot path code.
This is currently not supported and secondary CPUs will panic.
This patch preserves this behaviour in the normal boot flow.
However, when booting an EL3 payload, secondary CPUs are now held in
a pen until their mailbox is populated, at which point they jump to
this address. Note that, since all CPUs share the same mailbox, they
will all be released from their holding pen at the same time and the
EL3 payload is responsible to arbitrate execution between CPUs if
required.
Change-Id: I83737e0c9f15ca5e73afbed2e9c761bc580735b9
Sandrine Bailleux
authored
on 29 Apr 2015
Achin Gupta
committed
on 26 Nov 2015
|
CSS: Enable booting of EL3 payloads
...
This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.
Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.
The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.
The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.
The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.
This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.
Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
Sandrine Bailleux
authored
on 26 Nov 2015
Achin Gupta
committed
on 26 Nov 2015
|
Pass the entry point info to bl1_plat_prepare_exit()
...
This patch modifies the prototype of the bl1_plat_prepare_exit()
platform API to pass the address of the entry point info structure
received from BL2. The structure contains information that can be
useful, depending on the kind of clean up or bookkeeping operations
to perform.
The weak implementation of this function ignores this argument to
preserve platform backwards compatibility.
NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE
FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API.
Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb
Sandrine Bailleux
authored
on 10 Nov 2015
Achin Gupta
committed
on 26 Nov 2015
|
Introduce SPIN_ON_BL1_EXIT build flag
...
This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which
puts an infinite loop in BL1. It is intended to help debugging
the post-BL2 phase of the Trusted Firmware by stopping execution
in BL1 just before handing over to BL31. At this point, the
developer may take control of the target using a debugger.
This feature is disabled by default and can be enabled by
rebuilding BL1 with SPIN_ON_BL1_EXIT=1.
User Guide updated accordingly.
Change-Id: I6b6779d5949c9e5571dd371255520ef1ac39685c
Sandrine Bailleux
authored
on 10 Nov 2015
Achin Gupta
committed
on 26 Nov 2015
|
Remove the IMF_READ_INTERRUPT_ID build option
...
The IMF_READ_INTERRUPT_ID build option enables a feature where the interrupt
ID of the highest priority pending interrupt is passed as a parameter to the
interrupt handler registered for that type of interrupt. This additional read
of highest pending interrupt id from GIC is problematic as it is possible that
the original interrupt may get deasserted and another interrupt of different
type maybe become the highest pending interrupt. Hence it is safer to prevent
such behaviour by removing the IMF_READ_INTERRUPT_ID build option.
The `id` parameter of the interrupt handler `interrupt_type_handler_t` is
now made a reserved parameter with this patch. It will always contain
INTR_ID_UNAVAILABLE.
Fixes ARM-software/tf-issues#307
Change-Id: I2173aae1dd37edad7ba6bdfb1a99868635fa34de
Soby Mathew
committed
on 26 Nov 2015
|
Merge pull request #439 from soby-mathew/sm/new-gic-driver
...
Introduce new GICv3 and GICv2 drivers
Achin Gupta
committed
on 26 Nov 2015
|
Deprecate the GIC Legacy driver.
...
This patch deprecates the legacy ARM GIC driver and related header files
(arm_gic.h, gic_v2.h, gic_v3.h). For GICv2 systems, platform ports should
use the GICv2 driver in include/drivers/arm/gicv2.h and for GICv3 systems,
platform ports should use the GICv3 driver in include/drivers/arm/gicv3.h
NOTE: The ARM Legacy GIC drivers have been deprecated with this patch.
Platform ports are encouraged to migrate to the new GIC drivers.
Change-Id: Ic0460ef0427b54a6aac476279a7f29b81943e942
Soby Mathew
committed
on 26 Nov 2015
|
Add ARM GICv2 driver
...
This patch adds a driver for ARM GICv2 systems, example GIC-400. Unlike
the existing GIC driver in `include/drivers/arm/arm_gic.h`, this driver
is optimised for GICv2 and does not support GICv3 systems in GICv2
compatibility mode. The driver interface has been implemented in
`drivers/arm/gic/v2/gicv2_main.c`. The corresponding header is in
`include/drivers/arm/gicv2.h`. Helper functions are implemented in
`drivers/arm/gic/v2/gicv2_helpers.c` and are accessible through the
`drivers/arm/gic/v2/gicv2_private.h` header.
Change-Id: I09fffa4e621fb99ba3c01204839894816cd89a2a
Soby Mathew
committed
on 26 Nov 2015
|
Add ARM GICv3 driver without support for legacy operation
...
This patch adds a driver for ARM GICv3 systems that need to run software
stacks where affinity routing is enabled across all privileged exception
levels for both security states. This driver is a partial implementation
of the ARM Generic Interrupt Controller Architecture Specification, GIC
architecture version 3.0 and version 4.0 (ARM IHI 0069A). The driver does
not cater for legacy support of interrupts and asymmetric configurations.
The existing GIC driver has been preserved unchanged. The common code for
GICv2 and GICv3 systems has been refactored into a new file,
`drivers/arm/gic/common/gic_common.c`. The corresponding header is in
`include/drivers/arm/gic_common.h`.
The driver interface is implemented in `drivers/arm/gic/v3/gicv3_main.c`.
The corresponding header is in `include/drivers/arm/gicv3.h`. Helper
functions are implemented in `drivers/arm/gic/v3/arm_gicv3_helpers.c`
and are accessible through the `drivers/arm/gic/v3/gicv3_private.h`
header.
Change-Id: I8c3c834a1d049d05b776b4dcb76b18ccb927444a
Achin Gupta
authored
on 3 Sep 2015
Soby Mathew
committed
on 26 Nov 2015
|
Merge pull request #438 from soby-mathew/sm/error_deprecate
...
Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED
Achin Gupta
committed
on 26 Nov 2015
|
2015-11-24 |
Tegra: flowctrl: rename tegra_fc_cpu_idle() to tegra_fc_cpu_powerdn()
...
This patch renames the tegra_fc_cpu_idle() function to a more appropriate
tegra_fc_cpu_powerdn() to better reflect its usage.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Varun Wadekar
committed
on 24 Nov 2015
|
Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED
...
This patch changes the build time behaviour when using deprecated API within
Trusted Firmware. Previously the use of deprecated APIs would only trigger a
build warning (which was always treated as a build error), when
WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always
trigger a build time warning. Whether this warning is treated as error or not
is determined by the build flag ERROR_DEPRECATED which is disabled by default.
When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or
inclusion of deprecated headers will result in a build error.
Also the deprecated context management helpers in context_mgmt.c are now
conditionally compiled depending on the value of ERROR_DEPRECATED flag
so that the APIs themselves do not result in a build error when the
ERROR_DEPRECATED flag is set.
NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to
using ERROR_DEPRECATED, otherwise deprecated API usage will no longer
trigger a build error.
Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a
Soby Mathew
committed
on 24 Nov 2015
|
2015-11-19 |
Merge pull request #435 from sandrine-bailleux/sb/juno-r2
...
Changes to platform reset handler for Juno r2
Achin Gupta
committed
on 19 Nov 2015
|
Merge pull request #429 from vikramkanigiri/vk/fix_sctlr_res1
...
Add missing RES1 bit in SCTLR_EL1
Achin Gupta
committed
on 19 Nov 2015
|
Merge pull request #430 from jcastillo-arm/jc/tf-issues/333
...
Fix build error when `BL32` is not defined
Achin Gupta
committed
on 19 Nov 2015
|
Juno R2: Configure the correct L2 RAM latency values
...
The default reset values for the L2 Data & Tag RAM latencies on the
Cortex-A72 on Juno R2 are not suitable. This patch modifies
the Juno platform reset handler to configure the right settings
on Juno R2.
Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8
Sandrine Bailleux
committed
on 19 Nov 2015
|
Juno: Rework platform reset handler
...
This patch splits the Juno reset handler in 4 distinct pieces:
- Detection of the board revision;
- Juno R0 specific handler;
- Juno R1 specific handler;
- Juno R2 specific handler.
Depending on the board revision, the appropriate handler is called.
This makes the code easier to understand and maintain.
This patch is mainly cosmetic. The only functional change introduced
is that the Juno platform reset handler will now spin infinitely if
the board revision is not recognised. Previously, it would have
assumed that it was running on Juno R1 in this case.
Change-Id: I54ed77c4665085ead9d1573316c9c884d7d3ffa0
Sandrine Bailleux
committed
on 19 Nov 2015
|
2015-11-17 |
Fix build error when `BL32` is not defined
...
If an SPD wants to use a prebuilt binary as BL32 image (for example,
the OPTEE Dispatcher), it must point the `BL32` variable to the
image file. This dependency should apply only to the `fip` target.
However, it also applies to the `all` target at the moment. If the
user tries to build all individual TF images using `make all`
without setting BL32, the build fails. The following command will
throw the error:
make CROSS_COMPILE=aarch64-linux-gnu- SPD=opteed all
...
...
aarch64-linux-gnu-gcc: fatal error: no input files
compilation terminated.
make: *** [build/fvp/release/bl32/bl32.ld] Error 1
The reason is that the build system checks if BL32 is defined, and
if it is not, it will try to build BL32 from source. If the SPD
makefile does not provide support for that (as is the case of the
OPTEE Dispatcher, since OPTEE is provided as an external binary),
the build will fail.
This patch fixes the issue by checking if `BL32_SOURCES` has been
defined by the SPD before attempting to build BL32 from source.
If neither `BL32` nor `BL32_SOURCES` is defined when building the
FIP, a warning message will be printed and the process aborted.
Fixes ARM-software/tf-issues#333
Change-Id: I5e801ad333103ed9b042e5c4757424c8df2ff6e4
Juan Castillo
committed
on 17 Nov 2015
|
2015-11-13 |
Add missing RES1 bit in SCTLR_EL1
...
As per Section D7.2.81 in the ARMv8-A Reference Manual (DDI0487A Issue A.h),
bits[29:28], bits[23:22], bit[20] and bit[11] in the SCTLR_EL1 are RES1. This
patch adds the missing bit[20] to the SCTLR_EL1_RES1 macro.
Change-Id: I827982fa2856d04def6b22d8200a79fe6922a28e
Vikram Kanigiri
committed
on 13 Nov 2015
|
Add NULL pointer check before reading BL32 entry point information
...
BL2 is responsible for loading BL32 and passing a pointer to the
BL32 entrypoint info to BL31 in the BL31 parameters. If no BL32
image is loaded, a NULL pointer is passed. The platform is
responsible for accessing BL31 parameters and extracting the
corresponding BL32 EP info.
In ARM platforms, arm_bl31_early_platform_setup() dereferences the
pointer to the BL32 EP info without checking first if the pointer
is NULL. This will cause an exception if a BL32 entrypoint has not
been populated by BL2. FVP and Juno are not affected because they
always define BL32_BASE, irrespective of whether a BL32 image is
included in the FIP or not.
This patches fixes the issue by checking the BL32 ep_info pointer
before trying to access the data.
If `RESET_TO_BL31` is enabled, the BL32 entrypoint is not
populated if BL32_BASE is not defined.
NOTE: Maintainers of partner platforms should check for this issue
in their ports.
Fixes ARM-software/tf-issues#320
Change-Id: I31456155503f2765766e8b7cd30ab4a40958fb96
Juan Castillo
committed
on 13 Nov 2015
|
2015-11-11 |
Merge pull request #427 from jcastillo-arm/jc/tf-issues/294
...
Add -mstrict-align to the gcc options
Achin Gupta
committed
on 11 Nov 2015
|
Merge pull request #428 from vwadekar/per-soc-system-reset-v2
...
Tegra: introduce per-soc system reset handler
Achin Gupta
committed
on 11 Nov 2015
|