summaryrefslogtreecommitdiff
path: root/arch/arm/mach-k3/common.h
AgeCommit message (Collapse)Author
2020-08-11arm: mach-k3: j7200: Detect if ROM has already loaded sysfwLokesh Vutla
Detect if sysfw is already loaded by ROM and pass this information to sysfw loader. Based on this information sysfw loader either loads the sysfw image from boot media or just receives the boot notification message form sysfw. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com>
2020-08-11arm: mach-k3: j7200: Add support for SOC detectionLokesh Vutla
The J7200 SoC is a part of the K3 Multicore SoC architecture platform. It is targeted for automotive gateway, vehicle compute systems, Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications. The SoC aims to meet the complex processing needs of modern embedded products. Some highlights of this SoC are: * Dual Cortex-A72s in a single cluster, two clusters of lockstep capable dual Cortex-R5F MCUs and a Centralized Device Management and Security Controller (DMSC). * Configurable L3 Cache and IO-coherent architecture with high data throughput capable distributed DMA architecture under NAVSS. * Integrated Ethernet switch supporting up to a total of 4 external ports in addition to legacy Ethernet switch of up to 2 ports. * Upto 1 PCIe-GEN3 controller, 1 USB3.0 Dual-role device subsystems, 20 MCANs, 3 McASP, eMMC and SD, OSPI/HyperBus memory controller, I3C and I2C, eCAP/eQEP, eHRPWM among other peripherals. * One hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL management. See J7200 Technical Reference Manual (SPRUIU1, June 2020) for further details: https://www.ti.com/lit/pdf/spruiu1 Add support for detection J7200 SoC Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
2020-08-11arm: mach-k3: j721e: Add detection for j721eLokesh Vutla
Add an api soc_is_j721e(), and use it to enable certain functionality that is available only on j721e. This detection is needed when DT is not available. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
2020-08-11arm: mach-k3: Move mmr_unlock to a common locationLokesh Vutla
mmr_unlock api is common for all k3 devices. Move it to a common location. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com>
2020-07-25arm: mach-k3: Use SOC driver for device identificationDave Gerlach
Make use of UCLASS_SOC to find device family and revision for print_cpuinfo. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-24Revert "Merge tag 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm"Tom Rini
This reverts commit 5d3a21df6694ebd66d5c34c9d62a26edc7456fc7, reversing changes made to 56d37f1c564107e27d873181d838571b7d7860e7. Unfortunately this is causing CI failures: https://travis-ci.org/github/trini/u-boot/jobs/711313649 Signed-off-by: Tom Rini <trini@konsulko.com>
2020-07-20arm: mach-k3: Use SOC driver for device identificationDave Gerlach
Make use of UCLASS_SOC to find device family and revision for print_cpuinfo. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-05-19arm: mach-k3: Enable dcache in SPLJan Kiszka
Add support for enabling dcache already in SPL. It accelerates the boot and resolves the risk to run into unaligned 64-bit accesses. Based on original patch by Lokesh Vulta. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-04-19arm: mach-k3: Use JTAD_ID register for device identificationLokesh Vutla
JTAG ID register is defined by IEEE 1149.1 for device identification. Use this JTAG ID register for identifying AM65x[0] and J721E[1] devices instead of using SoC specific registers. [0] http://www.ti.com/lit/ug/spruid7e/spruid7e.pdf [1] http://www.ti.com/lit/ug/spruil1a/spruil1a.pdf Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-03-11arm: mach-k3: Add a separate function for printing sysfw versionLokesh Vutla
Add a separate function for printing sysfw version so that it can be called independently of k3_sysfw_loader. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2020-03-03arm: k3: Add support for loading non linux remote coresKeerthy
Add MAIN domain R5FSS0 remoteproc support from spl. This enables loading the elf firmware in SPL and starting the remotecore. In order to start the core, there should be a file with path "/lib/firmware/j7-main-r5f0_0-fw" under filesystem of respective boot mode. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [Guard start_non_linux_remote_cores under CONFIG_FS_LOADER] Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2020-01-20arm: K3: Disable ROM configured firewallsAndrew F. Davis
ROM configures certain firewalls based on its usage, which includes the one in front of boot peripherals. In specific case of boot peripherals, ROM does not open up the full address space corresponding to the peripherals. Like in OSPI, ROM only configures the firewall region for 32 bit address space and mark 64bit address space flash regions as in-accessible. When security-cfg is initialized by sysfw, all the non-configured firewalls are kept in bypass state using a global setting. Since ROM configured firewalls for certain peripherals, these will not be touched. So when bootloader touches any of the address space that ROM marked as in-accessible, system raises a firewall exception causing boot hang. It would have been ideal if sysfw cleans up the ROM configured boot peripheral firewalls. Given the memory overhead to store this information provided by ROM and the boot time increase in re configuring the firewalls, it is concluded to clean this up in bootloaders. So disable all the firewalls that ROM doesn't open up the full address space. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-03arm: mach-k3: Enable WA for R5F deadlockLokesh Vutla
On K3 devices there are 2 conditions where R5F can deadlock: 1.When software is performing series of store operations to cacheable write back/write allocate memory region and later on software execute barrier operation (DSB or DMB). R5F may hang at the barrier instruction. 2.When software is performing a mix of load and store operations within a tight loop and store operations are all writing to cacheable write back/write allocates memory regions, R5F may hang at one of the load instruction. To avoid the above two conditions disable linefill optimization inside Cortex R5F which will make R5F to only issue up to 2 cache line fills at any point of time. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11arm: k3: Add support for printing CPUINFOLokesh Vutla
Add support for printing CPU info for all K3 devices. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11arm: K3: common: Allow for early console functionalityAndreas Dannenberg
Implement an early console functionality in SPL that can be used before the main console is being brought up. This helps in situations where the main console is dependent on System Firmware (SYSFW) being up and running, which is usually not the case during the very early stages of boot. Using this early console functionality will allow for an alternate serial port to be used to support things like UART-based boot and early diagnostic messages until the main console is ready to get activated. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2018-11-16armv7R: K3: am654: Enable MPU regionsLokesh Vutla
Enable MPU regions for AM654 evm: - Region0: 0x00000000 - 0xFFFFFFFF: Device memory, not executable - Region1: 0x41c00000 - 0x42400000: Normal, executable, WB, Write alloc - Region2: 0x80000000 - 0xFFFFFFFF: Normal, executable, WB, Write alloc - region3-15: Disabled With this dcache can be enabled either in SPL or U-Boot. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>