fix(k3low): extend BL1 RW region for debug builds

DEBUG=1 builds include larger xlat tables that overflow BL1's 12K RW
region by 4K. Extend BL1_RW_LIMIT by 0x1000 under #ifdef DEBUG and
emit a loud

fix(k3low): extend BL1 RW region for debug builds

DEBUG=1 builds include larger xlat tables that overflow BL1's 12K RW
region by 4K. Extend BL1_RW_LIMIT by 0x1000 under #ifdef DEBUG and
emit a loud make-time warning that this binary is non-functional
(the extended region overlaps MAILBOX_SHMEM).
Also, add an ERROR print to make sure users are aware at boot
that BL1 has been built with DEBUG flag and panic.

NOT intended for production or functional testing.

Change-Id: Iae9453d8c5305e3e88c6e21fa5ac042c9a210d37
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

fix(k3low): add plat_get_image_source stub for BL1

AM62L BL1 never calls load_image (it hands off to ROM via secure
transport and enters WFI), but the generic bl_common.c:load_image
pulls in plat_ge

fix(k3low): add plat_get_image_source stub for BL1

AM62L BL1 never calls load_image (it hands off to ROM via secure
transport and enters WFI), but the generic bl_common.c:load_image
pulls in plat_get_image_source as a required symbol. Add a stub
returning -ENOTSUP to satisfy the linker.

Change-Id: I331ad94dea110a7202d3961119ac690b3c499736
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

feat(k3low): add BL1 platform definitions and integration for AM62L

AM62L devices use BL1 to configure DDR4/LPDDR4 before the secondary
bootloader. This patch wires all prior DDR and board patches i

feat(k3low): add BL1 platform definitions and integration for AM62L

AM62L devices use BL1 to configure DDR4/LPDDR4 before the secondary
bootloader. This patch wires all prior DDR and board patches into a
complete, buildable bl1.bin:

- ti_platform_defs.h: add IMAGE_BL1 conditionals for BL1-specific
stack and memory layout definitions.
- platform_def.h: add BL1 SRAM base/size and mailbox address
definitions used by am62l_bl1_setup.c.
- am62l_bl1_setup.c: BL1 platform initialisation — console, DDR
init via the Cadence/TI shim, and WFI-based handoff to the
secondary bootloader.
- platform.mk: add BL1_SOURCES, K3_LPDDR4_SOURCES, update BUILD_PLAT
and PLAT_INCLUDES to compile all DDR and BL1 sources.

Change-Id: I91e8b9e8e43a5560aa688d58e6805a7b5236de44
Signed-off-by: Hari Nagalla <hnagalla@ti.com>

show more ...

feat(k3low): add AM62L DDR platform shim and EVM board config

Rename the board directory from am62lx/ to am62lx-evm/ to reflect the
specific board variant, and introduce the EVM board configuration:

feat(k3low): add AM62L DDR platform shim and EVM board config

Rename the board directory from am62lx/ to am62lx-evm/ to reflect the
specific board variant, and introduce the EVM board configuration:

- board_config.c: pad-mux initialisation for MAIN/WKUP UART0 pins,
verified against the AM62L TRM (SPRUJB4A p.3976).
- board_def.h: board-level UART base and clock definitions.
- board_config.h: shared header declaring board_init().

Add the TI-authored AM62L DDRSS platform shim that wraps the Cadence
driver for this SoC:

- am62l_ddrss.c / am62l_ddrss.h: PSC power sequencing and DDR
initialisation flow calling the Cadence CTL/PHY/PI APIs.
- am62lx_ddr_config.c / am62lx_ddr_config.h: register data for the
AM62L DDRSS configuration.
- am62lx_skevm_lp4_50_800.h: machine-generated SK-EVM LPDDR4 register
values produced by the SysConfig DDR tool v0.10.30. This file should
be regenerated via that tool if board or timing parameters change.

New source files are intentionally unreferenced in platform.mk pending
the BL1 integration patch.

board.mk is introduced as a placeholder required by platform.mk's
include directive for BL31 builds; BL1_SOURCES will be added in the
next patch when BL1 support is wired in.

Change-Id: I8aff5eb1c2429646a701dc3b09821318bb6e73b9
Signed-off-by: Hari Nagalla <hnagalla@ti.com>

show more ...

feat(k3low): introduce Cadence LPDDR4 core driver for AM62L

AM62L devices support 16-bit DDR4/LPDDR4 DRAM memory devices. The core
DDR4/LPDDR4 driver was developed by Cadence. This patch introduces

feat(k3low): introduce Cadence LPDDR4 core driver for AM62L

AM62L devices support 16-bit DDR4/LPDDR4 DRAM memory devices. The core
DDR4/LPDDR4 driver was developed by Cadence. This patch introduces the
Cadence IP driver files (lpddr4.c, lpddr4_16bit.c, lpddr4_obj_if.c and
their associated headers) which carry dual copyright (Cadence + TI).

The driver was pruned from ~6800 macros to ~80 with AI-assisted removal
of unused code; the Cadence CTL/PHY/PI API surface remains intact for
review against the User Guides.

These files are intentionally unreferenced in platform.mk pending the
AM62L platform shim in the next patch.

For additional information please check the technical reference
manual at:
https://www.ti.com/lit/pdf/sprujb4

Change-Id: I8b02a6b30e5ea7b1b457cc0a933d8ef232993fa1
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>

show more ...

feat(k3low): re-configure firewalls for TI AM62L

In TI AM62L SoC, some of the firewalls are configured by ROM during
boot, or are at their default configurations. These firewalls are not
necessary a

feat(k3low): re-configure firewalls for TI AM62L

In TI AM62L SoC, some of the firewalls are configured by ROM during
boot, or are at their default configurations. These firewalls are not
necessary after the boot phase. For an HS-SE(SECURE ENFORCED) type
device, where the security goals are fully enforced, this causes
firewall exception when those regions are accessed from non-secure A53
core.

This commit adds changes to properly configure firewalls for AM62L SoC
initialization to remove the appropriate firewalls. A similar approach
is used for some other K3 TI SoCs, but in U-Boot. This code is based on
the U-Boot K3 firewall disabling code. Link:
https://github.com/u-boot/u-boot/blob/f9ffeec4bdcf1da655a0ffea482062adde78fee8/arch/arm/mach-k3/r5/common.c#L282

Change-Id: I6dd81d0544e181a58ce963ff9d724f465c764da0
Signed-off-by: T Pratham <t-pratham@ti.com>

show more ...

feat(k3): handle suspend in case of LPM_BOARDCFG_MANAGED

The J7 platforms support LPM_BOARDCFG_MANAGED[1] capability where the
low power mode configuration is done statically for the DM via the
pm-b

feat(k3): handle suspend in case of LPM_BOARDCFG_MANAGED

The J7 platforms support LPM_BOARDCFG_MANAGED[1] capability where the
low power mode configuration is done statically for the DM via the
pm-boardcfg. The specific suspend modes (eg: LPM_SOC_OFF, LPM_MCU_ONLY)
are not sent as a separate firmware capability like they are in the case
of LPM_DM_MANAGED.

Hence, split the firmware capability check to first look for the
DM_MANAGED or BOARDCFG_MANAGED capability and register the
pwr_domain_suspend psci callback accordingly.

Introduce LPM_BOARDCFG_MANAGED cap to handle suspend for J7
platforms as well.

Link: [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps

Change-Id: Iaa0ab478cbe0db6652f61e9d733c0fddb4bab234
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

feat(ti): add message to encrypt tfa during suspend

On some K3 plaforms, BL31 runs from an internal SRAM. During low power
modes like SOC_OFF, IO_ONLY_PLUS_DDR etc, the power to the SRAM
is cut off

feat(ti): add message to encrypt tfa during suspend

On some K3 plaforms, BL31 runs from an internal SRAM. During low power
modes like SOC_OFF, IO_ONLY_PLUS_DDR etc, the power to the SRAM
is cut off and only the DDR is active in self-refresh state.

Hence at suspend, BL31 with its context should be encrypted by TIFS and
saved in DDR. Encryption is needed so that the BL31 is not tampered with
while in DRAM.

We only need the encryption function here because the decryption message
will be send by the R5 SPL at resume.

Also introduce the LPM_ENCRYPT_IMAGE[1] capability which signals that FW
has the support to encrypt the image using the TISCI_MSG_LPM_ENCRYPT[2]
tisci message.

The encrypt_tfa message requires that the LPM_SAVE_ADDR[3] message is sent
during boot. This is taken care of by the bootloader.

Link: [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps
Link: [2] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#lpm-msg-lpm-encrypt
Link: [3] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#lpm-msg-lpm-save-addr

Change-Id: I266472da87dd0821493019b2d9853f8886f33811
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

feat(k3): choose PLAT_CLUSTER_DEVICE_START_ID depending on the SoC

The CLUSTER_DEVICE_START_ID denotes the device id of the A-core cluster.
It is utilized when powering off the entire cluster.

The

feat(k3): choose PLAT_CLUSTER_DEVICE_START_ID depending on the SoC

The CLUSTER_DEVICE_START_ID denotes the device id of the A-core cluster.
It is utilized when powering off the entire cluster.

The "generic" boards include J7200, J721E, J721S2 and AM65X platforms.

PLAT_CLUSTER_DEVICE_START_ID should be 4 instead of 198 on J7200[1],
J721E[2] and J721S2[3]. It is 198 only for AM65X[4].

This breaks PSCI APIs around cluster control and is exposed when
suspend-to-ram is enabled.

Query the JTAG_ID to get the SoC part number and choose the
CLUSTER_DEVICE_START_ID_AM65X when AM65X SoC is detected, else use
the PLAT_CLUSTER_DEVICE_START_ID that is defined in the respective
"board_def" file.

Link: [1] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/devices.html
Link: [2] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/devices.html
Link: [3] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/devices.html
Link: [4] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/devices.html

Change-Id: Idcd47c94e06996e8c1d68b49f13d4d693e95b17d
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

feat(k3): add SoC detection support

Implement SoC detection by reading the part number from the JTAG_ID
register. The part number is used to determine the appropriate cluster
start ID for the SoC.

feat(k3): add SoC detection support

Implement SoC detection by reading the part number from the JTAG_ID
register. The part number is used to determine the appropriate cluster
start ID for the SoC.

Note: J742S2 and J784S4 have the same part number and cluster start ID,
so they are handled identically without additional logic.

Change-Id: Ie97e123627b562edf34e7ff3839f6ceb8b0bbd8b
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

Merge "fix(cm): deprecate use of NS_TIMER_SWITCH" into integration

feat(ti): de-assert AINACTS at boot

De-asserting AINACTS at startup to enable ACP interface. This is
required to enable limited system level IO coherency via ACP port
(eg.: DMA traffic on AM62L driv

feat(ti): de-assert AINACTS at boot

De-asserting AINACTS at startup to enable ACP interface. This is
required to enable limited system level IO coherency via ACP port
(eg.: DMA traffic on AM62L driving ASEL = 14/15).

Change-Id: Iceaf992dec5dc37eae6dc06895585ea712f23496
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>

show more ...

fix(cm): deprecate use of NS_TIMER_SWITCH

On AArch64, secure world has it's own EL3 physical timer registers
accessible to secure EL1 in absence of S-EL2. With S-EL2 there is
virtualized view availa

fix(cm): deprecate use of NS_TIMER_SWITCH

On AArch64, secure world has it's own EL3 physical timer registers
accessible to secure EL1 in absence of S-EL2. With S-EL2 there is
virtualized view available for EL1 timer registers. So it is
unreasonable for secure world to use non-secure EL1 physical timer
registers. Moreover, the non-secure operating system (Linux in our case)
relies heavily on these EL1 physical timer registers for scheduling
decisions. If NS_TIMER_SWITCH is enabled, it simply breaks the preemption
model of the non-secure world by disabling non-secure timer interrupts
leading to RCU stalls being observed on long running secure world tasks.

The only arch timer register which will benefit from context management
is cntkctl_el1: Counter-timer Kernel Control Register. This enables the
secure and non-secure worlds to independently control accesses to EL0
for counter-timer registers. This is something that OP-TEE uses to
enable ftrace feature for Trusted Applications and SPM_MM uses for EL0
access as well.

Lets enable context management of cntkctl_el1 by default and deprecate
conditional context management of non-secure EL1 physical timer
registers for whom there isn't any upstream user. With that deprecate
this NS_TIMER_SWITCH build option which just adds confusion for the
platform maintainers. It will be eventually dropped following
deprecation policy of TF-A.

Reported-by: Stauffer Thomas MTANA <thomas.stauffer@mt.com>
Reported-by: Andrew Davis <afd@ti.com>
Change-Id: Ifb3a919dc0bf8c05c38895352de5fe94b4f4387e
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>

show more ...

feat(ti): am62lx init: boot notif and version msg

Consume the boot notification on this platform before we start further
communication with the system-firmware.

Change-Id: Ia9e5d8d616d7d9cd50ee5de2

feat(ti): am62lx init: boot notif and version msg

Consume the boot notification on this platform before we start further
communication with the system-firmware.

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

show more ...

feat(ti): add mmu regions for am62l soc

Update the k3low bl31 platform setup to map required device regions
(USART, GIC, GTC, MMR, and mailbox) in the MMU. This ensures that all
necessary hardware b

feat(ti): add mmu regions for am62l soc

Update the k3low bl31 platform setup to map required device regions
(USART, GIC, GTC, MMR, and mailbox) in the MMU. This ensures that all
necessary hardware blocks are accessible to the A53 cores on the
AM62L SoC.
Use 4K aligned address sizes wherever applicable, and update the
file header comment from "K3 SOC specific bl31_setup" to "k3low SoC
specific bl31_setup" to accurately represent the platform specific
nature of this file.
As part of the effort, rename WKUP_CTRL_MMR0_DEVICE_MANAGEMENT_BASE
to WKUP_CTRL_MMR0_BASE to make name shorter.

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

show more ...

feat(ti): build generic timer

Also, make sure we init the generic timer as part of the soc init
on am62lx as we use it later for delays

Change-Id: I921f4e4120ddaba588eb5b876231435fff3f7f3c
Signed-o

feat(ti): build generic timer

Also, make sure we init the generic timer as part of the soc init
on am62lx as we use it later for delays

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

show more ...

fix(ti): specify allowable rcv_addr in mailbox

The ti_sci_transport_recv function had an overly restrictive check
where we enforced the rcv_addr to be always at the start of the
RX_START region in s

fix(ti): specify allowable rcv_addr in mailbox

The ti_sci_transport_recv function had an overly restrictive check
where we enforced the rcv_addr to be always at the start of the
RX_START region in shared memory. This started failing unnecessarily
when messages started being received at a location other than the
beginning.
However, the sender might send the messages at any location within
the share memory region if it does some sort of buffer management.
In such a case, TFA needs to just make sure the message being read
is well within the allocated shared memory region. Not necessarily
at the start.

Fixes: 9347ff4561e445d4 ("feat(ti): add support for TI mailbox driver")
Change-Id: I32cf0f5e4b9fedf49e40ace0bef06b7fc4c016f6
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

feat(ti): enable power state validation for K3 SoCs

Add power state validation for K3 SoCs to ensure proper PSCI power state
transitions. Defining validate_power_state enables the
PSCI_CPU_SUSPEND_A

feat(ti): enable power state validation for K3 SoCs

Add power state validation for K3 SoCs to ensure proper PSCI power state
transitions. Defining validate_power_state enables the
PSCI_CPU_SUSPEND_AARCH64 capability and, in turn, CPU_SUSPEND.

validate_power_state checks if the requested power level and power state
are in a valid configuration. If the power state requested is standby,
set the core power state to the maximum retention state.

Change-Id: Ied3ebdc583b2e5b7c86923705954d763997b324e
Signed-off-by: Kendall Willis <k-willis@ti.com>

show more ...

fix(ti): remove validate_power_state definition

validate_power_state should not be defined since CPU suspend is not yet
supported.

Defining the validate_power_state function without any meaningful

fix(ti): remove validate_power_state definition

validate_power_state should not be defined since CPU suspend is not yet
supported.

Defining the validate_power_state function without any meaningful logic
caused a bug where a crash would happen if a device tried to enter a power
state that was not yet supported by TFA. This is because
validate_power_state would return a pass when the state was not properly
checked.

Removing the validate_power_state definition disables the
PSCI_CPU_SUSPEND_AARCH64 capability which will prevent the HLOS from
trying to suspend the CPU all together. This will fix the aforementioned
bug from occurring.

Fixes: 2e9c9e829964 ("ti: k3: common: Add PSCI stubs")
Change-Id: I3bbbd228fbddea64e72f0cf50afc6b25fb6d317c
Signed-off-by: Kendall Willis <k-willis@ti.com>

show more ...

fix(ti): fix UNUSED_VALUE in AM62L PSCI Driver

New Defects reported by Coverity Scan found value "-6" to "ret" here,
but that stored value is overwritten before it can be used.
We'd rather just retu

fix(ti): fix UNUSED_VALUE in AM62L PSCI Driver

New Defects reported by Coverity Scan found value "-6" to "ret" here,
but that stored value is overwritten before it can be used.
We'd rather just return from those places to avoid this, similar
to how it was being done in k3_psci as well.

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

show more ...

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

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

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