Define the Non-Secure timer frame ID for ARM platforms

On Juno and FVP platforms, the Non-Secure System timer corresponds
to frame 1. However, this is a platform-specific decision and it
shouldn't b

Define the Non-Secure timer frame ID for ARM platforms

On Juno and FVP platforms, the Non-Secure System timer corresponds
to frame 1. However, this is a platform-specific decision and it
shouldn't be hard-coded. Hence, this patch introduces
PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms
to specify the correct non-secure timer frame.

Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba

show more ...

Re-factor definition of TZC-400 base address

This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
support different TrustZone Controller base addresses across ARM platforms.

Re-factor definition of TZC-400 base address

This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
support different TrustZone Controller base addresses across ARM platforms.

Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd

show more ...

Configure all secure interrupts on ARM platforms

ARM TF configures all interrupts as non-secure except those which
are present in irq_sec_array. This patch updates the irq_sec_array
with the missing

Configure all secure interrupts on ARM platforms

ARM TF configures all interrupts as non-secure except those which
are present in irq_sec_array. This patch updates the irq_sec_array
with the missing secure interrupts for ARM platforms.

It also updates the documentation to be inline with the latest
implementation.

Fixes ARM-software/tf-issues#312

Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc

show more ...

Merge pull request #362 from jcastillo-arm/jc/inline

Fix build error with optimizations disabled (-O0)

PSCI: Validate non secure entrypoint on ARM platforms

This patch implements the platform power managment handler to verify
non secure entrypoint for ARM platforms. The handler ensures that the
entry

PSCI: Validate non secure entrypoint on ARM platforms

This patch implements the platform power managment handler to verify
non secure entrypoint for ARM platforms. The handler ensures that the
entry point specified by the normal world during CPU_SUSPEND, CPU_ON
or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
DRAM.

Change-Id: I4795452df99f67a24682b22f0e0967175c1de429

show more ...

PSCI: Use a single mailbox for warm reset for FVP and Juno

Since there is a unique warm reset entry point, the FVP and Juno
port can use a single mailbox instead of maintaining one per core.
The mai

PSCI: Use a single mailbox for warm reset for FVP and Juno

Since there is a unique warm reset entry point, the FVP and Juno
port can use a single mailbox instead of maintaining one per core.
The mailbox gets programmed only once when plat_setup_psci_ops()
is invoked during PSCI initialization. This means mailbox is not
zeroed out during wakeup.

Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432

show more ...

PSCI: Demonstrate support for composite power states

This patch adds support to the Juno and FVP ports for composite power states
with both the original and extended state-id power-state formats. Bo

PSCI: Demonstrate support for composite power states

This patch adds support to the Juno and FVP ports for composite power states
with both the original and extended state-id power-state formats. Both the
platform ports use the recommended state-id encoding as specified in
Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
ARM_RECOM_STATE_ID_ENC is used to include this support.

By default, to maintain backwards compatibility, the original power state
parameter format is used and the state-id field is expected to be zero.

Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10

show more ...

PSCI: Migrate ARM reference platforms to new platform API

This patch migrates ARM reference platforms, Juno and FVP, to the new platform
API mandated by the new PSCI power domain topology and compos

PSCI: Migrate ARM reference platforms to new platform API

This patch migrates ARM reference platforms, Juno and FVP, to the new platform
API mandated by the new PSCI power domain topology and composite power state
frameworks. The platform specific makefiles now exports the build flag
ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.

Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29

show more ...

PSCI: Add deprecated API for SPD when compatibility is disabled

This patch defines deprecated platform APIs to enable Trusted
Firmware components like Secure Payload and their dispatchers(SPD)
to co

PSCI: Add deprecated API for SPD when compatibility is disabled

This patch defines deprecated platform APIs to enable Trusted
Firmware components like Secure Payload and their dispatchers(SPD)
to continue to build and run when platform compatibility is disabled.
This decouples the migration of platform ports to the new platform API
from SPD and enables them to be migrated independently. The deprecated
platform APIs defined in this patch are : platform_get_core_pos(),
platform_get_stack() and platform_set_stack().

The patch also deprecates MPIDR based context management helpers like
cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context().
A mechanism to deprecate APIs and identify callers of these APIs during
build is introduced, which is controlled by the build flag WARN_DEPRECATED.
If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be
flagged either as a link error for assembly files or compile time warning
for C files during build.

Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613

show more ...

PSCI: Switch to the new PSCI frameworks

This commit does the switch to the new PSCI framework implementation replacing
the existing files in PSCI folder with the ones in PSCI1.0 folder. The
correspo

PSCI: Switch to the new PSCI frameworks

This commit does the switch to the new PSCI framework implementation replacing
the existing files in PSCI folder with the ones in PSCI1.0 folder. The
corresponding makefiles are modified as required for the new implementation.
The platform.h header file is also is switched to the new one
as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults
to 1 to enable compatibility layer which let the existing platform ports to
continue to build and run with minimal changes.

The default weak implementation of platform_get_core_pos() is now removed from
platform_helpers.S and is provided by the compatibility layer.

Note: The Secure Payloads and their dispatchers still use the old platform
and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build
flag will remain enabled in subsequent patch. The compatibility for SPDs using
the older APIs on platforms migrated to the new APIs will be added in the
following patch.

Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719

show more ...

PSCI: Implement platform compatibility layer

The new PSCI topology framework and PSCI extended State framework introduces
a breaking change in the platform port APIs. To ease the migration of the
pl

PSCI: Implement platform compatibility layer

The new PSCI topology framework and PSCI extended State framework introduces
a breaking change in the platform port APIs. To ease the migration of the
platform ports to the new porting interface, a compatibility layer is
introduced which essentially defines the new platform API in terms of the
old API. The old PSCI helpers to retrieve the power-state, its associated
fields and the highest coordinated physical OFF affinity level of a core
are also implemented for compatibility. This allows the existing
platform ports to work with the new PSCI framework without significant
rework. This layer will be enabled by default once the switch to the new
PSCI framework is done and is controlled by the build flag ENABLE_PLAT_COMPAT.

Change-Id: I4b17cac3a4f3375910a36dba6b03d8f1700d07e3

show more ...

PSCI: Unify warm reset entry points

There used to be 2 warm reset entry points:

- the "on finisher", for when the core has been turned on using a
PSCI CPU_ON call;

- the "suspend finisher", e

PSCI: Unify warm reset entry points

There used to be 2 warm reset entry points:

- the "on finisher", for when the core has been turned on using a
PSCI CPU_ON call;

- the "suspend finisher", entered upon resumption from a previous
PSCI CPU_SUSPEND call.

The appropriate warm reset entry point used to be programmed into the
mailboxes by the power management hooks.

However, it is not required to provide this information to the PSCI
entry point code, as it can figure it out by itself. By querying affinity
info state, a core is able to determine on which execution path it is.
If the state is ON_PENDING then it means it's been turned on else
it is resuming from suspend.

This patch unifies the 2 warm reset entry points into a single one:
psci_entrypoint(). The patch also implements the necessary logic
to distinguish between the 2 types of warm resets in the power up
finisher.

The plat_setup_psci_ops() API now takes the
secure entry point as an additional parameter to enable the platforms
to configure their mailbox. The platform hooks `pwr_domain_on`
and `pwr_domain_suspend` no longer take secure entry point as
a parameter.

Change-Id: I7d1c93787b54213aefdbc046b8cd66a555dfbfd9

show more ...

PSCI: Add framework to handle composite power states

The state-id field in the power-state parameter of a CPU_SUSPEND call can be
used to describe composite power states specific to a platform. The

PSCI: Add framework to handle composite power states

The state-id field in the power-state parameter of a CPU_SUSPEND call can be
used to describe composite power states specific to a platform. The current PSCI
implementation does not interpret the state-id field. It relies on the target
power level and the state type fields in the power-state parameter to perform
state coordination and power management operations. The framework introduced
in this patch allows the PSCI implementation to intepret generic global states
like RUN, RETENTION or OFF from the State-ID to make global state coordination
decisions and reduce the complexity of platform ports. It adds support to
involve the platform in state coordination which facilitates the use of
composite power states and improves the support for entering standby states
at multiple power domains.

The patch also includes support for extended state-id format for the power
state parameter as specified by PSCIv1.0.

The PSCI implementation now defines a generic representation of the power-state
parameter. It depends on the platform port to convert the power-state parameter
(possibly encoding a composite power state) passed in a CPU_SUSPEND call to this
representation via the `validate_power_state()` plat_psci_ops handler. It is an
array where each index corresponds to a power level. Each entry contains the
local power state the power domain at that power level could enter.

The meaning of the local power state values is platform defined, and may vary
between levels in a single platform. The PSCI implementation constrains the
values only so that it can classify the state as RUN, RETENTION or OFF as
required by the specification:
* zero means RUN
* all OFF state values at all levels must be higher than all RETENTION
state values at all levels
* the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values
to the framework

The platform also must define the macros PLAT_MAX_RET_STATE and
PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power
domains have been requested to enter a retention or power down state. The PSCI
implementation does not interpret the local power states defined by the
platform. The only constraint is that the PLAT_MAX_RET_STATE <
PLAT_MAX_OFF_STATE.

For a power domain tree, the generic implementation maintains an array of local
power states. These are the states requested for each power domain by all the
cores contained within the domain. During a request to place multiple power
domains in a low power state, the platform is passed an array of requested
power-states for each power domain through the plat_get_target_pwr_state()
API. It coordinates amongst these states to determine a target local power
state for the power domain. A default weak implementation of this API is
provided in the platform layer which returns the minimum of the requested
power-states back to the PSCI state coordination.

Finally, the plat_psci_ops power management handlers are passed the target
local power states for each affected power domain using the generic
representation described above. The platform executes operations specific to
these target states.

The platform power management handler for placing a power domain in a standby
state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for
placing a core power domain into a standby or retention state should now be
used to only place the core power domain in a standby or retention state.

The extended state-id power state format can be enabled by setting the
build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default.

Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c

show more ...

PSCI: Introduce new platform interface to describe topology

This patch removes the assumption in the current PSCI implementation that MPIDR
based affinity levels map directly to levels in a power do

PSCI: Introduce new platform interface to describe topology

This patch removes the assumption in the current PSCI implementation that MPIDR
based affinity levels map directly to levels in a power domain tree. This
enables PSCI generic code to support complex power domain topologies as
envisaged by PSCIv1.0 specification. The platform interface for querying
the power domain topology has been changed such that:

1. The generic PSCI code does not generate MPIDRs and use them to query the
platform about the number of power domains at a particular power level. The
platform now provides a description of the power domain tree on the SoC
through a data structure. The existing platform APIs to provide the same
information have been removed.

2. The linear indices returned by plat_core_pos_by_mpidr() and
plat_my_core_pos() are used to retrieve core power domain nodes from the
power domain tree. Power domains above the core level are accessed using a
'parent' field in the tree node descriptors.

The platform describes the power domain tree in an array of 'unsigned
char's. The first entry in the array specifies the number of power domains at
the highest power level implemented in the system. Each susbsequent entry
corresponds to a power domain and contains the number of power domains that are
its direct children. This array is exported to the generic PSCI implementation
via the new `plat_get_power_domain_tree_desc()` platform API.

The PSCI generic code uses this array to populate its internal power domain tree
using the Breadth First Search like algorithm. The tree is split into two
arrays:

1. An array that contains all the core power domain nodes

2. An array that contains all the other power domain nodes

A separate array for core nodes allows certain core specific optimisations to
be implemented e.g. remove the bakery lock, re-use per-cpu data framework for
storing some information.

Entries in the core power domain array are allocated such that the
array index of the domain is equal to the linear index returned by
plat_core_pos_by_mpidr() and plat_my_core_pos() for the MPIDR
corresponding to that domain. This relationship is key to be able to use
an MPIDR to find the corresponding core power domain node, traverse to higher
power domain nodes and index into arrays that contain core specific
information.

An introductory document has been added to briefly describe the new interface.

Change-Id: I4b444719e8e927ba391cae48a23558308447da13

show more ...

PSCI: Introduce new platform and CM helper APIs

This patch introduces new platform APIs and context management helper APIs
to support the new topology framework based on linear core position. This
f

PSCI: Introduce new platform and CM helper APIs

This patch introduces new platform APIs and context management helper APIs
to support the new topology framework based on linear core position. This
framework will be introduced in the follwoing patch and it removes the
assumption that the MPIDR based affinity levels map directly to levels
in a power domain tree. The new platforms APIs and context management
helpers based on core position are as described below:

* plat_my_core_pos() and plat_core_pos_by_mpidr()

These 2 new mandatory platform APIs are meant to replace the existing
'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the
linear index of the calling core and 'plat_core_pos_by_mpidr()' returns
the linear index of a core specified by its MPIDR. The latter API will also
validate the MPIDR passed as an argument and will return an error code (-1)
if an invalid MPIDR is passed as the argument. This enables the caller to
safely convert an MPIDR of another core to its linear index without querying
the PSCI topology tree e.g. during a call to PSCI CPU_ON.

Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always
platform specific, it is no longer possible to maintain a default implementation
of this API. Also it might not be possible for a platform port to verify an
MPIDR before the C runtime has been setup or the topology has been initialized.
This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to
topology setup. As a result, the generic Trusted Firmware code does not call
this API before the topology setup has been done.

The 'plat_my_core_pos' API should be able to run without a C runtime.
Since this API needs to return a core position which is equal to the one
returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR,
this too cannot have default implementation and is a mandatory API for
platform ports. These APIs will be implemented by the ARM reference platform
ports later in the patch stack.

* plat_get_my_stack() and plat_set_my_stack()

These APIs are the stack management APIs which set/return stack addresses
appropriate for the calling core. These replace the 'platform_get_stack()' and
'platform_set_stack()' APIs. A default weak MP version and a global UP version
of these APIs are provided for the platforms.

* Context management helpers based on linear core position

A set of new context management(CM) helpers viz cm_get_context_by_index(),
cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index()
are defined which are meant to replace the old helpers which took MPIDR
as argument. The old CM helpers are implemented based on the new helpers to
allow for code consolidation and will be deprecated once the switch to the new
framework is done.

Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69

show more ...

PSCI: Remove references to affinity based power management

As per Section 4.2.2. in the PSCI specification, the term "affinity"
is used in the context of describing the hierarchical arrangement
of c

PSCI: Remove references to affinity based power management

As per Section 4.2.2. in the PSCI specification, the term "affinity"
is used in the context of describing the hierarchical arrangement
of cores. This often, but not always, maps directly to the processor
power domain topology of the system. The current PSCI implementation
assumes that this is always the case i.e. MPIDR based levels of
affinity always map to levels in a power domain topology tree.

This patch is the first in a series of patches which remove this
assumption. It removes all occurences of the terms "affinity
instances and levels" when used to describe the power domain
topology. Only the terminology is changed in this patch. Subsequent
patches will implement functional changes to remove the above
mentioned assumption.

Change-Id: Iee162f051b228828310610c5a320ff9d31009b4e

show more ...

PSCI: Create new directory to implement new frameworks

This patch creates a copy of the existing PSCI files and related psci.h and
platform.h header files in a new `PSCI1.0` directory. The changes f

PSCI: Create new directory to implement new frameworks

This patch creates a copy of the existing PSCI files and related psci.h and
platform.h header files in a new `PSCI1.0` directory. The changes for the
new PSCI power domain topology and extended state-ID frameworks will be
added incrementally to these files. This incremental approach will
aid in review and in understanding the changes better. Once all the
changes have been introduced, these files will replace the existing PSCI
files.

Change-Id: Ibb8a52e265daa4204e34829ed050bddd7e3316ff

show more ...

Fix build error with optimizations disabled (-O0)

If Trusted Firmware is built with optimizations disabled (-O0), the
linker throws the following error:

undefined reference to 'xxx'

Where 'xxx

Fix build error with optimizations disabled (-O0)

If Trusted Firmware is built with optimizations disabled (-O0), the
linker throws the following error:

undefined reference to 'xxx'

Where 'xxx' is a raw inline function defined in a header file. The
reason is that, with optimizations disabled, GCC may decide to skip
the inlining. If that is the case, an external definition to the
compilation unit must be provided. Because no external definition
is present, the linker throws the error.

This patch fixes the problem by declaring the following inline
functions static, so the internal definition is used:

inline void soc_css_security_setup(void)
inline const arm_config_t *get_arm_config(void)

Change-Id: Id650d6be1b1396bdb48af1ac8a4c7900d212e95f

show more ...

Use uintptr_t as base address type in ARM driver APIs

This patch changes the type of the base address parameter in the
ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The
uintptr_t ty

Use uintptr_t as base address type in ARM driver APIs

This patch changes the type of the base address parameter in the
ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The
uintptr_t type allows coverage of the whole memory space and to
perform arithmetic operations on the addresses. ARM platform code
has also been updated to use uintptr_t as GIC base address in the
configuration.

Fixes ARM-software/tf-issues#214

Change-Id: I1b87daedadcc8b63e8f113477979675e07d788f1

show more ...

TBB: delete deprecated plat_match_rotpk()

The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.

TBB: delete deprecated plat_match_rotpk()

The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.

Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b

show more ...

TBB: switch to the new authentication framework

This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto

TBB: switch to the new authentication framework

This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto module and the image parser module to
authenticate the images in the Chain of Trust.

A new function 'load_auth_image()' has been implemented. When TBB
is enabled, this function will call the authentication module to
authenticate parent images following the CoT up to the root of
trust to finally load and authenticate the requested image.

The platform is responsible for picking up the right makefiles to
build the corresponding cryptographic and image parser libraries.
ARM platforms use the mbedTLS based libraries.

The platform may also specify what key algorithm should be used
to sign the certificates. This is done by declaring the 'KEY_ALG'
variable in the platform makefile. FVP and Juno use ECDSA keys.

On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
each to accommodate the ECDSA code.

REMOVED BUILD OPTIONS:

* 'AUTH_MOD'

Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867

show more ...

TBB: add TBBR Chain of Trust

This patch adds a CoT based on the Trusted Board Boot Requirements
document*. The CoT consists of an array of authentication image
descriptors indexed by the image ident

TBB: add TBBR Chain of Trust

This patch adds a CoT based on the Trusted Board Boot Requirements
document*. The CoT consists of an array of authentication image
descriptors indexed by the image identifiers.

A new header file with TBBR image identifiers has been added.
Platforms that use the TBBR (i.e. ARM platforms) may reuse these
definitions as part of their platform porting.

PLATFORM PORT - IMPORTANT:

Default image IDs have been removed from the platform common
definitions file (common_def.h). As a consequence, platforms that
used those common definitons must now either include the IDs
provided by the TBBR header file or define their own IDs.

*The NVCounter authentication method has not been implemented yet.

Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5

show more ...

TBB: add platform API to read the ROTPK information

This patch extends the platform port by adding an API that returns
either the Root of Trust public key (ROTPK) or its hash. This is
usually stored

TBB: add platform API to read the ROTPK information

This patch extends the platform port by adding an API that returns
either the Root of Trust public key (ROTPK) or its hash. This is
usually stored in ROM or eFUSE memory. The ROTPK returned must be
encoded in DER format according to the following ASN.1 structure:

SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}

In case the platform returns a hash of the key:

DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
keyDigest OCTET STRING
}

An implementation for ARM development platforms is provided in this
patch. When TBB is enabled, the ROTPK hash location must be specified
using the build option 'ARM_ROTPK_LOCATION'. Available options are:

- 'regs' : return the ROTPK hash stored in the Trusted
root-key storage registers.

- 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
BL2 binaries. This hash has been obtained from the development
RSA public key located in 'plat/arm/board/common/rotpk'.

On FVP, the number of MMU tables has been increased to map and
access the ROTPK registers.

A new file 'board_common.mk' has been added to improve code sharing
in the ARM develelopment platforms.

Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf

show more ...

Use numbers to identify images instead of names

The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in t

Use numbers to identify images instead of names

The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in the platform function plat_get_image_source(). For
a given image name, it returns the handle to the image file which
involves comparing images names. In addition, if the image is
packaged in a FIP, a name comparison is required to find the UUID
for the image. This method is not optimal.

This patch changes the interface between the generic and platform
code with regard to identifying images. The platform port must now
allocate a unique number (ID) for every image. The generic code will
use the image ID instead of the name to access its attributes.

As a result, the plat_get_image_source() function now takes an image
ID as an input parameter. The organisation of data structures within
the IO framework has been rationalised to use an image ID as an index
into an array which contains attributes of the image such as UUID and
name. This prevents the name comparisons.

A new type 'io_uuid_spec_t' has been introduced in the IO framework
to specify images identified by UUID (i.e. when the image is contained
in a FIP file). There is no longer need to maintain a look-up table
[iname_name --> uuid] in the io_fip driver code.

Because image names are no longer mandatory in the platform port, the
debug messages in the generic code will show the image identifier
instead of the file name. The platforms that support semihosting to
load images (i.e. FVP) must provide the file names as definitions
private to the platform.

The ARM platform ports and documentation have been updated accordingly.
All ARM platforms reuse the image IDs defined in the platform common
code. These IDs will be used to access other attributes of an image in
subsequent patches.

IMPORTANT: applying this patch breaks compatibility for platforms that
use TF BL1 or BL2 images or the image loading code. The platform port
must be updated to match the new interface.

Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5

show more ...

Merge pull request #320 from danh-arm/rh/timer-api-v10

Add delay timer API v10