arm: dts: k3-am65: Add tag to disable UHS modes in SR 1.0

The 4 bit interface in am65 sr1.0 cannot be supported at 3.3V or 1.8V
because of erratas i2025 and i2026. However, SD card is the primary
boot mode for development usecases.

Continue to enable SD card in SR1.0 and disable UHS modes in it to
minimise any ageing issues happening because of the erratas.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>

arm: dts: k3-am65: Update the otap delay values to match the data from RIOT sheets

Update the otap delay values of the sdhci nodes in k3-am65-main.dts to
match the values of P.G. 2.0 and use k3-am654-base-board-sr1.dts to overlay
the otap delay values corresponding P.G. 1.0.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

dma: ti: k3-psil-am654: Drop unused PSIL EP static data

ICSSG Ethernet driver uses two src threads per port (one per slice).
Similarly CPSW uses one src thread.

Drop PSIL EP static data for other src threads in order to reduce
R5 SPL footprint. This makes AM65x board bootable again.

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

configs: am64x_evm_*_defconfig: Enable FDT library overlay support and remove redundant configs

Enable config for FDT library overlay support. Update the config files
to rearrange and remove redundant configs, using savedefconfig.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

fdt: Use phandle to distinguish DT nodes with same name

While assigning the sequence number to subsystem instances by reading the
aliases property, only DT nodes names are compared and not the complete
path. This causes a problem when there are two DT nodes with same name but
have different paths.

In arch/arm/dts/k3-am65-main.dtsi there are two USB controllers with the
same device tree node name but different path. When aliases are defined for
these USB controllers then fdtdec_get_alias_seq() fails to pick the correct
instance for a given index.

fdt_path_offset() function is slow and this would effect the U-Boot
startup. To avert the time penalty on all boards, apply this extra check
only when required by using a config option.

Fix it by comparing the phandles of DT nodes after the node names match,
under a config option.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC

ARMv8's generic timer[1] picks up it's graycode from GTC. However,
the frequency of the GTC is supposed to be programmed in CNTFID0[2]
register prior to enabling the GTC in CNTCR[3] register.

In K3 architecture, GTC provides a central time to many parts of the
SoC including graycode to the generic timer in the ARMv8 subsystem.
However, due to the central nature and the need to enable the counter
early in the boot process, the R5 based u-boot enables GTC and
programs it's frequency based on central needs of the system. This
may not be a constant 200MHz based on the system. The bootloader is
supposed to program the FID0 register with the correct frequency it
has sourced for GTC from the central system controller OR from PLLs
as appropriate, and TF-A is supposed[4] to use that as the frequency for
it's local timer.

Currently we are programming just the CNTCR[3] register to enable the
GTC, however we dont let TF-A know the frequency that GTC is actually
running at. A mismatch in programmed frequency and what we program for
generic timer will, as we can imagine, all kind of weird mayhem.

So, program the CNTFID0 register with the clock frequency. Note:
assigned-clock-rates should have set the clock frequency, so the only
operation we need to explicitly do is to retrieve the frequency and
program it in FID0 register.

Since the valid in K3 for GTC clock frequencies are < U32_MAX, we can
just cast the ulong and continue.

[1] https://developer.arm.com/documentation/100095/0002/generic-timer/generic-timer-register-summary/aarch64-generic-timer-register-summary
[2] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntfid0
[3] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntcr
[4] https://github.com/ARM-software/arm-trusted-firmware/commit/6a22d9ea3c7fa28d053d3ba264b49b7396a86f9e

Signed-off-by: Nishanth Menon <nm@ti.com>

arm: dts: k3-*-r5-*-board: Add GTC clock

Add GTC Clock definition as index 0 clock so that we can use the clock
node in the driver later on.

Signed-off-by: Nishanth Menon <nm@ti.com>

arm: dts: k3-am642-r5-evm:: Add GTC clock

Add GTC Clock definition as index 0 clock so that we can use the clock
node in the driver later on.

Signed-off-by: Nishanth Menon <nm@ti.com>

configs: am65x_evm: Define the maximum file size for DFU

In include/dfu.h, if CONFIG_SYS_DFU_MAX_FILE_SIZE is not defined then it is
defined as CONFIG_SYS_DFU_DATA_BUF_SIZE. This is 128 KiB for a53 core and
20 KiB for r5 core. If a larger file is transferred using dfu then it
fails.

CONFIG_SYS_DFU_DATA_BUF_SIZE can not be increased as there is not enough
heap memory to be allocated for the buffer in case of R5 spl.

Fix this by defining CONFIG_SYS_DFU_MAX_FILE_SIZE as the default
CONFIG_SYS_DFU_DATA_BUF_SIZE value.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

arm: dts: k3-am642-evm: Add pinmux for MMC1 (SD slot)

Add pinmux for MMC1 (SD slot).

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

configs: am64x_evm_a53_defconfig: Enable configs to save env in eMMC and FAT write

Enable configs to save env in eMMC and FAT write.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400

Enable configs to support HS200/HS400.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

configs: am64x_evm_a53_defconfig/am64x_evm_r5_defconfig: Enable configs to support eMMC boot

Enable configs to support eMMC boot.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

arm64: dts: ti: k3-am64-main: Add DT binding to support HS200/HS400 modes

Add DT binding to support HS400 modes.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

configs: am65/j72x: Set CONFIG_LOGLEVEL to 7

By default CONFIG_LOGLEVEL seems to be set to 4 which is
too low and doesn't show dev_info/dev_notice/dev_warn
messages on console. This has been deliberately set low
globally to be conservative setting across the board due to
primary bootloader size limitations. It is best to tune
per board config as per user needs.

On K3 we have separate SPL and u-boot configs so we
can afford to set u-boot CONFIG_LOGLEVEL to 7.

On AM65 this patch causes u-boot.img size to change from
932KB to 940KB with 1 line additional print during
MMC boot. i.e. details of Net subsystem

"Net: K3 CPSW: nuss_ver: 0x6BA00102 cpsw_ver: 0x6BA80102 ale_ver: 0x00293904 Ports:1 mdio_freq:1000000"

Similar 8KB difference was seen on J721E.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>

arm: dts: k3-am65: Add remoteproc-name to ICSSG remote processors

If a remoteproc-name DT property is not present then the u-boot
remoteproc class driver uses the node name as remote processor name.

As the remote processor node names are not unique between different
ICSSG instances it causes probe failure for subsequent ICSSG instances.

To resolve this we specify a unique name using the remoteproc-name
DT property.

Signed-off-by: Roger Quadros <rogerq@ti.com>

arm: dts: k3-am654: Sync ICSSG and prueth nodes with Kernel

Sync the ICSSG and prueth nodes with Kernel device tree.

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: ti: icssg_prueth: Update classifier code

Update classifier code to match kernel driver code. This
adds necessary functions required for SR2.0

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg_prueth: Add icssg_config_sr2()

SR2.0 needs more stuff to be configured so add a
separate function for it.

Signed-off-by: Roger Quadros <rogerq@ti.com>

soc: pruss: Add pruss_cfg_set_gpmux()

This is required for drivers to set GPMUX value for
each ICSS slice.

Signed-off-by: Roger Quadros <rogerq@ti.com>

soc: ti: pruss: Add pruss_cfg_update and friends

Add pruss_cfg_update() and other helper APIs to configure
CFG region i.e. to set GPI mode, enable/disable MII_RT and XFR mode.

Signed-off-by: Roger Quadros <rogerq@ti.com>

soc: ti: pruss: drop pruss_request_shrmem_region()

This is no longer in use so get rid of it.

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg_prueth: drop use of pruss_request_shrmem_region()

use pruss_request_mem_region() instead.

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg_prueth: icss_mii_rt: add more defines

Add MII_RT register bit defines.

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg_prueth: add icssg_switch_map.h for SR2.0

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg-prueth: Separate out SR1.0 configuration

Add a new compatible for SR1.0 as it needs slighty

different configuration than SR1.0.

Move SR1.0 config code to config.c/h

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg_prueth: introduce icssg_config.c and IPG config function

We need a different IPG for SR1.0 vs SR2.0

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg_prueth: move declarations to relevant header files

Move MII related functions to icss_mii_rt.h and prueth
related declarations to icssg_prueth.h

Signed-off-by: Roger Quadros <rogerq@ti.com>

net: icssg_prueth: rename driver files to be consistent with kernel

Let's keep the file names identical to kernel code so it is
easier to compare.

Signed-off-by: Roger Quadros <rogerq@ti.com>

remoteproc: pru_rproc: set constant table for PRUs

ICSS Ethernet firmware requires this to be set.

Signed-off-by: Roger Quadros <rogerq@ti.com>

drivers: soc: ti: pruss: add pruss_request_mem_region/pruss_release_mem_region

These APIs are used to request memory areas in the PRUSS i.e.
DRAM0, DRAM1 or SHARED_RAM2.

Also cleanup the code to use enum pruss_mem and struct pruss_mem_region
insted of open coded memory addresses and sizes.

Signed-off-by: Roger Quadros <rogerq@ti.com>

remoteproc: pru_rproc: Add support for Tx PRU cores on K3 AM65x SR2.0

The Tx_PRU cores have their own dedicated IRAM (smaller than a PRU
or RTU), Control and debug feature sets. The RTU and Tx_PRU cores
though share the same Data RAMs as the PRU cores, so the memories
have to be partitioned carefully between different applications.

Enhance the existing PRU remoteproc driver to support these new Tx
PRU cores by using specific compatibles.

Signed-off-by: Roger Quadros <rogerq@ti.com>

configs: am64x-evm: Enable USB and DFU related configs

Enable config options required to add DFU and USB host mode in U-Boot.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

arm: dts: k3-am642-evm-u-boot: Add U-Boot tags and fix the dr_mode to peripheral for USB subsystem

Add U-Boot tags and fix the dr_mode as peripheral in U-Boot to support DFU
by default.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

arm: dts: k3-am642-*-evm: Add USB support

AM64 EVM board has a micro USB 2.0 AB connector and the USB0_VBUS is
connected with a resistor divider in between. USB0_DRVVBUS pin is muxed
between USB0_DRVVBUS and GPIO1_79 signals.

Add the corresponding properties and set the pinmux mode for USB subsystem
in the evm dts file.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

arm: dts: k3-am64-main: Add USB DT nodes

Add DT node for the single USB subsystem in main dtsi file.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

ram: k3-am64: Configure DDR PLL before controller start for DDR4

DDR4 does not require the frequency handshaking needed for LPDDR4, and
attempting to just statically configure the PLL at this time for DDR4
seems to produce marginal stability. To remove any risk of DDR4 getting
stuck initializing, configure the clock before attempting to start the
controller for DDR4 and leave any frequency handshaking to LPDDR4 only.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Tested-by: Vignesh Raghavendra <vigneshr@ti.com>

configs: am64x_evm.h: Set up MTDPARTS for OSPI

Setup mtdids and mtdparts to be used at U-Boot prompt and also to be
passed as cmdline arguments to kernel. This enables kernel to create MTD
partition for each of the component required for boot.

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

configs: am64x_evm_*_defconfig: Enable OSPI related configs

Enable config options required to support OSPI along with OSPI boot.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>

ARM: dts: k3-am642-*-evm: Add OSPI flash node

AM64 EVM has a S28HS512T flash. Add DT nodes for the same.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>

ARM: dts: k3-am64-main: Add FSS and OSPI DT nodes

AM64 SoC has a Flash SubSystem with an OSPI controller within. Add DT
entries for the same.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>

ARM: dts: k3-am64: Setup translation for OSPI DATA region0

OSPI DATA region has an alias within 32 bit address space for 32 bit
core such as R5 to access OSPI flash. Setup translation for the same.

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

ARM: dts: k3-am64-main: Add CPSW DT nodes

AM64 as CPSW3G IP with 2 external ports. Add DT entries for the same
(based on kernel DT).

Disable second port as its by default set to ICSS usage on EVM.

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

ARM: dts: k3-am64-main: Add BCDMA and PKTDMA DT nodes

AM64 has a two DMA engines:
- BCDMA mainly used for m2m DMA
- PKTDMA mainly used by CPSW.

Add DT entries for the same (based on kernel DT)

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

net: ti: am65-cpsw-nuss: Add a new compatible for AM64

Add a new compatible to support AM64 SoC

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

net: ti: am65-cpsw-nuss: Don't cache disabled port ID

Currently driver may end up caching disabled port ID as active
interface. Fix this by bailing out earlier in case port is marked
disabled in the DT.

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

net: ti: am65-cpsw-nuss: Prepare to support non primary ext port

CPSW NUSS IP on K3 SoCs can have more than one external port (upto 8)
Therefore increase AM65_CPSW_CPSWNU_MAX_PORTS to 9 (8 ext + 1 Root port)
as preparation to allow any one of the 8 ports to be used as ethernet
interface in U-Boot.

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

dma: ti: k3-udma: Add BCDMA and PKTDMA support

Sync BCDMA and PKTDMA support from Kernel for AM64 SoC

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

dma: ti: k3-psil-am64: Add AM64 PSIL endpoint data

Add AM64 SoC specific channel mapping and endpoint data.

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

dma: ti: k3-psil: Extend PSIL EP data extension for AM64

Extend PSIL EP data to include AM64 DMA specific information

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

soc: ti: k3-navss-ringacc: Add AM64 ringacc support

AM64 dual mode rings are modeled as pair of Rings objects which has common
configuration and memory buffer, but separate real-time control register
sets for each direction mem2dev (forward) and dev2mem (reverse).

AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.

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

firmware: ti_sci: Update ti_sci_cmd_rm_udmap_tx_ch_cfg() API to the latest

Update struct ti_sci_msg_rm_udmap_tx_ch_cfg_req to latest ABI to support
AM64x BCDMA Block copy channels.

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

arm: dts: k3-j7200: Set initial TX start to 18

TX = 16 is on the border of the range of valid TX values for this board
with the Cypress S28 flash. As a result, the PHY tuning sometimes fails
to find rxlow at that point, causing the algorithm to iterate over the
TX range taking a hit on the tuning time.

TX = 18 is much more stable in comparison. Tuning consistently succeeds
with it. Use it as the initial value to stop the PHY tuning from taking
longer.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

spi: spi-cadence-quadspi: Pull TX start and end boundaries from DT

The TX window from 16 to 48 is not always the best place to look for
rxlow and rxhigh values. Sometimes it might fall outside the range of
valid TX values. So to account for that a mechanism was introduced to
iterate over the TX boundaries to find the correct TX window.

This mechanism makes the algorithm more robust, and it will fail less
often. But the downside is that it would take longer to finish if TX =
16 or TX = 48 are outside the valid TX range. This can be mitigated by
specifying the initial values of the TX boundaries via device tree. This
way, the algorithm is kept robust because it will still iterate over the
TX range if the initial values do not work. But at the same time the
tuning time can be optimized by properly setting the initial boundary
values observed to be stable during testing.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

spi: spi-cadence-qspi: Search for rxlow at incrementing TX values

Sometimes TX = 16 might fall outside the range of valid TX values. In
that case, the tuning algorithm would be unable to find rxlow or rxhigh,
and give up. If TX = 16 is on the border of the valid range, then on
some runs it would succeed and on some others it would fail.

So if rxlow is not found at the initial TX value of 16, do not give up.
Instead, increment the TX and look for it again. This process is
repeated until the TX crosses a threshold, after which an error is
returned. A similar process is followed for the upper TX boundary as
well.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>

configs: am64x_evm_r5: Enable GPIO regulator

Enable GPIO regulator.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: dts: k3-am642-r5-evm: Add GPIO DDR VTT regulator

Add DDR VTT regulator.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: dts: k3-am64-main: Add GPIO nodes

Add main domain GPIO nodes.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: am642: Add support for triggering ddr init from SPL

In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support for
triggering DDR initialization from board_init_f().

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: dts: k3-am642: Add ddr node

Introduce ddr node for am642 needed for all ddr configurations.

Also, introduce the 1600MTs DDR4 configuration that is supported on the
am642-evm.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

TEMP: drivers: ram: k3-am64: Introduce ddrss driver

The AM64x DDR subsystem comprises DDR controller, DDR PHY and wrapper
logic to integrate these blocks in the device. The DDR subsystem is
used to provide an interface to external SDRAM devices which can be
utilized for storing program or data. Introduce support for the
DDR controller and DDR phy within the DDR subsystem.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

configs: am64x_evm_a53: Add Initial support

Add initial A53 defconfig support for AM64x SoCs.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

configs: am64x_evm_r5: Add Initial support

Add initial R5 defconfig support for AM64x SoCs.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: dts: k3-am642: Add r5 specific dt support

Add initial support for dt that runs on r5.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: dts: k3-am642: Add initial support for EVM

The AM642 EValuation Module (EVM) is a board that provides access to
various peripherals available on the AM642 SoC, such as PCIe, USB 2.0,
CPSW Ethernet, ADC, and more.

Add basic support.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: dts: ti: Add Support for AM642 SoC

The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable applications such as
Motor Drives, PLC, Remote IO and IoT Gateways.

Some highlights of this SoC are:
* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
  MCUs, and a single Cortex-M4F.
* Two Gigabit Industrial Communication Subsystems (ICSSG).
* Integrated Ethernet switch supporting up to a total of two external
  ports.
* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
  controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
  peripherals.
* Centralized System Controller for Security, Power, and Resource
  Management (DMSC).

See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2

Introduce basic support for the AM642 SoC to enable SD/MMC boot.
Introduce a limited set of MAIN domain periperhals under cbass_main and
a placeholder cbass_mcu node for future MCU domain usage.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64

Add pinctrl macros for AM64 SoC. These macro definitions are similar to
that of previous platforms, but adding new definitions to avoid any
naming confusions in the soc dts files.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

board: ti: am64x: Add board support for am64x evm

Add board specific initialization for am64x based boards.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

mailbox: k3-sec-proxy: Extend valid thread IDs

AM64x uses a different thread mapping that existing K3 SoCs, so update
the valid thread ID list to include those used for AM64x.

Also remove the comment identifying the purpose of each thread ID. The
purpose of the thread ID is specified when describing the threads in the
device tree and the same ID can mean different things on different SoCs,
so the comment is not useful.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

mmc: sdhci_am654: Add Support for TI's AM642 SoC

Add support for the controller present on the AM642 SoC.

There are instances:
sdhci0: 8bit bus width, max 400 MBps
sdhci1: 4bit bus width, max 100 MBps

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

armv8: mach-k3: am642: Add custom MMU support

Change the memory attributes for the DDR regions used by the remote
processors on AM65x so that the cores can see and execute the proper code.

A separate table based on the previous K3 SoCs is introduced since the
number of remote processors and their DDR usage is different between the
SoC families.

Signed-off-by: Keerthy J <j-keerthy@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: am642: Shut down R5 core after ATF startup on A53

The AM642 SoCs use the Main R5FSS0 as a boot processor, and runs
the R5 SPL that performs the initialization of the System Controller
processor and starting the Arm Trusted Firmware (ATF) on the Arm
Cortex A53 cluster. The Core0 serves as this boot processor and is
parked in WFE after all the initialization. Core1 does not directly
participate in the boot flow, and is simply parked in a WFI.

Power down these R5 cores (and the associated RTI timer resources
that were indirectly powered up) after starting up ATF on A53 by
using the appropriate SYSFW API in release_resources_for_core_shutdown().
This allows these Main R5F cores to be further controlled from the
A53 to run regular applications.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: am642: Use mmc start and stop callbacks

To avoid any glitches on MMC clock line, make use of pm per and post
callbacks when loading sysfw.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: am642: Load SYSFW binary and config from boot media

Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the AM642 early initialization sequence. Also
make use of existing logic to detect if ROM has already loaded sysfw
and avoided attempting to reload and instead just prepare to use already
running firmware.

While at it also initialize the MAIN_UART1 pinmux as it is used by SYSFW
to print diagnostic messages.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: am642: Store boot info from ROM

For AM642, ROM supports loading system firmware directly
from boot image. ROM passes information about the number of
images that are loaded to bootloader at a specific address
that is temporary.  Add support for storing this information
somewhere permanent before it gets corrupted.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: am642: Unlock all applicable control MMR registers

To access various control MMR functionality the registers need to
be unlocked. Do that for all control MMR regions in the MAIN domain.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: am642: Add support for boot device detection

AM642 allows for booting from primary or backup boot media.
Both media can be chosen individually based on switch settings.
ROM looks for a valid image in primary boot media, if not found
then looks in backup boot media. In order to pass this boot media
information to boot loader, ROM stores a value at a particular
address. Add support for reading this information and determining
the boot media correctly.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: Add basic support for AM642 SoC definition

The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable applications such as
Motor Drives, PLC, Remote IO and IoT Gateways.

Some highlights of this SoC are:
* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
  MCUs, and a single Cortex-M4F.
* Two Gigabit Industrial Communication Subsystems (ICSSG).
* Integrated Ethernet switch supporting up to a total of two external
  ports.
* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
  controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
  peripherals.
* Centralized System Controller for Security, Power, and Resource
  Management (DMSC).

See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: dts: k3-am65: set sdhci1 node at 25Mhz

Some of the AM65 PG1 are experiencing boot problems at 50 Mhz
which was introduced with
commit cc4edab968ee ("arm: dts: k3-am65: Fix mmc nodes")

This fix is to enable sdhci1 SD card interface at 25 Mhz.

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Praneeth Bajjuri <praneeth@ti.com>

Remove redundant YYLOC global declaration

commit 018921ee79d3f30893614b3b2b63b588d8544f73 upstream.

Same as the upstream fix for building dtc with gcc 10.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[praneeth@ti.com: cherry-pick commit '018921ee79d3' from v2020.04-rc2]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

tools: k3_fit_atf: fix FIT image ordering for UART boot

Ymodem is pretty picky about the ordering of the images, causing a boot
failure if images are in wrong order. SPL must be the last image loaded
in the loadables list, as any images post it are effectively ignored.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm: mach-k3: sysfw-loader: Correct value used in type field

The INDEX value was mistakenly used in the type field instead of the
value corresponding to the TISCI MSG for the type of boardcfg being
shared, so correct this.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

firmware: ti_sci: Update ti_sci_msg_req_reboot to include domain

The ti_sci_msg_req_reboot message payload has been extended to include a
domain field, but for the purposes of u-boot this should be zero to
reset the entire SoC as it did before. Include domain for completeness
and set to zero to ensure proper operation.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: security: do not check images with zero size

If DM image is not built-in to the fit, its size is going to be zero.
In this case, do not attempt to authenticate it.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm: mach-k3: common: fix build failure for HS devices

HSM rearch support series inadvertently broke HS build. Fix by removing
the offending piece of code conditionally via config flags.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm: mach-k3: sysfw-loader: pass boardcfg to sciserver

Copy the contents of the board config loaded from sysfw.itb into an
EXTBOOT shared memory buffer that gets passed to sciserver. This only
needs to be done if EXTBOOT area has not been populated by ROM code yet.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

configs: j7200_evm_r5: Enable raw access power management features

Sysfw is not going to provide access to power management features in the
new architecture, so SPL must implement these itself. Enable all the raw
register access based clock + power domain drivers.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[praneeth@ti.com: rebased patch to current ti-u-boot-2020.01]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

configs: j721e_evm_r5: enable FIT image post processing

This is used to parse the images from FIT, and to determine image types.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

configs: j721e_evm_a72: disable watchdog

Disable early boot watchdog as it is not really needed for anything
right now.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[praneeth@ti.com: rebase the patch to current ti-u-boot-2020.01]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

configs: j721e_evm_r5: disable SCI PM drivers

With the sysfw rearch, PM services are no longer available for R5 SPL to
use. Instead, we will be using the raw PM register level access drivers
for any PM. Thus, disable the SCI PM drivers to reflect this.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

configs: j721e_evm_r5: disable serdes

This is not currently supported in the rearch, so disable it.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

configs: j721e_evm_r5: Enable raw access power management features

Sysfw is not going to provide access to power management features in the
new architecture, so SPL must implement these itself. Enable all the raw
register access based clock + power domain drivers.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm: mach-k3: common: Drop main r5 start

Drop the main R5 startup for now.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

arm: mach-k3: do board config for PM and RM only if supported

If the raw PM support is built in, we are operating in the split
firmware approach mode where RM and PM support is not available. In this
case, skip the board config for these two.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm: mach-k3: j721e: force enable A72 core 0 during spl shutdown

With the new raw register mode access PM drivers, A72 core is not
enabled via ti-sci services, leading into bad usecounts for the core.
This effectively shuts down the A72 core when SPL goes down. Prevent the
problem by force enabling the A72 core once, which increases the use
count.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm: mach-k3: add support for detecting firmware images from FIT

Add callback routines for parsing the firmware info from FIT image, and
use the data to boot up ATF and the MCU R5 firmware.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

tools: k3_fit_atf: add DM binary to the FIT image

Add DM (device manager) firmware image to the fit image that is loaded by
R5 SPL. This is needed with the HSM rearch where the firmware allocation
has been changed slightly.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm: mach-k3: Add platform data for j721e and j7200

Add platform clock and powerdomain data for J721e and J7200. This data
is used by the corresponding drivers to register all the required device
clocks and powerdomains.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

cmd: ti: pd: Add debug command for K3 power domains

Add support command for debugging K3 power domains. This is useful with
the HSM rearch setup, where power domains are directly controlled by SPL
instead of going through the TI SCI layer. The debugging support is only
available in the u-boot codebase though, so the raw register access
power domain layer must be enabled on u-boot side for this to work. By
default, u-boot side uses the TI SCI layer, and R5 SPL only uses the
direct access methods.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

power: domain: Introduce driver for raw TI K3 PDs

Normally, power domains are handled via TI-SCI in K3 SoCs. However,
SPL is not going to have access to sysfw resources, so it must control
them directly. Add driver for supporting this.

Signed-off-by: Tero Kristo <t-kristo@ti.com>