plat-k3: drivers: Set firewall for DTHEv2 RNG

Set firewall to protect DTHEv2 RNG from non-secure world.

Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Reviewed-by: T Pratham <t-pratham@ti.com>
Review

plat-k3: drivers: Set firewall for DTHEv2 RNG

Set firewall to protect DTHEv2 RNG from non-secure world.

Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Reviewed-by: T Pratham <t-pratham@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>

show more ...

plat-k3: drivers: Remove code to get firewall configs

The ti_crypto_init_rng_fwl() function gets firewall configurations
before setting new ones. This is pointless, since we are not using
the config

plat-k3: drivers: Remove code to get firewall configs

The ti_crypto_init_rng_fwl() function gets firewall configurations
before setting new ones. This is pointless, since we are not using
the configurations that we get anywhere. Therefore remove these blocks
of code.

Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: T Pratham <t-pratham@ti.com>

show more ...

plat-k3: drivers: Refactor SA2UL RNG firewall setup

sa2ul_init() contains code to set firewall for SA2UL RNG. However,
almost the same code can also be used to firewall DTHEv2 RNG. Therefore
refacto

plat-k3: drivers: Refactor SA2UL RNG firewall setup

sa2ul_init() contains code to set firewall for SA2UL RNG. However,
almost the same code can also be used to firewall DTHEv2 RNG. Therefore
refactor this code into a separate function in the ti_sci driver.

Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Reviewed-by: T Pratham <t-pratham@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>

show more ...

plat-k3: drivers: Add support for TI mailbox driver

New devices like the AM62L use a mailbox to communicate with the
security firmware. Add mailbox driver here to support the mailbox
hardware.

Sign

plat-k3: drivers: Add support for TI mailbox driver

New devices like the AM62L use a mailbox to communicate with the
security firmware. Add mailbox driver here to support the mailbox
hardware.

Signed-off-by: Aniket Sarkar <a-sarkar1@ti.com>
Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>

show more ...

plat-k3: drivers: Refactor sec_proxy driver

Since the underneath transport layer may or may not always be sec_proxy
it doesn't make sense to keep following the k3_sec_proxy_* convention
for the TI_S

plat-k3: drivers: Refactor sec_proxy driver

Since the underneath transport layer may or may not always be sec_proxy
it doesn't make sense to keep following the k3_sec_proxy_* convention
for the TI_SCI message transports.
Rename them to something more generic like ti_sci_transport_*.

Signed-off-by: Aniket Sarkar <a-sarkar1@ti.com>
Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>

show more ...

plat-k3: drivers: Set SEC_PROXY_MAX_MSG_SIZE to 56

Currently, SEC_PROXY_MAX_MSG_SIZE is set to 60. However, its max size
(including the secure header) is 56. Therefore correct this macro.

Signed-of

plat-k3: drivers: Set SEC_PROXY_MAX_MSG_SIZE to 56

Currently, SEC_PROXY_MAX_MSG_SIZE is set to 60. However, its max size
(including the secure header) is 56. Therefore correct this macro.

Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>

show more ...

plat-k3: drivers: Open TRNG firewall for TIFS on all k3 devs

On k3 devices, TRNG is firewalled to be accessed only by OPTEE.

TIFS needs this for the encryption and decryption services to support
di

plat-k3: drivers: Open TRNG firewall for TIFS on all k3 devs

On k3 devices, TRNG is firewalled to be accessed only by OPTEE.

TIFS needs this for the encryption and decryption services to support
different low power modes. So, open firewall to TIFS as well.

There is no concurrent usage of TRNG, as TIFS uses TRNG only at suspend
when OPTEE is down and resume, when firewalls are restored but OPTEE is
not up yet.

As this is a firewall that required to be shared along with TIFS on all
devices, making this a common change and open on all devs.

Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>

show more ...

core: console: Allow setting logging verbosity during runtime

The default console can be disabled at runtime for power management. Any
prints after boot from OP-TEE could cause a bus data abort if t

core: console: Allow setting logging verbosity during runtime

The default console can be disabled at runtime for power management. Any
prints after boot from OP-TEE could cause a bus data abort if the UART has
been disabled. Add an option to change the log level after boot has
completed which can be used to disable the console log.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

plat-k3: drivers: Add TRNG driver support in AM62L

AM62L contains the EIP76D TRNG IP which was also present in the previous
K3 devices inside the SA2UL accelerator, so the same driver is being
re-us

plat-k3: drivers: Add TRNG driver support in AM62L

AM62L contains the EIP76D TRNG IP which was also present in the previous
K3 devices inside the SA2UL accelerator, so the same driver is being
re-used here. But the AM62L does not have SA2UL. The SoC specific
configurations are being set here for AM62L for enabling TRNG.

Signed-off-by: T Pratham <t-pratham@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-k3: drivers: Move RNG platform error from SA2UL to RNG defines

The error define for RNG base address being not defined for a platform
when software PRNG is disabled, is currently handled as a c

plat-k3: drivers: Move RNG platform error from SA2UL to RNG defines

The error define for RNG base address being not defined for a platform
when software PRNG is disabled, is currently handled as a case with
SA2UL platform config definitions. This is not appropriate as RNG is not
needed to be tied up to SA2UL. Moving it to be placed with RNG platform
configs where it is more apt.

Signed-off-by: T Pratham <t-pratham@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-k3: drivers: Refactor SA2UL driver

The EIP76D TRNG IP being used in current K3 devices is not unique to
SA2UL/SA3UL. The RNG driver can be reused in other devices containing
the same TRNG IP ou

plat-k3: drivers: Refactor SA2UL driver

The EIP76D TRNG IP being used in current K3 devices is not unique to
SA2UL/SA3UL. The RNG driver can be reused in other devices containing
the same TRNG IP outside of SA2UL/SA3UL.

Refactor the SA2UL and RNG driver to make EIP76D TRNG driver independent
of SA2UL.

Signed-off-by: T Pratham <t-pratham@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-k3: drivers: ti-sci: Add support for setting KEYREV

Add support for the TI-SCI OTP message TI_SCI_MSG_WRITE_KEYREV. This
allows for incrementing the key revision counter.

Signed-off-by: Andrew

plat-k3: drivers: ti-sci: Add support for setting KEYREV

Add support for the TI-SCI OTP message TI_SCI_MSG_WRITE_KEYREV. This
allows for incrementing the key revision counter.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

plat-k3: drivers: ti-sci: Add support for setting SWREV

Add support for the TI-SCI OTP message TI_SCI_MSG_WRITE_SWREV. This
allows for incrementing the software revision counter.

Signed-off-by: And

plat-k3: drivers: ti-sci: Add support for setting SWREV

Add support for the TI-SCI OTP message TI_SCI_MSG_WRITE_SWREV. This
allows for incrementing the software revision counter.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

plat-k3: drivers: ti-sci: Fix struct name in comments for OTP functions

A couple of the documented names for the OTP functions do not match
the struct names being documented. Fix this.

Signed-off-b

plat-k3: drivers: ti-sci: Fix struct name in comments for OTP functions

A couple of the documented names for the OTP functions do not match
the struct names being documented. Fix this.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

plat-k3: drivers: add platform flavors for 62A and 62P devices

Even though the SA2UL integration on the AM62Ax and AM62Px platforms are
functionally identical to the AM62x platforms many, when build

plat-k3: drivers: add platform flavors for 62A and 62P devices

Even though the SA2UL integration on the AM62Ax and AM62Px platforms are
functionally identical to the AM62x platforms many, when building
OP-TEE manually, are using the platform name they are building for and
not 'am62x' which leaves SA2UL_BASE undefined and to failed builds:

In file included from core/include/mm/core_memprot.h:9,
from core/include/kernel/interrupt.h:10,
from core/arch/arm/plat-k3/drivers/sa2ul_rng.c:12:
core/arch/arm/plat-k3/./platform_config.h:91:34: error: ‘SA2UL_BASE’ undeclared here (not in a function); did you mean ‘SCU_BASE’?
91 | #define RNG_BASE (SA2UL_BASE + 0x10000)
| ^~~~~~~~~~

For now let's just define the AM62Ax and AM62Px platform flavors
identical to how AM62x is defined and include an #else statement to
catch when a undefined platform flavor tries to build the SA2UL driver

Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>

show more ...

plat-k3: Add initial support for AM62Lx SoC

AM62Lx newest among on the K3 class of SoCs designed to be low footprint
system where DDR can be as small as 128M. Hence, move the DDR location
to the beg

plat-k3: Add initial support for AM62Lx SoC

AM62Lx newest among on the K3 class of SoCs designed to be low footprint
system where DDR can be as small as 128M. Hence, move the DDR location
to the beginning of DDR right after TF-A.

Disable TI SCI, secure boot info and HW unique ID support for now, they
will be incrementally at later point in time as the underlying
communication layer is different than AM62x.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>

show more ...

plat-k3: drivers: Add some trace message for TI-SCI calls

These could be good for debugging tracing of TI-SCI messages

Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Manor

plat-k3: drivers: Add some trace message for TI-SCI calls

These could be good for debugging tracing of TI-SCI messages

Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

show more ...

plat-k3: drivers: Remove ti_sci_get_response function

Currently since all the code is under mutex, it makes sense to remove
this function and keep it all under ti_sci_do_xfer for easier
readability.

plat-k3: drivers: Remove ti_sci_get_response function

Currently since all the code is under mutex, it makes sense to remove
this function and keep it all under ti_sci_do_xfer for easier
readability.

Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

show more ...

plat-k3: drivers: Move message_sequence updates inside ti_sci_do_xfer

To avoid potential race condition, set the message_sequence inside
ti_sci_do_xfer itself as the send and receive paths are prote

plat-k3: drivers: Move message_sequence updates inside ti_sci_do_xfer

To avoid potential race condition, set the message_sequence inside
ti_sci_do_xfer itself as the send and receive paths are protected by a
mutex and avoid race conditions on message_sequence.

Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

show more ...

plat-k3: drivers: Add mutex lock for ti_sci_do_xfer

Current TI-SCI calls are not protected by any locks. OP-TEE running on
multiple threads can end up receiving different message response then
the o

plat-k3: drivers: Add mutex lock for ti_sci_do_xfer

Current TI-SCI calls are not protected by any locks. OP-TEE running on
multiple threads can end up receiving different message response then
the one they sent due to no queuing model.

*I/TC: Message with sequence ID <> is not expected

Add mutex lock to prevent such issues.

Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

show more ...

plat-k3: disable PRNG by default for all K3

All K3 devices already have PRNG disabled, remove the check and
set this unconditionally.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jerome Foris

plat-k3: disable PRNG by default for all K3

All K3 devices already have PRNG disabled, remove the check and
set this unconditionally.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

plat-k3: drivers: Change SA2UL_init service to service_init_crypto

Since commit 11d8578d93f0 ("core: arm: call call_driver_initcalls()
late"), driver_init is deferred and thread_update_canaries trie

plat-k3: drivers: Change SA2UL_init service to service_init_crypto

Since commit 11d8578d93f0 ("core: arm: call call_driver_initcalls()
late"), driver_init is deferred and thread_update_canaries tries to get
random_stack_canaries which requires the TRNG driver to be setup. Since
it was being setup as part of driver_init, it lead to crash on K3
platforms.

Change driver_init to service_init_crypto which is meant to be used for
initialization of crypto operations. Also, for the TISCI services to be
available before service_init_crypto, change init_ti_sci invocation to
early_init_late.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

show more ...

core: Refactor console_init() and introduce plat_console_init()

Since there are some cross-platform console drivers, we let
console_init() be common code to have a chance to initialize those
console

core: Refactor console_init() and introduce plat_console_init()

Since there are some cross-platform console drivers, we let
console_init() be common code to have a chance to initialize those
console drivers (e.g., semihosting console).

If the cross-platform console drivers are not configured to be compiled,
plat_console_init() will be invoked to initialize platform-specific
console driver.

Signed-off-by: Alvin Chang <alvinga@andestech.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

plat-k3: drivers: sec_proxy: increment while reading trail bytes

The trail bytes from the secure proxy driver were being overwritten,
increase the count each time to not overwrite the existing data

plat-k3: drivers: sec_proxy: increment while reading trail bytes

The trail bytes from the secure proxy driver were being overwritten,
increase the count each time to not overwrite the existing data and not
get the end data corrupted from secure proxy.

Fixes: cf20f0a4f77e ("plat-k3: drivers: Add secure proxy driver for communication with System Controller")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>

show more ...

plat-k3: sa2ul_rng: Use mutex instead of spinlock for critical section

While spinlock are slightly more lightweight, they currently require that
interrupts are disabled during the critical section.

plat-k3: sa2ul_rng: Use mutex instead of spinlock for critical section

While spinlock are slightly more lightweight, they currently require that
interrupts are disabled during the critical section. If this section is
long enough it can have a negative affect on realtime sensitive tasks
that require deterministic preemption.

As our RNG gathering can loop while waiting for new random numbers to
become available we cannot know how long this section will take, so we
should use a mutex. Do that here.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...