Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-28 15:41:40 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/remoteproc/Makefile

19 lines
745 B
Makefile
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
# SPDX-License-Identifier: GPL-2.0+
drivers: Introduce a simplified remoteproc framework Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc. Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable. To address these needs, we need some minimal capability to load such a system and ensure it is started prior to an Operating System(Linux or any other) is started up. NOTE: This is NOT meant to be a solve-all solution, instead, it tries to address certain class of SoCs and products that need such a solution. A very simple model is introduced here as part of the initial support that supports microcontrollers with internal memory (no MMU, no execution from external memory, or specific image format needs). This basic framework can then (hopefully) be extensible to other complex SoC processor support as need be. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-09-17 20:42:39 +00:00
#
# (C) Copyright 2015
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
# Texas Instruments Incorporated - https://www.ti.com/
drivers: Introduce a simplified remoteproc framework Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc. Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable. To address these needs, we need some minimal capability to load such a system and ensure it is started prior to an Operating System(Linux or any other) is started up. NOTE: This is NOT meant to be a solve-all solution, instead, it tries to address certain class of SoCs and products that need such a solution. A very simple model is introduced here as part of the initial support that supports microcontrollers with internal memory (no MMU, no execution from external memory, or specific image format needs). This basic framework can then (hopefully) be extensible to other complex SoC processor support as need be. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-09-17 20:42:39 +00:00
#
remoteproc: add elf file load support The current implementation supports only binary file load. Add helpers to support ELF32 format (sanity check, and load). Note that since an ELF32 image is built for the remote processor, the load function uses the device_to_virt ops to translate the addresses. Implement a basic translation for sandbox_testproc. Add related tests. Test result: => ut dm remoteproc_elf Test: dm_test_remoteproc_elf: remoteproc.c Test: dm_test_remoteproc_elf: remoteproc.c (flat tree) Failures: 0 Signed-off-by: Loic Pallardy <loic.pallardy@st.com> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 13:11:33 +00:00
obj-$(CONFIG_$(SPL_)REMOTEPROC) += rproc-uclass.o rproc-elf-loader.o
remoteproc: Introduce a sandbox dummy driver Introduce a dummy driver for sandbox that allows us to verify basic functionality. This is not meant to do anything functional - but is more or less meant as a framework plumbing debug helper. The sandbox remoteproc driver maintains absolutey no states and is a simple driver which just is filled with empty hooks. Idea being to give an approximate idea to implement own remoteproc driver using this as a template. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-09-17 20:42:40 +00:00
# Remote proc drivers - Please keep this list alphabetically sorted.
remoteproc: Introduce K3 system controller K3 specific SoCs have a dedicated microcontroller for doing resource management. Any HLOS/firmware on compute clusters should load a firmware to this microcontroller before accessing any resource. Adding support for loading this firmware. After the K3 system controller got loaded with firmware and started up it sends out a boot notification message through the secure proxy facility using the TI SCI protocol. Intercept and receive this message through the rproc start operation which will need to get invoked explicitly after the firmware got loaded. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2018-08-27 10:27:51 +00:00
obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
remoteproc: Introduce a sandbox dummy driver Introduce a dummy driver for sandbox that allows us to verify basic functionality. This is not meant to do anything functional - but is more or less meant as a framework plumbing debug helper. The sandbox remoteproc driver maintains absolutey no states and is a simple driver which just is filled with empty hooks. Idea being to give an approximate idea to implement own remoteproc driver using this as a template. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-09-17 20:42:40 +00:00
obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
remoteproc: Introduce STM32 Cortex-M4 remoteproc driver This patch introduces support of Cortex-M4 remote processor for STM32 MCU and MPU families. Signed-off-by: Loic Pallardy <loic.pallardy@st.com> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-05-31 13:11:34 +00:00
obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
remoteproc: k3_rproc: Rename to ti_k3_arm64_rproc k3_rproc driver is specifically meant for controlling an arm64 core using TISCI protocol. So rename the driver, Kconfig symbol, compatible and functions accordingly. While at it drop this remoteproc selection for a53 defconfig. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-06-07 13:55:59 +00:00
obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
remoteproc: Introduce K3 C66 and C71 remoteproc driver Certain SoCs with K3 architecture have integrated a C66 Corepac DSP subsystem and an advanced C71 DSPs. Introduce a remoteproc driver that that does take care of loading an elf to any of the specified DSPs and start it. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
2019-09-04 10:31:36 +00:00
obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
remoteproc: Introduce K3 remoteproc driver for R5F subsystem SoCs with K3 architecture have an integrated Arm Cortex-R5F subsystem that is comprised of dual-core Arm Cortex-R5F processor cores. This R5 subsytem can be configured at boot time to be either run in a LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. This subsystem has each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - TCMA and TCMB. Add a remoteproc driver to support this subsystem to be able to load and boot the R5 cores primarily in LockStep mode or split mode. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com>
2019-09-04 10:31:34 +00:00
obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
remoteproc: Add support for TI power processor Many TI System on Chip (SoC) solutions do have a dedicated microcontroller for doing power management functionality. These include the AM335x, AM437x, Keystone K2G SoCs. The functionality provided by these microcontrollers and the communication mechanisms vary very widely. However, we are able to consolidate some basic functionality to be generic enough starting with K2G SoC family. Introduce a basic remote proc driver to support these microcontrollers. In fact, on SoCs starting with K2G, basic power management functions are primarily accessible for the High Level Operating Systems(HLOS) via these microcontroller solutions. Hence, having these started at a bootloader level is pretty much mandatory. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-25 18:53:45 +00:00
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem, commonly referred to as ICSSG. Each ICSSG processor subsystem on AM65x SR1.0 contains two primary PRU cores and two new auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. This IP instance has two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than a PRU), Control and debug feature sets, but is different in terms of sub-modules integrated around it and does not have the full capabilities associated with a PRU core. The RTU core is typically used to aid a PRU core in accelerating data transfers, while the Tx_PRU cores is normally used to control the TX L2 FIFO if enabled in Ethernet applications. Both can also be used to run independent applications. 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. The new cores also support a new sub-module called Task Manager to support two different context thread executions. The driver currently supports the AM65xx SoC Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210622063431.3151-3-lokeshvutla@ti.com
2021-06-22 06:34:28 +00:00
obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
remoteproc: ipu: Add driver to bring up ipu The driver enables IPU support. Basically enables the clocks, timers, watchdog timers and bare minimal MMU and supports loading the firmware from mmc. Signed-off-by: Keerthy <j-keerthy@ti.com> [Amjad: fix compile warnings] Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
2022-01-27 12:16:56 +00:00
obj-$(CONFIG_REMOTEPROC_TI_IPU) += ipu_rproc.o
Reference in a new issue Copy permalink