Commit Graph

12 Commits

Author SHA1 Message Date
Lokesh Vutla
ab827b3857 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-10-11 10:07:34 -04:00
Lokesh Vutla
4c850356a8 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-10-11 10:07:34 -04:00
Lokesh Vutla
54e4311fa1 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-07-26 21:49:25 -04:00
Fabien Dessenne
6bed04fbd4 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-07-22 09:21:28 +02:00
Fabien Dessenne
7a7c4cb0f0 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-07-22 09:21:28 +02:00
Lokesh Vutla
08c45314a8 spl: Allow remoteproc drivers to be used within SPL
Add an option for building remoteproc drivers within SPL.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
c365ed7d4b remoteproc: Introduce K3 remoteproc driver
Add support for K3 based remoteproc driver that
communicates with TISCI to start start a remote processor.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
1ad190bf59 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-09-11 08:32:55 -04:00
Tom Rini
83d290c56f 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-07 09:34:12 -04:00
Nishanth Menon
4239284973 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-03-14 19:18:37 -04:00
Nishanth Menon
3df0b8b4da 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-10-22 14:18:39 -04:00
Nishanth Menon
ddf56bc7e3 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-10-22 14:18:38 -04:00