Merge "docs: add playbook for new releases" into integration

feat(ti): introduce basic support for the AM62L

The AM62L is a lite, low power and performance optimized family of
application processors that are built for Linux application development.

Some high

feat(ti): introduce basic support for the AM62L

The AM62L is a lite, low power and performance optimized family of
application processors that are built for Linux application development.

Some highlights of AM62L SoC are:
- Single to Dual 64-bit Arm® Cortex®-A53 microprocessor subsystem
- 16-bit DDR Subsystem that supports LPDDR4, DDR4 memory types.
- Multiple low power modes support, ex: Deep sleep and RTC+DDR
- Mailbox transport layer for TI SCI

For more information check out our Technical Reference Manual (TRM)
which is loacted here:

https://www.ti.com/lit/pdf/sprujb4

Change-Id: I9d7c707b5b220c5ec13bd2de67f872b3da3c308a
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

feat(ti): introduce PSCI Driver for AM62L

The AM62L is a lite, low power and performance optimized family of
application processors that are built for Linux application development

There is enough

feat(ti): introduce PSCI Driver for AM62L

The AM62L is a lite, low power and performance optimized family of
application processors that are built for Linux application development

There is enough deviation from the previous K3 gen SoCs with regards to
how the PSCI functionality looks like on this device. For example, it
no longer does reset or LPSC turn ON/OFF operations using any external
Device Management entity like it did earlier.

The actual power ON/OFF operations will be implemented in a later stage
once all the PM related drivers are integrated. Such places in this
driver have been marked as TODO and will be replaced with actual call
to power on/off the cores at a later point.

This warranted the addition of a new am62l_psci driver for the AM62L
family of devices. For further details of how this new device looks
like, refer to the TRM [1].

[1] https://www.ti.com/lit/pdf/sprujb4

Change-Id: Ic53096e7bbc25fa55386ac4b6bef364dd6d0cf3b
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

feat(ti): add support for TI mailbox driver

New devices like the AM62L will use a mailbox to communicate with the
security firmware.

Change-Id: I33080d443d73d4aff685ada5b40c067a3ff6a137
Signed-off-

feat(ti): add support for TI mailbox driver

New devices like the AM62L will use a mailbox to communicate with the
security firmware.

Change-Id: I33080d443d73d4aff685ada5b40c067a3ff6a137
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): move out k3/common to ti/common

This will allow us to support more platforms that share commonalities
like the k3_gicv3, console, helpers, etc.
With this new common folder location, we

refactor(ti): move out k3/common to ti/common

This will allow us to support more platforms that share commonalities
like the k3_gicv3, console, helpers, etc.
With this new common folder location, we can move the previously
created ti_bl31_setup file into the new location so it can be shared
across multiple TI SoCs when need comes.
With this, also update all copyright dates.

Change-Id: Ie4365e32cd3b4b5870fe2cd03843400506e46265
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

feat(mt8189): add GPIO support

- Add GPIO support for MT8189.

Change-Id: I2d140b32eef8c05aba9170bf4af894ed43d52978
Signed-off-by: Cathy Xu <ot_cathy.xu@mediatek.com>

feat(mt8189): initialize platform for MT8189

- Add basic platform setup.
- Add MT8189 documentation at docs/plat/.
- Add generic CPU helper functions.
- Add basic register address.

Change-Id: Id59a

feat(mt8189): initialize platform for MT8189

- Add basic platform setup.
- Add MT8189 documentation at docs/plat/.
- Add generic CPU helper functions.
- Add basic register address.

Change-Id: Id59ae9265983defb46e27befabfd5c30b2b4a5a6
Signed-off-by: Gavin Liu <gavin.liu@mediatek.com>

show more ...

refactor(ti): introduce ti_bl31_setup

There maybe a lot of reuse between platforms for bl31_setup in future
which may require us to have a common bl31 setup driver for TI.
The ti_bl31_setup is expec

refactor(ti): introduce ti_bl31_setup

There maybe a lot of reuse between platforms for bl31_setup in future
which may require us to have a common bl31 setup driver for TI.
The ti_bl31_setup is expected to contain all the reusable bits
and the soc_bl31_setup can have the custom soc init functionality
like the mmap regions and any special sequences needed at
device boot
While at it, also fix the path of the reference to the kernel doc
for booting.

Change-Id: Ie574f08cf3ba75362c45f85306499061ef89c964
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): add the sec hdr to the ti sci msg

We can make an assumption that since TF-A is a secure entity it will
always communicate with a secure header present in all it's TI SCI
messages, whet

refactor(ti): add the sec hdr to the ti sci msg

We can make an assumption that since TF-A is a secure entity it will
always communicate with a secure header present in all it's TI SCI
messages, whether received or transmitted.
Hence, just add the sec hdr to the TI SCI header itself and get rid of
any logic that aims to skip these secure header bytes (like it was
being done in sec proxy for eg.)
No functional change expected. Hence, preserved the bits from the
previous sec proxy driver implementation where we zero out the chksum.

Change-Id: Id332276c038549e87dda1969b8dc90bcb19bf1ca
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): rename the k3_sec_proxy_chan_id

As part of further abstracting the transport layer, let's be more
consistent with the naming conventions. So, let's get rid of the
k3_sec_proxy_chan_id

refactor(ti): rename the k3_sec_proxy_chan_id

As part of further abstracting the transport layer, let's be more
consistent with the naming conventions. So, let's get rid of the
k3_sec_proxy_chan_id names with something more generic like
ti_sci_transport_chan_id and RX/TX_SECURE_TRANSPORT_CHANNEL_ID
for the enums

Change-Id: Iadf9255b5fbeffa2e5b3d9e6d85ba68fe5010c5b
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): rename the sec_proxy functions

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

refactor(ti): rename the sec_proxy functions

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_*.

Change-Id: I17a85b302e2a6c4cab71697110c48cbc09838ca6
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): add top level ti_sci transport layer

The TI SCI transport header will allow us to abstract all transport
related calls from the actual medium of transport which can vary
from device to

refactor(ti): add top level ti_sci transport layer

The TI SCI transport header will allow us to abstract all transport
related calls from the actual medium of transport which can vary
from device to device.
For eg. it is sec proxy for current TI K3 devices, but in future it
maybe mailbox like in the TI AM62L.
With this change, we no longer need to include anything from the IPC
folder, so drop it from plat_common.mk

Change-Id: Ic99209688cf69f20e694e31e553ce4ec74254669
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): move TI SCI and sec proxy to drivers

Prepare to support more devices and abstract TI SCI and it's transport
layers. This refactor will help keep things clean when new ipc drivers
get a

refactor(ti): move TI SCI and sec proxy to drivers

Prepare to support more devices and abstract TI SCI and it's transport
layers. This refactor will help keep things clean when new ipc drivers
get added.

Change-Id: I05673f379b1398c0b6a2bd9e1b5392165d12f151
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

Merge "fix(arm): resolve build issue with ARM_ROTPK_LOCATION=regs option" into integration

refactor(mediatek): move headers to common folder

The plat_macros.S and plat_private.h are identical across some
platforms, moved to the common folder for easier maintenance.

Change-Id: I31c71551aa

refactor(mediatek): move headers to common folder

The plat_macros.S and plat_private.h are identical across some
platforms, moved to the common folder for easier maintenance.

Change-Id: I31c71551aa0e891f080e58f21e6e79551d2a19e0
Signed-off-by: Gavin Liu <gavin.liu@mediatek.com>

show more ...

docs: add playbook for new releases

Change-Id: I76a2a84b176791e16372dab8bf565e48223a6756
Signed-off-by: Chris Palmer <palmer@google.com>

Merge changes from topic "upstream-stm32mp257d-ultra-fly-sbc" into integration

* changes:
feat(stm32mp2): use USART1 for debug console on ultra-fly boards
feat(fdts): add support for STM32MP257D

Merge changes from topic "upstream-stm32mp257d-ultra-fly-sbc" into integration

* changes:
feat(stm32mp2): use USART1 for debug console on ultra-fly boards
feat(fdts): add support for STM32MP257D-based ultra-fly-sbc board
feat(fdts): add dual-ranked LPDDR4 config for STM32MP2

show more ...

Merge changes from topic "mbedtls-3.6.3" into integration

* changes:
feat(mbedtls): update mbedtls to version 3.6.3
docs(prerequisites): update mbedtls to v3.6.3

Merge "refactor(st-pmic): use LOG_LEVEL for regulator debug output" into integration

Merge "feat(drtm): update DLME data header with actual Event Log size" into integration

Merge "fix(intel): update ssbl naming conventions" into integration

Merge "fix(spmd): check pwr mgmt status for SPMC framework response" into integration

fix(arm): resolve build issue with ARM_ROTPK_LOCATION=regs option

Fix the broken build when using the ARM_ROTPK_LOCATION=regs option.

Change-Id: Ieaa7baebd86448d198a1b9d2149a3490700b45d3
Signed-off

fix(arm): resolve build issue with ARM_ROTPK_LOCATION=regs option

Fix the broken build when using the ARM_ROTPK_LOCATION=regs option.

Change-Id: Ieaa7baebd86448d198a1b9d2149a3490700b45d3
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

perf(libc): use builtin implementations where possible

When conditions are right, eg a small memcpy of a known size and
alignment, the compiler may know of a sequence that is optimal for the
given c

perf(libc): use builtin implementations where possible

When conditions are right, eg a small memcpy of a known size and
alignment, the compiler may know of a sequence that is optimal for the
given constraints and inline it. If the compiler doesn't find one, it
will emit a call to the generic function (in the libc) which will
implement this in the most generic and unconstrained manner. That
generic function is rarely the most optimal when constraints are known.

So give the compiler a chance to do this. Replace calls to libc
functions that have builtins to the builtin and keep the generic
implementation if it decides to emit a call anyway.

And example of this in action is usage of FEAT_MOPS. When the compiler
is aware of the feature (-march=armv8.8-a) then it will emit the 3 MOPS
instructions instead of calls to our memcpy() and memset()
implementations.

Change-Id: I9860cfada1d941b613ebd4da068e9992c387952e
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

fix(arm): resolve misra rule R11.6 violation

Fixed below MISRA violation:
- MISRA violation: MC3R1.R11.6:
- A cast shall not be performed between a pointer to void and an
arithmetic data type.

fix(arm): resolve misra rule R11.6 violation

Fixed below MISRA violation:
- MISRA violation: MC3R1.R11.6:
- A cast shall not be performed between a pointer to void and an
arithmetic data type. (i.e cast from integer to void*)
- Fix:
- cast via portable and misra compliant type "uintptr_t" and
use 0U instead of NULL for comparisons.

Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: Ie3a7561d9a254027c5364485a1d72fc1320dfcad

show more ...