brain-hackers_pepepper-mirror
/
u-boot-brain
mirror of https://github.com/brain-hackers/u-boot-brain
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
u-boot-brain/include/remoteproc.h

367 lines
12 KiB
C
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-07 06:58:06 +09: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-18 05:42:39 +09:00
/*
* (C) Copyright 2015
* Texas Instruments Incorporated - http://www.ti.com/
*/
#ifndef _RPROC_H_
#define _RPROC_H_
/*
* Note: The platform data support is not meant for use with newer
* platforms. This is meant only for legacy devices. This mode of
* initialization *will* be eventually removed once all necessary
* platforms have moved to dm/fdt.
*/
#include <dm/platdata.h> /* For platform data support - non dt world */
/**
* enum rproc_mem_type - What type of memory model does the rproc use
* @RPROC_INTERNAL_MEMORY_MAPPED: Remote processor uses own memory and is memory
* mapped to the host processor over an address range.
*
* Please note that this is an enumeration of memory model of different types
* of remote processors. Few of the remote processors do have own internal
* memories, while others use external memory for instruction and data.
*/
enum rproc_mem_type {
RPROC_INTERNAL_MEMORY_MAPPED = 0,
};
/**
* struct dm_rproc_uclass_pdata - platform data for a CPU
* @name: Platform-specific way of naming the Remote proc
* @mem_type: one of 'enum rproc_mem_type'
* @driver_plat_data: driver specific platform data that may be needed.
*
dm: treewide: Rename 'platdata' variables to just 'plat' We use 'priv' for private data but often use 'platdata' for platform data. We can't really use 'pdata' since that is ambiguous (it could mean private or platform data). Rename some of the latter variables to end with 'plat' for consistency. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-04 08:55:18 +09:00
* This can be accessed with dev_get_uclass_plat() for any UCLASS_REMOTEPROC
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-18 05:42:39 +09:00
* device.
*
*/
struct dm_rproc_uclass_pdata {
const char *name;
enum rproc_mem_type mem_type;
void *driver_plat_data;
};
/**
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* struct dm_rproc_ops - Driver model remote proc operations.
*
* This defines the operations provided by remote proc driver.
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-18 05:42:39 +09:00
*/
struct dm_rproc_ops {
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
/**
* init() - Initialize the remoteproc device (optional)
*
* This is called after the probe is completed allowing the remote
* processor drivers to split up the initializations between probe and
* init if needed.
*
* @dev: Remote proc device
* @return 0 if all ok, else appropriate error value.
*/
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-18 05:42:39 +09:00
int (*init)(struct udevice *dev);
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
/**
* load() - Load the remoteproc device using data provided (mandatory)
*
* Load the remoteproc device with an image, do not start the device.
*
* @dev: Remote proc device
* @addr: Address of the image to be loaded
* @size: Size of the image to be loaded
* @return 0 if all ok, else appropriate error value.
*/
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-18 05:42:39 +09:00
int (*load)(struct udevice *dev, ulong addr, ulong size);
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
/**
* start() - Start the remoteproc device (mandatory)
*
* @dev: Remote proc device
* @return 0 if all ok, else appropriate error value.
*/
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-18 05:42:39 +09:00
int (*start)(struct udevice *dev);
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
/**
* stop() - Stop the remoteproc device (optional)
*
* @dev: Remote proc device
* @return 0 if all ok, else appropriate error value.
*/
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-18 05:42:39 +09:00
int (*stop)(struct udevice *dev);
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
/**
* reset() - Reset the remoteproc device (optional)
*
* @dev: Remote proc device
* @return 0 if all ok, else appropriate error value.
*/
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-18 05:42:39 +09:00
int (*reset)(struct udevice *dev);
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
/**
* is_running() - Check if the remote processor is running (optional)
*
* @dev: Remote proc device
* @return 0 if running, 1 if not running, -ve on error.
*/
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-18 05:42:39 +09:00
int (*is_running)(struct udevice *dev);
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
/**
* ping() - Ping the remote device for basic communication (optional)
*
* @dev: Remote proc device
* @return 0 on success, 1 if not responding, -ve on other errors.
*/
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-18 05:42:39 +09:00
int (*ping)(struct udevice *dev);
remoteproc: add device_to_virt ops Introduce the device_to_virt function to allow translation between device address (remote processor view) and virtual address (main processor view). 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 22:11:32 +09:00
/**
* device_to_virt() - Return translated virtual address (optional)
*
* Translate a device address (remote processor view) to virtual
* address (main processor view).
*
* @dev: Remote proc device
* @da: Device address
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-09-04 19:31:27 +09:00
* @size: Size of the memory region @da is pointing to
remoteproc: add device_to_virt ops Introduce the device_to_virt function to allow translation between device address (remote processor view) and virtual address (main processor view). 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 22:11:32 +09:00
* @return virtual address.
*/
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-09-04 19:31:27 +09:00
void * (*device_to_virt)(struct udevice *dev, ulong da, ulong size);
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-18 05:42:39 +09:00
};
/* Accessor */
#define rproc_get_ops(dev) ((struct dm_rproc_ops *)(dev)->driver->ops)
remoteproc: Fix potential build issues with SPL remoteproc The rproc uclass driver can either be built with SPL_REMOTEPROC or REMOTEPROC, but the function prototypes in remoteproc.h are defined only when CONFIG_REMOTEPROC is defined. This can cause build issues in SPL if CONFIG_REMOTEPROC is not selected. Fix this by replacing the existing precompiler macro usage with CONFIG_IS_ENABLED. Fixes: ddf56bc7e3ef ("drivers: Introduce a simplified remoteproc framework") Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-20 00:27:56 +09:00
#if CONFIG_IS_ENABLED(REMOTEPROC)
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-18 05:42:39 +09:00
/**
* rproc_init() - Initialize all bound remote proc devices
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if all ok, else appropriate error value.
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-18 05:42:39 +09:00
*/
int rproc_init(void);
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-08-27 19:27:50 +09:00
/**
* rproc_dev_init() - Initialize a remote proc device based on id
* @id: id of the remote processor
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if all ok, else appropriate error value.
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-08-27 19:27:50 +09:00
*/
int rproc_dev_init(int id);
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-18 05:42:39 +09:00
/**
* rproc_is_initialized() - check to see if remoteproc devices are initialized
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return true if all devices are initialized, false otherwise.
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-18 05:42:39 +09:00
*/
bool rproc_is_initialized(void);
/**
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 22:11:33 +09:00
* rproc_load() - load binary or elf to a remote processor
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-18 05:42:39 +09:00
* @id: id of the remote processor
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 22:11:33 +09:00
* @addr: address in memory where the image is located
* @size: size of the image
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if all ok, else appropriate error value.
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-18 05:42:39 +09:00
*/
int rproc_load(int id, ulong addr, ulong size);
/**
* rproc_start() - Start a remote processor
* @id: id of the remote processor
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if all ok, else appropriate error value.
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-18 05:42:39 +09:00
*/
int rproc_start(int id);
/**
* rproc_stop() - Stop a remote processor
* @id: id of the remote processor
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if all ok, else appropriate error value.
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-18 05:42:39 +09:00
*/
int rproc_stop(int id);
/**
* rproc_reset() - reset a remote processor
* @id: id of the remote processor
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if all ok, else appropriate error value.
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-18 05:42:39 +09:00
*/
int rproc_reset(int id);
/**
* rproc_ping() - ping a remote processor to check if it can communicate
* @id: id of the remote processor
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if all ok, else appropriate error value.
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-18 05:42:39 +09:00
*
* NOTE: this might need communication path available, which is not implemented
* as part of remoteproc framework - hook on to appropriate bus architecture to
* do the same
*/
int rproc_ping(int id);
/**
* rproc_is_running() - check to see if remote processor is running
* @id: id of the remote processor
remoteproc: fix function headers Add full function comment headers. Fix rproc_is_initialized() return value description. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-31 22:11:31 +09:00
* @return 0 if running, 1 if not running, -ve on error.
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-18 05:42:39 +09:00
*
* NOTE: this may not involve actual communication capability of the remote
* processor, but just ensures that it is out of reset and executing code.
*/
int rproc_is_running(int id);
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 22:11:33 +09:00
/**
* rproc_elf32_sanity_check() - Verify if an image is a valid ELF32 one
*
* Check if a valid ELF32 image exists at the given memory location. Verify
* basic ELF32 format requirements like magic number and sections size.
*
* @addr: address of the image to verify
* @size: size of the image
* @return 0 if the image looks good, else appropriate error value.
*/
int rproc_elf32_sanity_check(ulong addr, ulong size);
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-09-04 19:31:29 +09:00
/**
* rproc_elf64_sanity_check() - Verify if an image is a valid ELF32 one
*
* Check if a valid ELF64 image exists at the given memory location. Verify
* basic ELF64 format requirements like magic number and sections size.
*
* @addr: address of the image to verify
* @size: size of the image
* @return 0 if the image looks good, else appropriate error value.
*/
int rproc_elf64_sanity_check(ulong addr, ulong size);
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 22:11:33 +09:00
/**
* rproc_elf32_load_image() - load an ELF32 image
* @dev: device loading the ELF32 image
* @addr: valid ELF32 image address
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-09-04 19:31:28 +09:00
* @size: size of the image
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 22:11:33 +09:00
* @return 0 if the image is successfully loaded, else appropriate error value.
*/
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-09-04 19:31:28 +09:00
int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size);
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-09-04 19:31:29 +09:00
/**
* rproc_elf64_load_image() - load an ELF64 image
* @dev: device loading the ELF64 image
* @addr: valid ELF64 image address
* @size: size of the image
* @return 0 if the image is successfully loaded, else appropriate error value.
*/
int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
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-09-04 19:31:30 +09:00
/**
* rproc_elf_load_image() - load an ELF image
* @dev: device loading the ELF image
* @addr: valid ELF image address
* @size: size of the image
*
* Auto detects if the image is ELF32 or ELF64 image and load accordingly.
* @return 0 if the image is successfully loaded, else appropriate error value.
*/
int rproc_elf_load_image(struct udevice *dev, unsigned long addr, ulong size);
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-09-04 19:31:31 +09:00
/**
* rproc_elf_get_boot_addr() - Get rproc's boot address.
* @dev: device loading the ELF image
* @addr: valid ELF image address
*
* This function returns the entry point address of the ELF
* image.
*/
ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr);
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>
2019-10-30 22:38:28 +09:00
/**
* rproc_elf32_load_rsc_table() - load the resource table from an ELF32 image
*
* Search for the resource table in an ELF32 image, and if found, copy it to
* device memory.
*
* @dev: device loading the resource table
* @fw_addr: ELF image address
* @fw_size: size of the ELF image
* @rsc_addr: pointer to the found resource table address. Updated on
* operation success
* @rsc_size: pointer to the found resource table size. Updated on operation
* success
*
* @return 0 if a valid resource table is successfully loaded, -ENODATA if there
* is no resource table (which is optional), or another appropriate error value.
*/
int rproc_elf32_load_rsc_table(struct udevice *dev, ulong fw_addr,
ulong fw_size, ulong *rsc_addr, ulong *rsc_size);
/**
* rproc_elf64_load_rsc_table() - load the resource table from an ELF64 image
*
* Search for the resource table in an ELF64 image, and if found, copy it to
* device memory.
*
* @dev: device loading the resource table
* @fw_addr: ELF image address
* @fw_size: size of the ELF image
* @rsc_addr: pointer to the found resource table address. Updated on
* operation success
* @rsc_size: pointer to the found resource table size. Updated on operation
* success
*
* @return 0 if a valid resource table is successfully loaded, -ENODATA if there
* is no resource table (which is optional), or another appropriate error value.
*/
int rproc_elf64_load_rsc_table(struct udevice *dev, ulong fw_addr,
ulong fw_size, ulong *rsc_addr, ulong *rsc_size);
/**
* rproc_elf_load_rsc_table() - load the resource table from an ELF image
*
* Auto detects if the image is ELF32 or ELF64 image and search accordingly for
* the resource table, and if found, copy it to device memory.
*
* @dev: device loading the resource table
* @fw_addr: ELF image address
* @fw_size: size of the ELF image
* @rsc_addr: pointer to the found resource table address. Updated on
* operation success
* @rsc_size: pointer to the found resource table size. Updated on operation
* success
*
* @return 0 if a valid resource table is successfully loaded, -ENODATA if there
* is no resource table (which is optional), or another appropriate error value.
*/
int rproc_elf_load_rsc_table(struct udevice *dev, ulong fw_addr,
ulong fw_size, ulong *rsc_addr, ulong *rsc_size);
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-18 05:42:39 +09:00
#else
static inline int rproc_init(void) { return -ENOSYS; }
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-08-27 19:27:50 +09:00
static inline int rproc_dev_init(int id) { return -ENOSYS; }
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-18 05:42:39 +09:00
static inline bool rproc_is_initialized(void) { return false; }
static inline int rproc_load(int id, ulong addr, ulong size) { return -ENOSYS; }
static inline int rproc_start(int id) { return -ENOSYS; }
static inline int rproc_stop(int id) { return -ENOSYS; }
static inline int rproc_reset(int id) { return -ENOSYS; }
static inline int rproc_ping(int id) { return -ENOSYS; }
static inline int rproc_is_running(int id) { return -ENOSYS; }
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 22:11:33 +09:00
static inline int rproc_elf32_sanity_check(ulong addr,
ulong size) { return -ENOSYS; }
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-09-04 19:31:29 +09:00
static inline int rproc_elf64_sanity_check(ulong addr,
ulong size) { return -ENOSYS; }
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-09-04 19:31:30 +09:00
static inline int rproc_elf_sanity_check(ulong addr,
ulong size) { return -ENOSYS; }
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 22:11:33 +09:00
static inline int rproc_elf32_load_image(struct udevice *dev,
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-09-04 19:31:28 +09:00
unsigned long addr, ulong size)
{ return -ENOSYS; }
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-09-04 19:31:29 +09:00
static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
ulong size)
{ return -ENOSYS; }
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-09-04 19:31:30 +09:00
static inline int rproc_elf_load_image(struct udevice *dev, ulong addr,
ulong size)
{ return -ENOSYS; }
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-09-04 19:31:31 +09:00
static inline ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr)
{ return 0; }
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>
2019-10-30 22:38:28 +09:00
static inline int rproc_elf32_load_rsc_table(struct udevice *dev, ulong fw_addr,
ulong fw_size, ulong *rsc_addr,
ulong *rsc_size)
{ return -ENOSYS; }
static inline int rproc_elf64_load_rsc_table(struct udevice *dev, ulong fw_addr,
ulong fw_size, ulong *rsc_addr,
ulong *rsc_size)
{ return -ENOSYS; }
static inline int rproc_elf_load_rsc_table(struct udevice *dev, ulong fw_addr,
ulong fw_size, ulong *rsc_addr,
ulong *rsc_size)
{ return -ENOSYS; }
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-18 05:42:39 +09:00
#endif
#endif /* _RPROC_H_ */