Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-16 16:23:14 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/mach-k3/Makefile

30 lines
1 KiB
Makefile
Raw Normal View History

arm: K3: Add support for AM654 SoC definition The AM654 device is designed for industrial automation and PLC controller class platforms among other applications. Introduce base support for AM654 SoC. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2018-08-27 10:27:09 +00:00
# SPDX-License-Identifier: GPL-2.0+
#
tree-wide: Replace http:// link with https:// link for ti.com Replace instances of http://www.ti.com with https://www.ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-11-01 20:56:03 +00:00
# Copyright (C) 2017-2018 Texas Instruments Incorporated - https://www.ti.com/
arm: K3: Add support for AM654 SoC definition The AM654 device is designed for industrial automation and PLC controller class platforms among other applications. Introduce base support for AM654 SoC. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2018-08-27 10:27:09 +00:00
# Lokesh Vutla <lokeshvutla@ti.com>
arm: mach-k3: Only build init files for SPL The content of these files are only used in SPL builds. The contents are already ifdef for the same, remove that and only include the whole file in the build when building for SPL. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-15 15:25:26 +00:00
obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/
obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
obj-$(CONFIG_SOC_K3_AM625) += am62x/
arm: mach-k3: introduce basic files to support the am62a Introduce the mach-k3 files needed to properly boot TI's am62a SoC family of devices Signed-off-by: Bryan Brattlof <bb@ti.com>
2022-11-04 00:13:55 +00:00
obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
armv8: K3: am654: Add custom MMU support Add MMU mappings for AM654 SoC. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-08-27 10:27:13 +00:00
obj-$(CONFIG_ARM64) += arm64-mmu.o
armv7r: K3: Allow SPL to run only on core 0 Based on the MCU R5 efuse settings, R5F cores in MCU domain either work in split mode or in lock step mode. If efuse settings are in lockstep mode: ROM release R5 cores and SPL continues to run on the R5 core is lockstep mode. If efuse settings are in split mode: ROM releases both the R5 cores simultaneously and allow SPL to run on both the cores. In this case it is bootloader's responsibility to detect core 1 and park it. Else both the core will be running bootloader independently which might result in an unexpected behaviour. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2018-11-15 05:34:50 +00:00
obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
arm: mach-k3: Clean non-coherent lines out of L3 cache When switching on or off the ARM caches some care must be taken to ensure existing cache line allocations are not left in an inconsistent state. An example of this is when cache lines are considered non-shared by and L3 controller even though the lines are shared. To prevent these and other issues all cache lines should be cleared before enabling or disabling a coherent master's cache. ARM cores and many L3 controllers provide a way to efficiently clean out all cache lines to allow for this, unfortunately there is no such easy way to do this on current K3 MSMC based systems. We could explicitly clean out every valid external address tracked by MSMC (all of DRAM), or we could attempt to identify only the set of addresses accessed by a given boot stage and flush only those specifically. This patch attempts the latter. We start with cleaning the SPL load address. More addresses can be added here later as they are identified. Note that we perform a flush operation for both the flush and invalidate operations, this is not a typo. We do this to avoid the situation that some ARM cores will promote an invalidate to a clean+invalidate, but only emit the invalidation operation externally, leading to a loss of data. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Faiz Abbas <faiz_abbas@ti.com>
2020-07-15 21:02:36 +00:00
obj-$(CONFIG_ARM64) += cache.o
arm: k3: Fix ft_system_setup so it can be enabled on any SoC ft_system_setup cannot be enabled on SoC without msmc sram otherwise fdt_fixup_msmc_ram function fails causing system reset. Fix by moving fdt_fixup_msmc_ram to common_fdt.c file and creating SoC (AM654, J721E and J721S2) specific files for fdt fixups. This change was verified to not change anything on any existing board (all the J721S2, AM654 and J721E boards requires it, none of the remaining k3 boards require it). Fixes: 30e96a240156 ("arm: mach-k3: Move MSMC fixup to SoC level") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-07-14 15:23:08 +00:00
obj-$(CONFIG_OF_LIBFDT) += common_fdt.o
ifeq ($(CONFIG_OF_LIBFDT)$(CONFIG_OF_SYSTEM_SETUP),yy)
obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o
obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
arm: mach-k3: am62: Fixup CPU core, gpu and pru nodes in fdt AM62x SoC is available in multiple variant: - CPU cores (Cortex-A) AM62x1 (1 core), AM62x2 (2 cores), AM62x4 (4 cores) - GPU AM625x with GPU, AM623x without GPU - PRU (Programmable RT unit) can be present or not on AM62x2/AM62x4 Remove the relevant FDT nodes by reading the actual configuration from the SoC registers, with that change is possible to have a single dts/dtb file handling the different variant at runtime. While removing GPU node and CPU nodes also the watchdog node in the same Module Domain is removed. A similar approach is implemented for example on i.MX8 and STM32MP1 SoC. Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-07-14 15:23:10 +00:00
obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
arm: k3: Fix ft_system_setup so it can be enabled on any SoC ft_system_setup cannot be enabled on SoC without msmc sram otherwise fdt_fixup_msmc_ram function fails causing system reset. Fix by moving fdt_fixup_msmc_ram to common_fdt.c file and creating SoC (AM654, J721E and J721S2) specific files for fdt fixups. This change was verified to not change anything on any existing board (all the J721S2, AM654 and J721E boards requires it, none of the remaining k3 boards require it). Fixes: 30e96a240156 ("arm: mach-k3: Move MSMC fixup to SoC level") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-07-14 15:23:08 +00:00
endif
arm: K3: Introduce System Firmware loader framework Introduce a framework that allows loading the System Firmware (SYSFW) binary as well as the associated configuration data from an image tree blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC RAW mode partition or sector. To simplify the handling of and loading from the different boot media we tap into the existing U-Boot SPL framework usually used for loading U-Boot by building on an earlier commit that exposes some of that functionality. Note that this initial implementation only supports FS and RAW-based eMMC/SD card boot. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 22:55:47 +00:00
ifeq ($(CONFIG_SPL_BUILD),y)
arm: mach-k3: Rename SOC_K3_AM6 to SOC_K3_AM654 The first AM6x device was the AM654x, but being the first we named it just AM6, since more devices have come out with this same prefix we should switch it to the normal convention of using the full name of the first compatibility device the series. This makes what device we are talking about more clear and matches all the K3 devices added since. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-15 15:25:27 +00:00
obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
arm: mach-k3: Only build init files for SPL The content of these files are only used in SPL builds. The contents are already ifdef for the same, remove that and only include the whole file in the build when building for SPL. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-15 15:25:26 +00:00
obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o
obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o
obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
obj-$(CONFIG_SOC_K3_AM625) += am625_init.o
arm: mach-k3: introduce basic files to support the am62a Introduce the mach-k3 files needed to properly boot TI's am62a SoC family of devices Signed-off-by: Bryan Brattlof <bb@ti.com>
2022-11-04 00:13:55 +00:00
obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o
arm: K3: Introduce System Firmware loader framework Introduce a framework that allows loading the System Firmware (SYSFW) binary as well as the associated configuration data from an image tree blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC RAW mode partition or sector. To simplify the handling of and loading from the different boot media we tap into the existing U-Boot SPL framework usually used for loading U-Boot by building on an earlier commit that exposes some of that functionality. Note that this initial implementation only supports FS and RAW-based eMMC/SD card boot. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-04 22:55:47 +00:00
obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
endif
arm: mach-k3: security: Bypass image signing at runtime for GP devices We can skip the image authentication check at runtime if the device is GP. This reduces the delta between GP and HS U-Boot builds. End goal is to re-unify the two build types into one build that can run on all device types. Signed-off-by: Andrew Davis <afd@ti.com>
2022-07-15 16:34:34 +00:00
obj-y += common.o security.o
Reference in a new issue Copy permalink