Commit Graph

38 Commits

Author SHA1 Message Date
Suman Anna
445b45042c remoteproc: k3-r5: Fix rproc init failure on Split-mode _only_ devices
The R5F subsystem/cluster on K3 SoCs can support both LockStep and
Split-modes (superset) or just Split-mode depending on an eFUSE
capability register. The LockStep configuration bit is Read-only
though on Split-mode _only_ devices and as such the System Firmware
does not allow the LockStep mode bit to be configured on such devices.
The current logic in k3_r5f_rproc_configure() fails on Split-mode
devices because of this unconditional programming of the LockStep
mode bit, and results in the probe failure shown during the
"rproc init" step at U-Boot prompt.

Fix this by limiting the LockStep mode bit clear configuration only on
devices supporting both LockStep/Split-modes.

Fixes: 4c850356a8 ("remoteproc: Introduce K3 remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-03-16 12:33:19 +05:30
Suman Anna
0438a0a181 remoteproc: k3-r5: Fix rproc init failure for Main R5FSS0
The Main R5FSS0 cluster is also enabled to probe the R5F remoteproc
driver within R5 SPL for booting the Core0 very early. This results
in a ti_sci_power_domain_on failure during the probe from the A72
U-Boot when "rproc init" is executed at U-Boot prompt, and doesn't
enumerate all the rproc devices.

Fix this by suppressing the power_domain_on altogether using the
flag DM_FLAG_DEFAULT_PD_CTRL_OFF added in commit af94ad418d
("dm: core: Allow for not controlling the power-domain by DM framework").

Fixes: fac6aa817a ("configs: j721e_evm_r5: Enable R5F remoteproc support")
Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16 12:33:03 +05:30
Suman Anna
42005817ee remoteproc: k3-dsp: Add support for L2RAM loading on C66x DSPs
The resets for the DSP processors on K3 SoCs are managed through the
Power and Sleep Controller (PSC) module. Each DSP typically has two
resets - a global module reset for powering on the device, and a local
reset that affects only the CPU while allowing access to the other
sub-modules within the DSP processor sub-systems.

The C66x DSPs have two levels of internal RAMs that can be used to
boot from, and the firmware loading into these RAMs require the
local reset to be asserted with the device powered on/enabled using
the module reset. Enhance the K3 DSP remoteproc driver to add support
for loading into the internal RAMs. The local reset is deasserted on
SoC power-on-reset, so logic has to be added in probe in remoteproc
mode to balance the remoteproc state-machine.

Note that the local resets are a no-op on C71x cores, and the hardware
does not supporting loading into its internal RAMs.

Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16 12:32:47 +05:30
Suman Anna
1e53d5b585 remoteproc: k3-dsp: Add a sanity check for DSP boot address alignment
The DSP remote processors on K3 SoCs require a boot register to be
programmed with a boot address, and these boot addresses need to be
aligned on certain address boundaries. The current code does not have
any error checks, and relies on the System Firmware to perform the
checking. Add logic to perform this sanity check within the remoteproc
driver itself to detect these anomalies specifically, and print a
meaningful trace. This avoids the cumbersome debug of root-causing
such failures from the corresponding TI-SCI failure.

The C66x and C71x DSP cores have different alignment needs and are
as follows:
	C66x DSP = 1 KB (0x400)
	C71x DSP = 2 MB (0x200000)

Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16 12:32:47 +05:30
Suman Anna
0020003ef3 remoteproc: k3-dsp: Fix unbalanced state machine in k3_dsp_start
The global module reset is deasserted through the ti_sci_power_domain_on()
call in k3_dsp_start(), but is not asserted back if the local module reset
fails. Fix this.

While at this, remove the stale comment about assigned-clock-rates that
seems to have been copied from the K3 ARM64 Remoteproc driver.

Fixes: ab827b3857 ("remoteproc: Introduce K3 C66 and C71 remoteproc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16 12:32:47 +05:30
Simon Glass
336d4615f8 dm: core: Create a new header file for 'compat' features
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05 19:33:46 -07:00
Simon Glass
61b29b8268 dm: core: Require users of devres to include the header
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
2020-02-05 19:33:46 -07:00
Fabien Dessenne
83b539cfd4 remoteproc: elf_loader: fix program header parsing
Fix an issue where some sections are never loaded : if p_type is
different from PT_LOAD the phdr pointer must be incremented.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Suman Anna <s-anna@ti.com>
2020-01-24 11:19:52 -05:00
Fabien Dessenne
33fd41951a remoteproc: stm32: load resource table from firmware
Load the optional resource table from the firmware, and write its
address in the dedicated backup register.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-07 11:13:25 -05:00
Fabien Dessenne
4a4deb870f remoteproc: stm32: track the coprocessor state in a backup register
Update the dedicated backup register to track the coprocessor state and
rely on that register to compute the .is_running() value (which expects
a return value of 0 -not 1- if the processor is running).

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-07 11:13:25 -05:00
Fabien Dessenne
ffcb880de8 remoteproc: elf_loader: Add elf resource table load support
Add rproc_elf_load_rsc_table(), which searches for a resource table in
an elf64/elf32 image, and if found, copies it to device memory.
Add also the elf32 and elf64 variants of this API.
Add a test for this.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-07 11:13:25 -05:00
Simon Glass
1eb69ae498 common: Move ARM cache operations out of common.h
These functions are CPU-related and do not use driver model. Move them to
cpu_func.h

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2019-12-02 18:24:58 -05:00
Lokesh Vutla
af17b0dad5 remoteproc: k3_arm64: Enable DM_FLAG_DEFAULT_PD_CTRL_OFF
Enable DM_FLAG_DEFAULT_PD_CTRL_OFF for arm64 remote core so that
pd can be enabled after loading the image.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2019-10-15 08:40:03 -06:00
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
f7954828b8 remoteproc: tisci_proc: Add helper api for controlling core power domain
Power domain for the remote cores needs to be handled in a right
sequence as mandated by the spec. Introduce tisci helper apis
that can control power-domains of remote cores. TISCI clients
can use this api and control the remote cores power domain instead
of hooking it to power-domain layer.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
81e39fbd92 remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api
Introduce rproc_elf_get_boot_addr() that returns the entry point of
the elf file. This api auto detects the 64/32 bit elf file and returns
the boot addr accordingly.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
856c0ad413 remoteproc: elf_loader: Introduce a common elf loader and checker functions
Introduce a common remoteproc elf loader and checker functions that
automatically detects the 64 bit elf file or 32 bit elf file and
loads/checks the sections accordingly.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
e3c4d6f01f remoteproc: elf-loader: Add 64 bit elf loading support
The current rproc-elf-loader supports loading of only 32 bit elf files.
Introduce support for loading of 64 bit elf files in rproc-elf-loader.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
14d963d1b5 remoteproc: elf_loader: Always check the validity of the image before loading
rproc_elf32_load_image() rely on user to send a valid address for elf loading.
Instead do a sanity check on the address passed by user. This will help
all rproc elf users to not call sanity_check explicitly before calling
elf_loading.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
c08eb93626 remoteproc: ops: Add elf section size as input parameter to device_to_virt api
Introduce a new parameter "size" that accepts size of the region to
remoteproc ops callback device_to_virt(). This can enforce more checks
on the region that device_to_virt() is dealing with.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:33 -04:00
Patrick Delaunay
5d2901a4b6 stm32mp1: Add remoteproc support for m4 coprocessor
Alignment with kernel patch proposal for binding:

[PATCH v4 0/8] stm32 m4 remoteproc on STM32MP157c
https://lkml.org/lkml/2019/5/14/159

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-08-27 11:19:23 +02: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
Lokesh Vutla
44de37a00e remoteproc: k3_rproc: Update the driver to use ti_sci_proc helpers
Update the k3_rproc driver to use the generic ti_sci_proc helper
apis which simplifies the driver a bit.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-26 21:49:25 -04:00
Lokesh Vutla
4fa23ebe73 remoteproc: tisci: add TI-SCI processor control helper functions
Texas Instruments' K3 generation SoCs has specific modules/register
spaces used for configuring the various aspects of a remote processor.
These include power, reset, boot vector and other configuration features
specific to each compute processor present on the SoC. These registers
are managed by the System Controller such as DMSC on K3 AM65x SoCs.

The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used to communicate to the System Controller from various compute
processors to invoke specific services provided by the firmware running
on the System Controller.

Add a common processor control interface header file that can be used by
multiple remoteproc drivers. The helper functions within this header file
abstract the various TI SCI protocol ops for the remoteproc drivers, and
allow them to request the System Controller to be able to program and
manage various remote processors on the SoC. The common macros required
by the R5 remoteproc driver were also added. The remoteproc drivers are
expected to manage the life-cycle of their ti_sci_proc_dev local
structures.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-07-26 21:49:24 -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
0d7b6cffa5 remoteproc: k3_system_controller: Increase rx timeout
There is one case where 400ms is not sufficient for loading the
system firmware:
- System firmware is not signed with rsa degenerate key.
- ROM loading the sysfw directly from SPI flash which is in memory
  mapped mode.

The above scenario is definitely not desired in production use cases
as it effects boot time. But still keeping this support as this is
a valid boot scenario.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-09 20:22:05 -04: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
Lokesh Vutla
81ae6e6d00 remoteproc: Allow for individual remoteproc initialization
Existing rproc_init() api tries to initialize all available
remoteproc devices. This will fail when there is dependency
among available remoteprocs. So introduce a separate api
that allows to initialize remoteprocs individually based
on id.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.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
Simon Glass
e160f7d430 dm: core: Replace of_offset with accessor
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-02-08 06:12:14 -07: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
9cb05a8f9f drivers: remoteproc: rproc-uclass: Fix check for NULL pointers
Neither uc_pdata->name nor check_name are supposed to be NULL in
_rproc_name_is_unique(). if uc_pdata->name is NULL, we are not
intialized yet, however if check_data is NULL, we do not have
proper data. Further, if either were NULL, strlen will crap out
while attempting to derefence NULL.

Instead, just check if either of these are NULL and bail out.

This should also fix the following coverity scan warnings:
*** CID 132281:  Null pointer dereferences  (FORWARD_NULL)
/drivers/remoteproc/rproc-uclass.c: 73 in _rproc_name_is_unique()

Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
2015-12-05 18:22:32 -05: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