This patch implements support for adding dynamic configurations for
BL31 (soc_fw_config), BL32 (tos_fw_config) and BL33 (nt_fw_config). The
necessary cert tool support and changes to default chain of trust are made
for these configs.
Change-Id: I25f266277b5b5501a196d2f2f79639d838794518
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
In 'console_set_scope' and when registering a console, field 'flags' of
'console_t' is assigned a 32-bit value. However, when it is actually
used, the functions perform 64-bit reads to access its value. This patch
changes all 64-bit reads to 32-bit reads.
Change-Id: I181349371409e60065335f078857946fa3c32dc1
Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
In the multi console driver, allowing to register the same console more
than once may result in an infinte loop when putc is called.
If, for example, a boot message is trying to be printed, but the
consoles in the loop in the linked list are runtime consoles, putc will
iterate forever looking for a console that can print boot messages (or
a NULL pointer that will never come).
This loop in the linked list can occur after restoring the system from a
system suspend. The boot console is registered during the cold boot in
BL31, but the runtime console is registered even in the warm boot path.
Consoles are always added to the start of the linked list when they are
registered, so this it what should happen if they were actually
different structures:
console_list -> NULL
console_list -> BOOT -> NULL
console_list -> RUNTIME -> BOOT -> NULL
console_list -> RUNTIME -> RUNTIME -> BOOT -> NULL
In practice, the two runtime consoles are the same one, so they create
this loop:
console_list -> RUNTIME -. X -> BOOT -> NULL
^ |
`----'
This patch adds an assertion to detect this problem. The assertion will
fail whenever the same structure tries to be registered while being on
the list.
In order to assert this, console_is_registered() has been implemented.
It returns 1 if the specified console is registered, 0 if not.
Change-Id: I922485e743775ca9bd1af9cbd491ddd360526a6d
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Commit 4c0d039076 ("Rework type usage in Trusted Firmware") changed
the type usage in struct declarations, but did not touch the definition
side. Fix the type mismatch.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Rule 8.4: A compatible declaration shall be visible when
an object or function with external linkage is defined
Fixed for:
make DEBUG=1 PLAT=fvp SPD=tspd TRUSTED_BOARD_BOOT=1 \
GENERATE_COT=1 ARM_ROTPK_LOCATION=devel_rsa \
ROT_KEY=arm_rotprivk_rsa.pem MBEDTLS_DIR=mbedtls all
Change-Id: Ie4cd6011b3e4fdcdd94ccb97a7e941f3b5b7aeb8
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Rule 8.3: All declarations of an object or function shall
use the same names and type qualifiers
Fixed for:
make DEBUG=1 PLAT=fvp SPD=tspd TRUSTED_BOARD_BOOT=1 \
GENERATE_COT=1 ARM_ROTPK_LOCATION=devel_rsa \
ROT_KEY=arm_rotprivk_rsa.pem MBEDTLS_DIR=mbedtls all
Change-Id: Ia34fe1ae1f142e89c9a6c19831e3daf4d28f5831
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Some low end platforms using DMC500 memory controller do not have
CCI(Cache Coherent Interconnect) interface and only have non-coherent
system interface support. Hence this patch makes the system interface
count configurable from the platforms.
Change-Id: I6d54c90eb72fd18026c6470c1f7fd26c59dc4b9a
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Accessing the interrupt_props array only happens inside a loop over
interrupt_props_num, so the GICv3 driver can cope with no secure
interrupts. This allows us to relax the asserts that insists on
a non-NULL interrupt_props pointer and at least one secure interrupt.
This enables GICv3 platforms which have no need for a secure interrupt.
This only covers the non-deprecated code paths.
Change-Id: I49db291906512f56af065772f69acb281dfbdcfb
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Accessing the interrupt_props array only happens inside a loop over
interrupt_props_num, so the GICv2 driver can cope with no secure
interrupts. As in fact we have already some asserts in place that
respect that, lets change the final place where we insist on a non-NULL
pointer to relax that.
This enables GICv2 platforms which have no need for a secure interrupt.
This only covers the non-deprecated code paths.
Also we remove a now redundant assert().
Change-Id: Id100ea978643d8558335ad28649d55743fe9bd4c
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Void pointers have been used to access linker symbols, by declaring an
extern pointer, then taking the address of it. This limits symbols
values to aligned pointer values. To remove this restriction an
IMPORT_SYM macro has been introduced, which declares it as a char
pointer and casts it to the required type.
Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
- Interrupt configuration is a 2-bit field, so the field shift has to
be double that of the bit number.
- Interrupt configuration (level- or edge-trigger) is specified in the
MSB of the field, not LSB.
Fixes applied to both GICv2 and GICv3 drivers.
FixesARM-software/tf-issues#570
Change-Id: Ia6ae6ed9ba9fb0e3eb0f921a833af48e365ba359
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Replace placeholder by actual implementation.
Change-Id: I0861b1ac5304b0d2d7c32d7d9a48bd985e258e92
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Include missing plat_helpers.S into pl011_console.S, to build successfully
when MULTI_CONSOLE_API is enabled.
Signed-off-by: Michalis Pappas <mpappas@fastmail.fm>
Emit runtime warnings when intializing the GIC drivers using the
deprecated method of defining integer interrupt arrays in the GIC driver
data structures; interrupt_prop_t arrays should be used instead. This
helps platforms detect that they have migration work to do. Previously,
no warning was emitted in this case. This affects both the GICv2 and GICv3
drivers.
Also use the __deprecated attribute to emit a build time warning if these
deprecated fields are used. These warnings are suppressed in the GIC
driver compatibility functions but will be visible if platforms use them.
Change-Id: I6b6b8f6c3b4920c448b6dcb82fc18442cfdf6c7a
Signed-off-by: Dan Handley <dan.handley@arm.com>
For platforms that have not migrated to MULTI_CONSOLE_API == 1, there
are a lot of confusing deprecated declaration warnings relating to
use of console_init() and console_uninit(). Some of these relate to use
by the generic code, not the platform code. These functions are not really
deprecated but *removed* when MULTI_CONSOLE_API == 1.
This patch consolidates these warnings into a single preprocessor warning.
The __deprecated attribute is removed from the console_init() and
console_uninit() declarations.
For preprocessor warnings like this to not cause fatal build errors,
this patch adds -Wno-error=cpp to the build flags when
ERROR_DEPRECATED == 0.
This option (and -Wno-error=deprecated-declarations) is now added to
CPPFLAGS instead of TF_CFLAGS to ensure the build flags are used in the
assembler as well as the compiler.
This patch also disentangles the MULTI_CONSOLE_API and ERROR_DEPRECATED
build flags by defaulting MULTI_CONSOLE_API to 0 instead of
ERROR_DEPRECATED. This allows platforms that have not migrated to
MULTI_CONSOLE_API to use ERROR_DEPRECATED == 1 to emit a more meaningful
build error.
Finally, this patch bans use of MULTI_CONSOLE_API == 1 and AARCH32, since
the AArch32 console implementation does not support
MULTI_CONSOLE_API == 1.
Change-Id: If762165ddcb90c28aa7a4951aba70cb15c2b709c
Signed-off-by: Dan Handley <dan.handley@arm.com>
Rule 8.4: A compatible declaration shall be visible when
an object or function with external linkage is defined
Fixed for:
make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all
Change-Id: I7c2ad3f5c015411c202605851240d5347e4cc8c7
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Rule 8.4: A compatible declaration shall be visible when
an object or function with external linkage is defined.
Change-Id: I26e042cb251a6f9590afa1340fdac73e42f23979
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Rule 8.3: All declarations of an object or function shall
use the same names and type qualifiers.
Change-Id: Iff384187c74a598a4e73f350a1893b60e9d16cec
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
This patch adds image IDs to `hw_config` and `tb_fw_config` and
includes them in the default Chain Of Trust (CoT).
Change-Id: If7bb3e9be8a5e48be76614b35bf43d58fc7fed12
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Hynix ufs has deviations on hi36xx platform which will result
in ufs bursts transfer failures at a very low probability.
To fix the problem, the Hynix device must set the register
VS_DebugSaveConfigTime to 0x10, which will set time reference
for SaveConfigTime is 250 ns. The time reference for SaveConfigTime
is 40 ns by default.
Signed-off-by: fengbaopeng <fengbaopeng@hisilicon.com>
Previously the definition of `_tzc_read_peripheral_id()` was wrapped
in ENABLE_ASSERTIONS build flag. This causes build issue for TZC400 driver
when DEBUG=1 and ENABLE_ASSERTIONS=0. This patch fixes the same by
moving the definitions outside the ENABLE_ASSERTIONS build flag.
Change-Id: Ic1cad69f02ce65ac34aefd39eaa96d5781043152
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
This fixes all defects according to MISRA Rule 3.1: "The character
sequences /* and // shall not be used within a comment". This affects
all URLs in comments, so they have been removed:
- The link in `sdei_state.c` can also be found in the documentation file
`docs/sdei.rst`.
- The bug that the file `io_fip.c` talks about doesn't affect the
currently supported version of GCC, so it doesn't make sense to keep
the comment. Note that the version of GCC officially supported is the
one that comes with Linaro Release 17.10, which is GCC 6.2.
- The link in `tzc400.c` was broken, and it didn't correctly direct to
the Technical Reference Manual it should. The link has been replaced
by the title of the document, which is more convenient when looking
for the document.
Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Delay functions like udelay() are often used to ensure that the
necessary time passed to allow some asynchronous event to finish, such
as the stabilization delay for a power rail. For these use cases it is
not very problematic if the delay is slightly longer than requested,
but it is critical that the delay must never be shorter.
The current udelay() implementation contains two hazards that may cause
the delay to be slightly shorter than intended: Firstly, the amount of
ticks to wait is calculated with an integer division, which may cut off
the last fraction of ticks needed. Secondly, the delay may be short by a
fraction of a tick because we do not know whether the initial ("start")
sample of the timer was near the start or near the end of the current
tick. Thus, if the code intends to wait for one tick, it might read the
timer value close to the end of the current tick and then read it again
right after the start of the next tick, concluding that the duration of
a full tick has passed when it in fact was just a fraction of it.
This patch rounds up the division and always adds one extra tick to
counteract both problems and ensure that delays will always be larger
but never smaller than requested.
Change-Id: Ic5fe5f858b5cdf3c0dbf3e488d4d5702d9569433
Signed-off-by: Julius Werner <jwerner@chromium.org>
If the GIC loses power during suspend, which the restore code was
written for, exit early in the post restore power sequence. This
prevents an assert from tripping, and the power sequence isn't needed
in this case anyways.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
coreboot supports an in-memory console to store firmware logs even when
no serial console is available. It is widely supported by
coreboot-compatible bootloaders (including SeaBIOS and GRUB) and can be
read by the Linux kernel.
This patch allows BL31 to add its own log messages to this console. The
driver will be registered automatically if coreboot support is compiled
in and detects the presence of a console buffer in the coreboot tables.
Change-Id: I31254dfa0c2fdeb7454634134b5707b4b4154907
Signed-off-by: Julius Werner <jwerner@chromium.org>
This patch updates the Cadence CDNS console driver to support the new
console API. The driver will continue to support the old API as well by
checking the MULTI_CONSOLE_API compile-time flag.
Change-Id: I2ef8fb0d6ab72696997db1e0243a533499569d6b
Signed-off-by: Julius Werner <jwerner@chromium.org>
This patch updates the ARM PL011 console driver to support the new
console API. The driver will continue to support the old API as well by
checking the MULTI_CONSOLE_API compile-time flag.
Change-Id: Ic34e4158addbb0c5fae500c9cff899c05a4f4206
Signed-off-by: Julius Werner <jwerner@chromium.org>
This patch updates the TI 16550 console driver to support the new
console API. The driver will continue to support the old API as well by
checking the MULTI_CONSOLE_API compile-time flag.
Change-Id: I60a44b7ba3c35c74561824c04b8dbe3e3039324c
Signed-off-by: Julius Werner <jwerner@chromium.org>
This patch modifies the makefiles to avoid the definition
of BL1_SOURCES and BL2_SOURCES in the tbbr makefiles, and
it lets to the platform makefiles to define them if they
actually need these images. In the case of BL2_AT_EL3
BL1 will not be needed usually because the Boot ROM will
jump directly to BL2.
Change-Id: Ib6845a260633a22a646088629bcd7387fe35dcf9
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
Add some macros according to JEDEC Standard Embedded Multi-Media
Card (eMMC) Electrical Standard (5.1)": Table 145 - Bus Mode
Selection.
Change-Id: Iaa45e0582653ef4290efd60d039f0bdc420eeb47
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
The block operations were trying to optimize the number of memory
copies, and it tried to use directly the buffer supplied by the user
to them. This was a mistake because it created too many corner cases:
1- It was possible to generate unaligned
operations to unaligned buffers. Drivers that were using
DMA transfer failed in that case.
2- It was possible to generate read operations
with sizes that weren't a multiple of the block size. Some
low level drivers assumed that condition and they calculated
the number of blocks dividing the number of bytes by the
size of the block, without considering the remaining bytes.
3- The block_* operations didn't control the
number of bytes actually copied to memory, because the
low level drivers were writing directly to the user buffer.
This patch rewrite block_read and block_write to use always the device
buffer, which the platform ensures that has the correct aligment and
the correct size.
Change-Id: I5e479bb7bc137e6ec205a8573eb250acd5f40420
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
This patch overhauls the console API to allow for multiple console
instances of different drivers that are active at the same time. Instead
of binding to well-known function names (like console_core_init),
consoles now provide a register function (e.g. console_16550_register())
that will hook them into the list of active consoles. All console
operations will be dispatched to all consoles currently in the list.
The new API will be selected by the build-time option MULTI_CONSOLE_API,
which defaults to ${ERROR_DEPRECATED} for now. The old console API code
will be retained to stay backwards-compatible to older platforms, but
should no longer be used for any newly added platforms and can hopefully
be removed at some point in the future.
The new console API is intended to be used for both normal (bootup) and
crash use cases, freeing platforms of the need to set up the crash
console separately. Consoles can be individually configured to be active
active at boot (until first handoff to EL2), at runtime (after first
handoff to EL2), and/or after a crash. Console drivers should set a sane
default upon registration that can be overridden with the
console_set_scope() call. Code to hook up the crash reporting mechanism
to this framework will be added with a later patch.
This patch only affects AArch64, but the new API could easily be ported
to AArch32 as well if desired.
Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
Signed-off-by: Julius Werner <jwerner@chromium.org>
The flag support the following values:
- sha256 (default)
- sha384
- sha512
Change-Id: I7a49d858c361e993949cf6ada0a86575c3291066
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
At present, the GIC drivers enable Group 0 interrupts only if there are
Secure SPIs listed in the interrupt properties/list. This means that,
even if there are Group 0 SGIs/PPIs configured, the group remained
disabled in the absence of a Group 0 SPI.
Modify both GICv2 and GICv3 SGI/PPI configuration to enable Group 0 when
corresponding SGIs/PPIs are present.
Change-Id: Id123e8aaee0c22b476eebe3800340906d83bbc6d
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This patch brings in the following fixes:
- The per-PE target data initialized during power up needs to be
flushed so as to be visible to other PEs.
- Setup per-PE target data for the primary PE as well. At present,
this was only setup for secondary PEs when they were powered on.
Change-Id: Ibe3a57c14864e37b2326dd7ab321a5c7bf80e8af
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Some SoCs integrate a GIC in version 1 that is currently not supported
by the trusted firmware. This change hijacks GICv2 driver to handle the
GICv1 as GICv1 is compatible enough with GICv2 as far as the platform
does not attempt to play with virtualization support or some GICv2
specific power features.
Note that current trusted firmware does not use these GICv2 features
that are not available in GICv1 Security Extension.
Change-Id: Ic2cb3055f1319a83455571d6d918661da583f179
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
The GIC driver initialization currently allows an array of interrupts to
be configured as secure. Future use cases would require more interrupt
configuration other than just security, such as priority.
This patch introduces a new interrupt property array as part of both
GICv2 and GICv3 driver data. The platform can populate the array with
interrupt numbers and respective properties. The corresponding driver
initialization iterates through the array, and applies interrupt
configuration as required.
This capability, and the current way of supplying array (or arrays, in
case of GICv3) of secure interrupts, are however mutually exclusive.
Henceforth, the platform should supply either:
- A list of interrupts to be mapped as secure (the current way).
Platforms that do this will continue working as they were. With this
patch, this scheme is deprecated.
- A list of interrupt properties (properties include interrupt group).
Individual interrupt properties are specified via. descriptors of
type 'interrupt_prop_desc_t', which can be populated with the macro
INTR_PROP_DESC().
A run time assert checks that the platform doesn't specify both.
Henceforth the old scheme of providing list of secure interrupts is
deprecated. When built with ERROR_DEPRECATED=1, GIC drivers will require
that the interrupt properties are supplied instead of an array of secure
interrupts.
Add a section to firmware design about configuring secure interrupts.
FixesARM-software/tf-issues#262
Change-Id: I8eec29e72eb69dbb6bce77879febf32c95376942
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
The helpers perform read-modify-write on GIC*_ICFGR registers, but don't
serialise callers. Any serialisation must be taken care of by the
callers.
Change-Id: I71995f82ff2c7f70d37af0ede30d6ee18682fd3f
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
SPIs can be routed to either a specific PE, or to any one of all
available PEs.
API documentation updated.
Change-Id: I28675f634568aaf4ea1aa8aa7ebf25b419a963ed
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
The back end GIC driver converts and assigns the interrupt type to
suitable group.
For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, which
determines to which type Group 0 interrupts maps to.
- When the build option is set 0 (the default), Group 0 interrupts are
meant for Secure EL1. This is presently the case.
- Otherwise, Group 0 interrupts are meant for EL3. This means the SPD
will have to synchronously hand over the interrupt to Secure EL1.
The query API allows the platform to query whether the platform supports
interrupts of a given type.
API documentation updated.
Change-Id: I60fdb4053ffe0bd006b3b20914914ebd311fc858
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
The PE target mask is used to translate linear PE index (returned by
platform core position) to a bit mask used when targeting interrupts to
a PE, viz. when raising SGIs and routing SPIs.
The platform shall:
- Populate the driver data with a pointer to array that's to contain
per-PE target masks.
- Invoke the new driver API 'gicv2_set_pe_target_mask()' during
per-CPU initialization so that the driver populates the target mask
for that CPU.
Platforms that don't intend to target interrupts or raise SGIs need not
populate this.
Change-Id: Ic0db54da86915e9dccd82fff51479bc3c1fdc968
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Document the API in separate platform interrupt controller API document.
Change-Id: If18f208e10a8a243f5c59d226fcf48e985941949
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>