Giter Site home page Giter Site logo

openamp / open-amp Goto Github PK

View Code? Open in Web Editor NEW
654.0 82.0 272.0 11.23 MB

The main OpenAMP library implementing RPMSG, Virtio, and Remoteproc for RTOS etc

Home Page: https://www.openampproject.org/

License: Other

C 66.22% CMake 4.64% Perl 25.99% Shell 0.13% Python 3.03%

open-amp's Introduction

open-amp

This repository is the home for the Open Asymmetric Multi Processing (OpenAMP) framework project. The OpenAMP framework provides software components that enable development of software applications for Asymmetric Multiprocessing (AMP) systems. The framework provides the following key capabilities.

  1. Provides Life Cycle Management, and Inter Processor Communication capabilities for management of remote compute resources and their associated software contexts.
  2. Provides a stand alone library usable with RTOS and Baremetal software environments
  3. Compatibility with upstream Linux remoteproc and rpmsg components
  4. Following AMP configurations supported a. Linux host/Generic(Baremetal) remote b. Generic(Baremetal) host/Linux remote
  5. Proxy infrastructure and supplied demos showcase ability of proxy on host to handle printf, scanf, open, close, read, write calls from Bare metal based remote contexts.

OpenAMP Source Structure

|- lib/
|  |- virtio/     # virtio implementation
|  |- rpmsg/      # rpmsg implementation
|  |- remoteproc/ # remoteproc implementation
|  |- proxy/      # implement one processor access device on the
|  |              # other processor with file operations
|- apps/        # demonstration/testing applications
|  |- examples/ # Application samples using the OpenAMP framework.
|  |- machine/  # common files for machine can be shared by applications
|  |            # It is up to each app to decide whether to use these files.
|  |- system/   # common files for system can be shared by applications
|               # It is up to each app to decide whether to use these files.
|- cmake        # CMake files
|- script       # helper scripts (such as checkpatch) for contributors.

OpenAMP library libopen_amp is composed of the following directories in lib/:

  • virtio/
  • rpmsg/
  • remoteproc/
  • proxy/

OpenAMP system/machine support has been moved to libmetal, the system/machine layer in the apps/ directory is for system application initialization, and resource table definition.

libmetal APIs used in OpenAMP

Here are the libmetal APIs used by OpenAMP, if you want to port OpenAMP for your system, you will need to implement the following libmetal APIs in the libmetal's lib/system/<SYS> directory:

  • alloc, for memory allocation and memory free
  • cache, for flushing cache and invalidating cache
  • io, for memory mapping. OpenAMP required memory mapping in order to access vrings and carved out memory.
  • irq, for IRQ handler registration, IRQ disable/enable and global IRQ handling.
  • mutex
  • shmem (For RTOS, you can usually use the implementation from lib/system/generic/)
  • sleep, at the moment, OpenAMP only requires microseconds sleep as when OpenAMP fails to get a buffer to send messages, it will call this function to sleep and then try again.
  • time, for timestamp
  • init, for libmetal initialization.
  • atomic

Please refer to lib/system/generic when you port libmetal for your system.

If you a different compiler to GNU gcc, please refer to lib/compiler/gcc/ to port libmetal for your compiler. At the moment, OpenAMP needs the atomic operations defined in lib/compiler/gcc/atomic.h.

OpenAMP Compilation

OpenAMP uses CMake for library and demonstration application compilation. OpenAMP requires libmetal library. For now, you will need to download and compile libmetal library separately before you compiling OpenAMP library. In future, we will try to make libmetal as a submodule to OpenAMP to make this flow easier.

Some Cmake options are available to allow user to customize to the OpenAMP library for it project:

  • WITH_PROXY (default OFF): Include proxy support in the library.
  • WITH APPS (default OFF): Build with sample applications.
  • WITH_PROXY_APPS (default OFF):Build with proxy sample applications.
  • WITH_VIRTIO_DRIVER (default ON): Build with virtio driver enabled. This option can be set to OFF if the only the remote mode is implemented.
  • WITH_VIRTIO_DEVICE (default ON): Build with virtio device enabled. This option can be set to OFF if the only the driver mode is implemented.
  • WITH_STATIC_LIB (default ON): Build with a static library.
  • WITH_SHARED_LIB (default ON): Build with a shared library.
  • WITH_ZEPHYR (default OFF): Build open-amp as a zephyr library. This option is mandatory in a Zephyr environment.
  • WITH_DCACHE_VRINGS (default OFF): Build with data cache operations enabled on vrings.
  • WITH_DCACHE_BUFFERS (default OFF): Build with data cache operations enabled on buffers.
  • WITH_DCACHE_RSC_TABLE (default OFF): Build with data cache operations enabled on resource table.
  • WITH_DCACHE (default OFF): Build with all cache operations enabled. When set to ON, cache operations for vrings, buffers and resource table are enabled.
  • RPMSG_BUFFER_SIZE (default 512): adjust the size of the RPMsg buffers. The default value of the RPMsg size is compatible with the Linux Kernel hard coded value. If you AMP configuration is Linux kernel host/ OpenAMP remote, this option must not be used.

Example to compile OpenAMP for Zephyr

The Zephyr open-amp repo implements the open-amp library for the Zephyr project. It is mainly a fork of this repository, with some add-ons for integration in the Zephyr project. The standard way to compile OpenAMP for a Zephyr project is to use Zephyr build environment. Please refer to Zephyr OpenAMP samples for examples and Zephyr documentation for the build process.

Example to compile OpenAMP for communication between Linux processes:

  • Install libsysfs devel and libhugetlbfs devel packages on your Linux host.

  • build libmetal library on your host as follows:

        $ mkdir -p build-libmetal
        $ cd build-libmetal
        $ cmake <libmetal_source>
        $ make VERBOSE=1 DESTDIR=<libmetal_install> install
    
  • build OpenAMP library on your host as follows:

      $ mkdir -p build-openamp
      $ cd build-openamp
      $ cmake <openamp_source> -DCMAKE_INCLUDE_PATH=<libmetal_built_include_dir> \
            -DCMAKE_LIBRARY_PATH=<libmetal_built_lib_dir> [-DWITH_APPS=ON]
      $ make VERBOSE=1 DESTDIR=$(pwd) install
    

The OpenAMP library will be generated to build/usr/local/lib directory, headers will be generated to build/usr/local/include directory, and the applications executable will be generated to build/usr/local/bin directory.

  • cmake option -DWITH_APPS=ON is to build the demonstration applications.

  • If you have used -DWITH_APPS=ON to build the demos, you can try them on your Linux host as follows:

    • rpmsg echo demo:

      # Start echo test server to wait for message to echo
      $ sudo LD_LIBRARY_PATH=<openamp_built>/usr/local/lib:<libmetal_built>/usr/local/lib \
         build/usr/local/bin/rpmsg-echo-shared
      # Run echo test to send message to echo test server
      $ sudo LD_LIBRARY_PATH=<openamp_built>/usr/local/lib:<libmetal_built>/usr/local/lib \
         build/usr/local/bin/rpmsg-echo-ping-shared 1
      
    • rpmsg echo demo with the nocopy API:

      # Start echo test server to wait for message to echo
      $ sudo LD_LIBRARY_PATH=<openamp_built>/usr/local/lib:<libmetal_built>/usr/local/lib \
         build/usr/local/bin/rpmsg-nocopy-echo-shared
      # Run echo test to send message to echo test server
      $ sudo LD_LIBRARY_PATH=<openamp_built>/usr/local/lib:<libmetal_built>/usr/local/lib \
         build/usr/local/bin/rpmsg-nocopy-ping-shared 1
      

Example to compile Zynq UltraScale+ MPSoC R5 generic(baremetal) remote:

  • build libmetal library on your host as follows:

    • Create your on cmake toolchain file to compile libmetal for your generic (baremetal) platform. Here is the example of the toolchain file:

          set (CMAKE_SYSTEM_PROCESSOR "arm"              CACHE STRING "")
          set (MACHINE "zynqmp_r5" CACHE STRING "")
      
          set (CROSS_PREFIX           "armr5-none-eabi-" CACHE STRING "")
          set (CMAKE_C_FLAGS          "-mfloat-abi=soft -mcpu=cortex-r5 -Wall -Werror -Wextra \
             -flto -Os -I/ws/xsdk/r5_0_bsp/psu_cortexr5_0/include" CACHE STRING "")
      
          SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -flto")
          SET(CMAKE_AR  "gcc-ar" CACHE STRING "")
          SET(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> qcs <TARGET> <LINK_FLAGS> <OBJECTS>")
          SET(CMAKE_C_ARCHIVE_FINISH   true)
      
          include (cross-generic-gcc)
      
    • Compile libmetal library:

          $ mkdir -p build-libmetal
          $ cd build-libmetal
          $ cmake <libmetal_source> -DCMAKE_TOOLCHAIN_FILE=<toolchain_file>
          $ make VERBOSE=1 DESTDIR=<libmetal_install> install
      
  • build OpenAMP library on your host as follows:

    • Create your on cmake toolchain file to compile openamp for your generic (baremetal) platform. Here is the example of the toolchain file:

          set (CMAKE_SYSTEM_PROCESSOR "arm" CACHE STRING "")
          set (MACHINE                "zynqmp_r5" CACHE STRING "")
          set (CROSS_PREFIX           "armr5-none-eabi-" CACHE STRING "")
          set (CMAKE_C_FLAGS          "-mfloat-abi=soft -mcpu=cortex-r5 -Os -flto \
            -I/ws/libmetal-r5-generic/usr/local/include \
            -I/ws/xsdk/r5_0_bsp/psu_cortexr5_0/include" CACHE STRING "")
          set (CMAKE_ASM_FLAGS        "-mfloat-abi=soft -mcpu=cortex-r5" CACHE STRING "")
          set (PLATFORM_LIB_DEPS      "-lxil -lc -lm" CACHE STRING "")
          SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -flto")
          SET(CMAKE_AR  "gcc-ar" CACHE STRING "")
          SET(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> qcs <TARGET> <LINK_FLAGS> <OBJECTS>")
          SET(CMAKE_C_ARCHIVE_FINISH   true)
          set (CMAKE_FIND_ROOT_PATH /ws/libmetal-r5-generic/usr/local/lib \
              /ws/xsdk/r5_bsp/psu_cortexr5_0/lib )
      
          include (cross_generic_gcc)
      
    • We use cmake find_path and find_library to check if libmetal includes and libmetal library is in the includes and library search paths. However, for non-linux system, it doesn't work with CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH variables, and thus, we need to specify those paths in the toolchain file with CMAKE_C_FLAGS and CMAKE_FIND_ROOT_PATH.

  • Compile the OpenAMP library:

    $ mkdir -p build-openamp
    $ cd build-openamp
    $ cmake <openamp_source> -DCMAKE_TOOLCHAIN_FILE=<toolchain_file>
    $ make VERBOSE=1 DESTDIR=$(pwd) install
    

The OpenAMP library will be generated to build/usr/local/lib directory, headers will be generated to build/usr/local/include directory, and the applications executable will be generated to build/usr/local/bin directory.

Example to compile OpenAMP Linux Userspace for Zynq UltraScale+ MPSoC

We can use yocto to build the OpenAMP Linux userspace library and application. open-amp and libmetal recipes are in this yocto layer: https://github.com/OpenAMP/meta-openamp

  • Add the meta-openamp layer to your layers in your yocto build project's bblayers.conf file.
  • Add libmetal and open-amp to your packages list. E.g. add libmetal and open-amp to the IMAGE_INSTALL_append in the local.conf file.
  • You can also add OpenAMP demos Linux applications packages to your yocto packages list. OpenAMP demo examples recipes are also in meta-openamp: https://github.com/OpenAMP/meta-openamp/tree/master/recipes-openamp/rpmsg-examples

In order to user OpenAMP(RPMsg) in Linux userspace, you will need to have put the IPI device, vring memory and shared buffer memory to your Linux kernel device tree. The device tree example can be found here: https://github.com/OpenAMP/open-amp/blob/main/apps/machine/zynqmp/openamp-linux-userspace.dtsi

Version

The OpenAMP version follows the set of rule proposed in Semantic Versioning specification.

Supported System and Machines

For now, it supports:

  • Zynq generic remote
  • Zynq UltraScale+ MPSoC R5 generic remote
  • Linux host OpenAMP between Linux userspace processes
  • Linux userspace OpenAMP RPMsg host
  • Linux userspace OpenAMP RPMsg remote
  • Linux userspace OpenAMP RPMsg and MicroBlaze bare metal remote

Known Limitations:

  1. In case of OpenAMP on Linux userspace for inter processors communication, it only supports static vrings and shared buffers.
  2. sudo is required to run the OpenAMP demos between Linux processes, as it doesn't work on some systems if you are normal users.

How to contribute:

As an open-source project, we welcome and encourage the community to submit patches directly to the project. As a contributor you should be familiar with common developer tools such as Git and CMake, and platforms such as GitHub. Then following points should be rescpected to facilitate the review process.

Licencing

Code is contributed to the Linux kernel under a number of licenses, but all code must be compatible with version the BSD License, which is the license covering the OpenAMP distribution as a whole. In practice, use the following tag instead of the full license text in the individual files:

```
SPDX-License-Identifier:    BSD-3-Clause
SPDX-License-Identifier:    BSD-2-Clause
```

Signed-off-by

Commit message must contain Signed-off-by: line and your email must match the change authorship information. Make sure your .gitconfig is set up correctly:

```
git config --global user.name "first-name Last-Namer"
git config --global user.email "[email protected]"
```

gitlint

Before you submit a pull request to the project, verify your commit messages meet the requirements. The check can be performed locally using the the gitlint command.

Run gitlint locally in your tree and branch where your patches have been committed:

  ```gitlint```

Note, gitlint only checks HEAD (the most recent commit), so you should run it after each commit, or use the --commits option to specify a commit range covering all the development patches to be submitted.

Code style

In general, follow the Linux kernel coding style, with the following exceptions:

  • Use /** */ for doxygen comments that need to appear in the documentation.

The Linux kernel GPL-licensed tool checkpatch is used to check coding style conformity.Checkpatch is available in the scripts directory.

To check your <n> commits in your git branch:

./scripts/checkpatch.pl --strict  -g HEAD-<n>

Send a pull request

We use standard github mechanism for pull request. Please refer to github documentation for help.

Communication and Collaboration

Subscribe to the OpenAMP mailing list([email protected]).

For more details on the framework please refer to the OpenAMP Docs.

open-amp's People

Contributors

anchao avatar arnopo avatar arvindraghuraman avatar carlocaione avatar cv-bowen avatar eanjum avatar edgarigl avatar edmooring avatar edmooring-xilinx avatar explorerwyr avatar galak avatar glneo avatar guidingli avatar hubertmis avatar iuliana-prodan avatar joshualin-petaio avatar kernelchuk avatar kinjalp27 avatar michalprincnxp avatar mzyx-hnu avatar saddepal avatar samsor avatar tammyleino avatar tyokota-eforce avatar ulfalizer avatar umairkhanuet avatar wjliang avatar wmamills avatar xiaoxiang781216 avatar zaporozhets avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

open-amp's Issues

OpenAmp on Microblaze

I am trying to port the example mentioned in UG1186 onto Microblaze (Soft IP).
I work on zc102 board, I want to make communication between cortex 53 and Microblaze (PL->Soft IP).
I tried googling about it but found none.
If anyone has any Idea how to do that please help.

Linux user space apps don't connect

Compiled on Ubuntu 16.04. echo_testd-shared and echo_test-shared don't connect.

$ sudo LD_LIBRARY_PATH=usr/local/lib/ usr/local/bin/echo_testd-shared
metal: debug:     Failed fread /dev/urandom
metal: debug:     added page size 4096 @/tmp
metal: debug:     added page size 2097152 @/dev/hugepages
metal: debug:     registered platform bus
metal: debug:     registered pci bus
Waiting for connection on /tmp/openamp.event.0

In another shell

$ sudo LD_LIBRARY_PATH=usr/local/lib/ usr/local/bin/echo_test-shared
metal: debug:     Failed fread /dev/urandom
metal: debug:     added page size 4096 @/tmp
metal: debug:     added page size 2097152 @/dev/hugepages
metal: debug:     registered platform bus
metal: debug:     registered pci bus
 1 - Send data to remote core, retrieve the echo and validate its integrity ..
Waiting for connection on /tmp/openamp.event.0

And ... nothing happens.

I can repeat this for matrix_multiply as well.

I followed the instructions for building. No additional changes.

I've run the tests for libmetal and they pass. (make test)

Thoughts? Where should I be looking?

Code review cleanups of decoupling work

  • Cleanup how is_rpmsg_ept_ready to be more natural:
        return (ept->dest_addr != RPMSG_ADDR_ANY &&
                ept->addr != RPMSG_ADDR_ANY);
  • Fix rpmsg_virtio_get_buffer_size: No need to for size -= sizeof(struct rpmsg_hdr); already done as part of _rpmsg_virtio_get_buffer_size

  • Cleanup usage / remove RPMSG_ERR_UNEXPECTED

  • RPMSG_EPT_CB_HANDLED -> use RPMSG_SUCCESS for ept_cb, add assert for now in rpmsg_virtio_rx_callback

Decouple remoteproc to start a remote processor from RPMsg/Virtio

There are the following limitations of remoteproc API today to start a processor system:

  • remoteproc APIs are tight to RPMsg virtio APIs, cannot just use the remoteproc API to load a simple ELF file
  • firmware is required to be in memory
  • resource table is required in the ELF.
  • it loads data using sections. This will not work for the case to load the firmware in streams. (no seek is supported)
  • doesn't supports Elf64

The proposal is to:

  • separate remoteproc from virtio, rpmsg,
  • allow remoteproc to load a simple ELF.
  • allow to have the ELF loaded from storage
  • allow to have ELF loaded streamingly (no seek)
  • support 64 bit ELF

Here is the user application flow:

/* User defines remoteproc operations
 * rproc instance initialization
 * @init: create and initialize a remoteproc instance
 * @remove: remove the remoteproc instance, it should also release its
 *          memory resource
 * @get_ready: make the remoteproc ready to load and run application
 * @start: kick the remoteproc to run application
 * @stop: stop the remoteproc from running application, the resource such as
 *        memory may not be off.
 * @go_offline: shutdown the remoteproc and release its resources.
 * @da_mmap: memory mapped the target mempory
 */
struct remoteproc_ops r5_rproc_ops = {
        .init = r5_rproc_init,
        .remove = r5_rproc_remove,
        .get_ready = r5_rproc_get_ready,
        .start = r5_rproc_start,
        .stop = r5_rproc_stop,
        .go_offline = r5_rproc_go_offline,
        .da_mmap = r5_rproc_da_mmap,
};

/* User defines loading firmware operations which will be called by remoteproc when
 * loads a firmwar.
 * @open: user defined callback to open the "firmware" to prepare loading
 * @close: user defined callback to close the "firmware" to clean up
 *         after loading
 * @postopen: user defined callback before loading the firmware contents
 *            to target memory
 * @load: user defined callback to load the firmware contents to target
 *           memory from storage
 * @load_finish: user defined callback used to make sure all the async
 *               firmware loading finish
 * @features: loader supported features. e.g. seek
 */
struct loader_ops sd_loader_ops = {
        .open = sd_loader_open,
        .close = sd_loader_close,
        .postopen = fw_postopen,
        .load = sd_loader_load,
        .load_finish = sd_loader_load_finish,
        .features = SUPPORT_SEEK,
};


/* E.g. application flow to start/stop a remote processor */
int main(void)
{
        struct remoteproc *rproc;
        void *fw_info;
        int fw_data = 0;
        void *fw = &fw_data;

        /* Initialize remoteproc instance */
        rproc = remoteproc_init(&r5_rproc_ops, &r5_priv);
        if (!rproc)
                return -1;

        /* Load remtoeproc firmware, it will return the firmware
         * information pointer, which can be used by application
         * later. The remoteproc will find a firmware parser by
         * detecting its format.
         */
        fw_info = remoteproc_load_fw(rproc, fw, &sd_loader_ops);
        /* Start the processor */
        if (!fw_info)
                return -1;
        remoteproc_start(rproc);
        /* ... */
        remoteproc_stop(rproc);
        /* application may want to do some cleanup before shutdown */
        remoteproc_shutdown(rproc);
        remoteproc_remove(rproc);
}
/* This is how the proposed remoteproc load firmware implementation */
void *remoteproc_load_fw(struct remoteproc *rproc, void *fw,
                       struct loader_ops *loader_ops)
{
        int ret;
        struct fw_ops *fops;
        void *fw_info;
        metal_phys_addr_t entry;
        metal_phys_addr_t rsc_da;
        ssize_t rsc_len;
        ssize_t rsc_offset;

        if (!rproc)
                return -RPROC_ENODEV;

        metal_mutex_acquire(&rproc->lock);
        /* If remoteproc is running, cannot load firmware */
        if (rproc->state == RPROC_RUNNING || rproc->state == RPROC_ERROR) {
                openamp_error("load fw failure: invalid rproc state %d.\n",
                              rproc->state);
                goto error;
        }

        if (!load_ops) {
                openamp_error("load fw failure: loader ops is not set.\n");
                goto error;
        }

        /* Open firmware to get ready to parse */
        ret = loader_ops->open(fw);
        if (ret) {
                openamp_error("load fw failure: failed to open firmware.\n");
                goto error;
        }

        /* Check firmware format to select a parser, E.g. if it is ELF, it will
 	 * picked the ELF parser
	 */
        fops = remoteproc_check_fw_format(fw, loader_ops);
        if (!fops) {
                openamp_error("load fw failure: failed to get fw ops.\n");
                goto error;

		/* parse the firmware, get the headers. E.g. ELF image header and program headers
		 * if the loader supports seek, it will also gets the section headers
		 */
        ret = fops->parse(fw, &fw_info, loader_ops);
        if (ret) {
                openamp_error("load fw failure: failed to parse firmware.\n");
                goto error;
        }

        /* remoteproc get ready to load the firmware, it may need to
         * get extra configuration information from the firmware to get
         * ready to load the firmware
         */
        ret = rproc->ops->get_ready(rproc, fw, fw_info, fops, loader_ops);
        if (ret) {
                openamp_error("load fw failure: remote get ready failed.\n");
                goto error;
        }

        /* load firmware. E.g. for ELF, it will load each loadable segments */
        ret = fops->load(fw, fw_info, rproc, loader_ops);
        if (ret) {
                openamp_error("load fw failure: failed to load firmware.\n");
                goto error;
        }

        /* Get resource table if it is there for resource which is shared
         * with the remote.
         */
        rsc_len = fops->get_rsc_table(fw, fw_info, &rsc_da, &rsc_offset);
        if (rsc_len > 0) {
                rproc->rsc_table = rproc->ops->da_mmap(rproc, rsc_da,
                                                       (size_t)rsc_len,
                                                       0, &rproc->rsc_io,
                                                       NULL);
                rproc->rsc_len = (size_t)rsc_len;
        }

        /* get entry point from the firmware */
		entry = fops->get_entry(fw_info);
        rproc->bootaddr = entry;
        rproc->state = RPROC_READY;

        metal_mutex_release(&rproc->lock);
        return fw_info;
error:
        metal_mutex_release(&rproc->lock);
        return NULL;
}

When loading the firmware, it will loads loadable segments instead of sections as
the program header is placed before the segment data in the ELF and the the section headers
are placed to the end of ELF. Proposed ELF loader implementation is attached

hil_set_shm(): incorrect test of memory size?

Hi, in hil_set_shm() at line 660 it seems the test for valid memory size is not correct:

if (proc->sh_buff.io) {
io = proc->sh_buff.io;
if (io->size > size)
return -1;
...

I think it should be:
if (io->size < size)
return -1;

Thanks

Static endpoint cleanup

Close on changes for static endpoint support, rename new endpoint callback to endpoint announcement callback.

EWARM warnings

Hi,
Using the openAMP with IAR EWARM there are the following warnings:
Warning[Pe223]: function "metal_generic_dev_sys_open" declared implicitly OpenAMP\libmetal\lib\device.c 148


Warning[Pe223]: function "metal_sys_io_mem_map" declared implicitly OpenAMP\libmetal\lib\system\generic\device_generic.c 51


Warning[Pe223]: function "metal_sys_init" declared implicitly OpenAMP\libmetal\lib\init.c 47


Warning[Pe223]: function "metal_sys_finish" declared implicitly OpenAMP\libmetal\lib\init.c 56


Warning[Pe223]: function "metal_machine_io_mem_map" declared implicitly OpenAMP\libmetal\lib\system\generic\io_generic.c 50


Warning[Pe223]: function "metal_sys_io_mem_map" declared implicitly OpenAMP\libmetal\lib\io.c 48


Warning[Pe223]: function "sys_irq_save_disable" declared implicitly OpenAMP\libmetal\lib\system\generic\irq.c 258


Warning[Pe223]: function "sys_irq_restore_enable" declared implicitly OpenAMP\libmetal\lib\system\generic\irq.c 266


Warning[Pe111]: statement is unreachable OpenAMP\open-amp\lib\rpmsg\remote_device.c 379


Warning[Pe111]: statement is unreachable OpenAMP\open-amp\lib\remoteproc\rsc_table_parser.c 163


Warning[Pe223]: function "metal_shmem_open_generic" declared implicitly OpenAMP\libmetal\lib\system\generic\shmem_generic.c 41

Is it possible to fix them?
regards
Haithem.

shared memory are not protected

I am seeing two potential issues:

  • tx/rx vrings address are hardcoded in the code (E.g. baremetal), there is no section for it. there is no guarantee that the shared memory will not be corrupted by the software.
  • shared memory hardcoded in platform_info.c has no connection to vrings.
    • It will needs better description in the code, and tells how the number comes

Provide extern "C" declarations for the case the code is mixed with C++

Today it is common pactice to add the code shown below to C header files in order to allow their use from C++:

#if defined __cplusplus
extern "C" {
#endif
:
:
#if defined __cplusplus
}
#endif

I have seen that the files under the obsolate directory follow this practise. Unfortunately, the files under lib/include/openamp don't. This gives some inconvenience if you want to use the open-amp implementation with C++.

Please consider this is as improvement request for future versions.

Can multiple rpmsg_rtos_alloc_tx_buffer() calls be made prior to rpmsg_rtos_send_nocopy()?

We are currently experiencing a bug on the iMX7s using rpmsg where the M-core is getting the SAME buffer from rpmsg_rtos_alloc_tx_buffer() before it is ever en-queued during rpmsg_rtos_send_nocopy(). A-core is running Linux and is the MASTER, M-core is running MQX.
We see the M-core get the same buffer 4 times in row, and as a result the data is corrupted when received on the A-core. The bug has a low encounter rate, but is easy to re-produce when we generate a lot of transmissions from the M-core to the A-core. It may be that this is not a bug but that we are misusing rpmsg_rtos_alloc_tx_buffer() ?

Is it required that you complete a call to rpmsg_rtos_send_nocopy() before you call rpmsg_rtos_alloc_tx_buffer() again? The underlying code for rpmsg_rtos_alloc_tx_buffer() led us to believe that is simply gets the next available packet, but maybe that is not the case?

thanks,
Jeremy

error while building with Yocto

Hi,
I've just started to try OpenAMP. I've followed the instructions to install the open-amp and libmetal recipes with Yocto. However, I've got the following error:

"Nothing RPROVIDES 'rpmsg-examples' (but /home/yaset/QorIQ-SDK-V2.0-20160527-yocto/sources/meta-freescale/recipes-fsl/images/fsl-image-core.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'rpmsg-examples' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['rpmsg-examples']"

I hope someone can help me with this.

Regards,

Yaset

set_status in virtio_dispatch inconsistency for remote/slave role

We currently have in remoteproc_virtio.c:

const struct virtio_dispatch remoteproc_virtio_dispatch_funcs = {
	.get_status =  rproc_virtio_get_status,
	.get_features = rproc_virtio_get_features,
	.read_config = rproc_virtio_read_config,
	.notify = rproc_virtio_virtqueue_notify,
	.negotiate_features = rproc_virtio_negotiate_features,
#ifndef VIRTIO_SLAVE_ONLY
	/*
	 * We suppose here that the vdev is in a shared memory so that can
	 * be access only by one core: the master. In this case salve core has
	 * only read access right.
	 */
	.set_status = rproc_virtio_set_status,
	.set_features = rproc_virtio_set_features,
	.write_config = rproc_virtio_write_config,
	.reset_device = rproc_virtio_reset_device,
#endif
};

If compiling for SLAVE only the .set_status callback is not defined, but in rpmsg_virtio.c we can end up calling it (via rpmsg_virtio_set_status function) in the rpmsg_virtio_wait_remote_ready function:

#ifndef VIRTIO_MASTER_ONLY
/**     
 * check if the remote is ready to start RPMsg communication
 */                  
static int rpmsg_virtio_wait_remote_ready(struct rpmsg_virtio_device *rvdev)
{
        uint8_t status;
        
        while (1) {
                status = rpmsg_virtio_get_status(rvdev);
                /* Busy wait until the remote is ready */
                if (status & VIRTIO_CONFIG_STATUS_NEEDS_RESET) {
                        rpmsg_virtio_set_status(rvdev, 0);
                        /* TODO notify remote processor */
                } else if (status & VIRTIO_CONFIG_STATUS_DRIVER_OK) {
                        return true;
                }
                /* TODO: clarify metal_cpu_yield usage*/
                metal_cpu_yield();
        }
        
        return false;
}
#endif /*!VIRTIO_MASTER_ONLY*/

Using open-amp for M4

Hi,

i just want to use RPMsg baremetal on the slave side (Linux side is already running). I am quite confused what components i need to port. In your documentation of open-amp there is written to port the platform.c.h files. But in libmetal there is written I need to port alloc,cache etc.. So I need to to both?

General Question:
How do both systems (master and slave) knows what kind of hardware layer (interrupt base, mailboxes etc,) they use for communication? Is there a common file/header for checking compatibility?

Thanks Andreas

Can't RPMsg remote send messages until the master send the first message?

Hi, I'm using ST vendor's OpenAMP port but I think it is applied to the upstream as well so I'm posting a question here.

While working with RPMsg I found that the remote cannot send message using rpmsg_send() until the master sends any data first because ept->dest_addr is set to RPMSG_ADDR_ANY in the vendor when creating the endpoint. ept->dest_addr is corrected in the fist rpmsg_virtio_rx_callback:

if (ept->dest_addr == RPMSG_ADDR_ANY) {
    /*
     * First message received from the remote side,
     * update channel destination address
     */
    ept->dest_addr = rp_hdr->src;
}

This looks like it's OpenAMP's design decision that blocks sending data from the remote until the master sends data.

I don't know if my thoughts is correct. If it is, how to workaround this limitation? Should the master send any data when an endpoint is created, or I should figure out the correct local endpoint's destination address when creating the endpoint?

C++ compatibility errors

Nested structs and unions have different visibility rules in C and C++ and causes compilation error from defined here:

struct vq_desc_extra {
void *cookie;
uint16_t ndescs;
} vq_descx[0];

and used here:

num_desc_extra * sizeof(struct vq_desc_extra);

minimal example of the issue: https://godbolt.org/z/7GElZ4

Solution could be either to move definition of struct vq_desc_extra outside of struct virtqueue, or make function virtqueue_allocate() not inline, but rather implemented in C source file.

Such issues can be identified with -Wc++-compat flag on GCC, but are only relevant for header files included into C++ source files.

conflicting types for ‘sleep’

open-amp/apps/func_test_suite/func_test_suite.c:25:13: error: conflicting types for ‘sleep’
 static void sleep();
             ^
In file included from libmetal-install/usr/local/include/metal/system/linux/sys.h:58:0,
                 from libmetal-install/usr/local/include/metal/sys.h:111,
                 from libmetal-install/usr/local/include/metal/dma.h:47,
                 from open-amp/lib/include/openamp/virtqueue.h:37,
                 from open-amp/lib/include/openamp/virtio.h:34,
                 from open-amp/lib/include/openamp/rpmsg_core.h:35,
                 from open-amp/lib/include/openamp/rpmsg.h:39,
                 from open-amp/lib/include/openamp/open_amp.h:33,
                 from open-amp/apps/func_test_suite/func_test_suite.c:8:
/usr/include/unistd.h:447:21: note: previous declaration of ‘sleep’ was here
 extern unsigned int sleep (unsigned int __seconds);
                     ^
****

Compiling with -DWITH_FUNCTION_TEST_SUITE=ON from cmake.
OS is

$ uname -a
Linux *** 4.13.0-43-generic #48~16.04.1-Ubuntu SMP Thu May 17 12:56:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is it somehow unexpected to have sleep(unsigned int) defined here?

Follow openamp_gs.pdf and meet build error.

openamp_gs.pdf:
5. Build PetaLinux
a. Change into the <master_root>
$ cd <master_root>
b. Execute the following command:
$ petalinux-build

kinreven@ubuntu:~/openamp/xilinx-zynq-linux$ petalinux-build
INFO: Checking component...
INFO: Generating make files and build linux
INFO: Generating make files for the subcomponents of linux
INFO: Building linux
[INFO ] pre-build linux/rootfs/rpmsg_echo_test_kern_app
[INFO ] pre-build linux/rootfs/rpmsg_mat_mul_kern_app
[INFO ] pre-build linux/rootfs/rpmsg_proxy_dev_driver
[INFO ] pre-build linux/rootfs/rpmsg_user_dev_driver
[INFO ] pre-build linux/rootfs/zynq_remoteproc_driver
[INFO ] pre-build linux/rootfs/echo_test
[INFO ] pre-build linux/rootfs/echo_test_baremetal_fw
[INFO ] pre-build linux/rootfs/fwupgrade
[INFO ] pre-build linux/rootfs/mat_mul_baremetal_fw
[INFO ] pre-build linux/rootfs/mat_mul_demo
[INFO ] pre-build linux/rootfs/peekpoke
[INFO ] pre-build linux/rootfs/proxy_app
[INFO ] pre-build linux/rootfs/rpc_demo_baremetal_fw
[INFO ] pre-build linux/rootfs/uWeb
[INFO ] build system.dtb
[INFO ] build linux/kernel
[INFO ] update linux/u-boot source
[INFO ] generate linux/u-boot configuration files
[INFO ] build linux/u-boot
[INFO ] Setting up stage config
[INFO ] Setting up rootfs config
[INFO ] Updating for armv7a-vfp-neon
[INFO ] Updating package manager
[INFO ] Expanding stagefs
[INFO ] build kernel in-tree modules
[INFO ] modules linux/kernel
[INFO ] build linux/rootfs/rpmsg_echo_test_kern_app
[INFO ] modules linux/kernel
[INFO ] build linux/rootfs/rpmsg_mat_mul_kern_app
[INFO ] modules linux/kernel
[INFO ] build linux/rootfs/rpmsg_proxy_dev_driver
[INFO ] modules linux/kernel
[INFO ] build linux/rootfs/rpmsg_user_dev_driver
[INFO ] modules linux/kernel
[INFO ] build linux/rootfs/zynq_remoteproc_driver
[INFO ] modules linux/kernel
[ERROR] make[6]: *** [/home/kinreven/openamp/xilinx-zynq-linux/build/linux/rootfs/modules/zynq_remoteproc_driver/zynq_remoteproc_driver.o] Error 1
[ERROR] make[5]: *** [module/home/kinreven/openamp/xilinx-zynq-linux/build/linux/rootfs/modules/zynq_remoteproc_driver] Error 2
[ERROR] make[4]: *** [sub-make] Error 2
[ERROR] make[3]: *** [modules_only] Error 2
[ERROR] make[2]: *** [modules] Error 2
[ERROR] make[1]: *** [sub_build_component_/none/modules/multi/zynq_remoteproc_driver] Error 2
ERROR: Failed to build linux

RPMsg functional testing suite

We plan on moving func_test_suite to apps/tests/api, we need to update this api test for all the new api's that are part of the decoupling work.

Load_FW demo on ZCU102

I'm attempting to get the load_fw demo to work on a ZCU102 eval board, and having much difficulty. Ultimately the goal is to have the APU running vxWorks and bring either RPU core out of reset and run arbitrary code, but right now I'm looking to understand what is provided here.

What steps would be needed to run the demo as is on the ZCU102 eval board?

Is there any further documentation? It's unclear to me what the target platform is or how to provide the .elf file to be loaded for the load_fw as provided.

elf_loader is not compatible with C++ executable

Hi I am not sure but following code in elf_loader_load_sections prevents loading C++ constructor initialization section
/* Check if the section is part of runtime and is not section with
* no-load attributes such as BSS or heap. */
if ((current->sh_type & SHT_NOBITS) == 0) {

sh_type for that kind of sections is #define SHT_INIT_ARRAY 14
and #define SHT_FINI_ARRAY 15
which is 0xE or 0xF in hex
BR, Alex.

microblaze openamp IPI probleam

Hi, I was trying to use microblaze to realize openamp echo-test example. I have checked #135, so I could only use it in linux userspace. I have already designed my vivado project(refer to https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841793/Utilizing+PS+memory+to+execute+Microblaze+application+on+Zynq+Ultrascale?search_id=a14232a6-1b0e-40fa-acd1-3fd39a4c94fc), then lanched to SDK and build my microblaze echo-test application. On the other side, I got my petalinux project ready. However, when I started the test, it seems that microblaze side never got the IPI inerrupt message from linux, which means that linux side send a number and receive nothing from microblaze side.

Microblaze app have already finished rpmsg initialization and start polling, so I think it?did not get IPI interrupt.

Here is my console:

root@mb-test:~# echo_test-openamp
metal: info: metal_uio_dev_open: No IRQ for device 3ed40000.vring.
metal: info: metal_uio_dev_open: No IRQ for device 3ed40000.vring.
metal: info: metal_uio_dev_open: No IRQ for device 3ed80000.shm.
1 - Send data to remote core, retrieve the echo and validate its integrity ..
Remote proc resource initialized.

And here is my terminal(from my sdk echo-test project):

Starting application...
Try to init remoteproc resource

Init remoteproc resource succeeded
Waiting for events...

Here is my microblaze code.

Redundant bindings present in DT remoteproc node

Currently the bindings for the remoteproc device tree node for Linux master consists three interrupt definitions.
ipino = <6>;
vring0 = <2>;
vring1 = <3>;

All we really need is two IPIs – one for master to notify remote, and another for remote to notify master.

In order to fix remove the redundant binding and confusion caused because of it;
• Remove ipino.
• Vring0 - is the interrupt remote will use to notify master (rx virtqueue)
• Vring1 - is the interrupt master will use to notify remote (rx virtqueue)

cannot find -lzip/-lfdt

When i execute command 'source open_amp_build.sh', i am getting an about missing libraries. Do we need to compile these libraries (fdt,zlib) seperately and add to project?

Building Linux Bootstrap

CC libs/system/zc702evk/linux/boot.o
CC libs/system/zc702evk/linux/rsc_table.o
AS libs/system/zc702evk/linux/boot_wrapper.o
Building linux aggregate image : libs/system/zc702evk/linux/firmware
arm-xilinx-eabi-gcc -nostartfiles -T"/home/mhrztrk/RFI/work/open-amp/libs/system/zc702evk/linux/link_remote.ld" -L"/home/mhrztrk/RFI/work/open-amp/libs/system/zc702evk/linux/lib/arm-xilinx-eabi-" -o "libs/system/zc702evk/linux/firmware" -Wl,--start-group libs/system/zc702evk/linux/boot.o libs/system/zc702evk/linux/rsc_table.o libs/system/zc702evk/linux/boot_wrapper.o -lc -lm -lstdc++ -lzlib -lfdt -Wl,--end-group
/opt/Xilinx/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-gnueabi/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/bin/ld: cannot find -lzlib
/opt/Xilinx/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-gnueabi/bin/../lib/gcc/arm-xilinx-eabi/4.8.3/../../../../arm-xilinx-eabi/bin/ld: cannot find -lfdt
collect2: error: ld returned 1 exit status
make: *** [libs/system/zc702evk/linux/firmware] Error 1

Rework dir struct of apps into examples/ & tests (tests is echo + api)

Make a cleaner split between examples and tests. So lets re-org the apps dir as follows:

apps/tests/
apps/examples/
apps/platform/

apps/echo_test/ & apps/echo_test_decouple -> apps/examples/echo
apps/func_test_suite -> apps/tests/api
apps/linux_firmware_remoteproc_slave -> apps/platform ???
apps/load_fw -> apps/platform ???
apps/machine -> apps/platform
apps/matrix_multiply -> apps/examples/matrix_multiply
apps/rpc_demo -> apps/examples/rpc_demo
apps/systerm -> apps/platform

Why disable virtqueue callback function?

In file lib/rpmsg/rpmsg_virtio.c, line 587: it disables the callback function.

When running the echo examples, the remote core will not get any response when the master core runs virtqueue_kick function[because vq_ring_must_notify wiil return false].

	/*
	 * Suppress "tx-complete" interrupts
	 * since send method use busy loop when buffer pool exhaust
	 */
	virtqueue_disable_cb(rvdev->svq);
/**
 * virtqueue_kick - Notifies other side that there is buffer available for it.
 *
 * @param vq      - Pointer to VirtIO queue control block
 */
void virtqueue_kick(struct virtqueue *vq)
{
	VQUEUE_BUSY(vq);

	/* Ensure updated avail->idx is visible to host. */
	atomic_thread_fence(memory_order_seq_cst);

	if (vq_ring_must_notify(vq))
		vq_ring_notify(vq);

	vq->vq_queued_cnt = 0;

	VQUEUE_IDLE(vq);
}

Checklist for merging of decouple work

  • RPMSG:
    • Close on changes for static endpoint support, rename new endpoint callback to endpoint announcement callback. (PR #98)
    • Review changes to remove shmem (PR #99)
    • Style review -- checkpatch.pl?
    • Make MASTER/SLAVE a cmake option (PR #100)
    • Code review
  • Remoteproc:
    • Code review
  • General:
    • Update apps for new api changes. (PR #103)
    • [ X] Rework dir struct of apps into examples/ & tests (tests is echo + api) (PR #101)
  • Testing:
    • Decouple apps platform code from remoteproc (PR #104)
    • Message Tests:
      [ ] RPC demo
    • Message test development:
      • [ X ] Linux Kernel driver for msg test (master)
      • Zephyr master/slave for msg test
      • [ X ] Bare Metal master/slave for msg test
      • [ X ] Linux OpenAMP Userspace master/slave for msg test
    • Message test validation:
      • Master: Linux OpenAMP Userspace / Slave: Linux Openamp Userspace [posix] (x86 linux)
      • Master: Linux OpenAMP Userspace / Slave: Bare Metal (uio) (Zync UltraScale+)
      • Master: Linux Kernel / Slave: Bare Metal (Zync UltraScale+, ST Platform)
      • Master: Linux Kernel / Slave: Zephyr (ST Platform)
      • Master: Bare Metal / Slave: Bare Metal (Zync UltraScale+)
      • Master: Bare Metal / Slave: Linux Openamp Userspace (uio) (Zync UltraScale+)
      • Master: Zephyr / Slave: Zephyr (NXP)
    • RPMsg functional testing suite (PR #106)
    • Test OpenAMP apps on Zync platform
    • Zephyr - implement slave support
    • Add 'slave' app to match Linux Kernel samples/rpmsg/rpmsg_client_sample.c (PR #102)
    • Test 'slave' app on ST platform w/Zephyr
    • Update proxy support (PR #107)

Please make the OpenAMP API const correct

Nowadays const correctness should be self-evident, especially for library code. It makes the API more clear, gives a contract on which data will not be modified by the callee and helps the compiler to warn about violations. In total const correctness helps to improve usability, quality and maintainability of the code.

Unfortunately, I found that the OpenAMP implementation does not care about const correctness. I consider this is serious bug.

For example the rpmsg_send_offchannel_raw() has the following signature:

/**
 * This function sends rpmsg "message" to remote device.
 *
 * @param rp_chnl - pointer to rpmsg channel
 * @param src     - source address of channel
 * @param dst     - destination address of channel
 * @param data    - data to transmit
 * @param size    - size of data
 * @param wait    - boolean, wait or not for buffer to become
 *                  available
 *
 * @return - status of function execution
 *
 */

int rpmsg_send_offchannel_raw(struct rpmsg_channel *rp_chnl, uint32_t src,
			      uint32_t dst, char *data, int size, int wait);

Hopefully, the data to transmit are not modified by the function. Therefore it should be qualified as const. I am not sure if rp_chnl is modified by the function. This is hard to figure out at a glace (which is a good example why const correctness important).

Assuming that rp_chnl is constant too, the correct function prototype would be:

int rpmsg_send_offchannel_raw(const struct rpmsg_channel *rp_chnl, uint32_t src,
			      uint32_t dst, const char *data, int size, int wait);

Another example is the function rpmsg_get_buffer_size():

/**
 * rpmsg_get_buffer_size
 *
 * Returns buffer size available for sending messages.
 *
 * @param channel - pointer to rpmsg channel
 *
 * @return - buffer size
 *
 */
int rpmsg_get_buffer_size(struct rpmsg_channel *rp_chnl):

It is obvious that the function will not change the passed parameter. Thus the correct function prototype is:

int rpmsg_get_buffer_size(const struct rpmsg_channel *rp_chnl):

I think this is essential therefore I ask you to make the OpenAMP API const correct.

Decouple app platform code from remote proc

The apps should hide remote proc details behind the platform layer to allow for usage with and without remoteproc.

So things like platform_create_proc() should just return a void *, etc.

How to clear/free/flush virtio buffer ring?

I am using rpmsg to communicate between a linux (A9) and a FreeRTOS (M4) on an imx6sx through a kernel module with ioctl on a device file on devfs.

The communication works…sending and receiving is fine, but when I reload a FreeRTOS image on the M4 side…all the previous send rpmsg messages will be received from the M4 again. Afterwards I can send and receive new messages. But it seems that the virtio buffer ring in the shared memory stays even I run "rmmod" the kernel module.

Is there a way to clear, free or flush the shared memory to communicate via IPC? I would prefer to flush the within my loadable kernel module.

OpenAMP Linux to Linux

I'd like to be able to test and develop my OpenAMP functionality without access to hardware (or emulator) for the target system. Is it possible to use the OpenAMP APIs to communicate within the same Linux OS?

For example use remoteproc to load a process using OpenAMP back into the same OS?

Other suggestions for testing are welcome.

Linux: select() call does not work with char device created by user_dev_driver

Hi Everyone:

I would like build some asynchronous processing logic with OpenAMP. I intend to use select() upon an opened file descriptor to block until there is data available or a timeout expired. The Problem is that the select call doesn't block then used with OpenAMPs file descriptor. The cause of this might be the missing poll() functionality.

I would really love to seem this feature soon.

Communicate between multi linux processes and rtos on same RPMsg channel.

We would like to communicate between two linux processes, these use different endpoints, and RTOS tasks by RPMsg on same channel.
Is this function possible? and if it's possible what should we do?

(Linux)                 (RTOS)
[proc1(user app)]#ep1 -- [vring] --- [ RTOS task(app)#ep1]
[proc2(mng app)]#ep2           [ RTOS task(mng)#ep2]

rpmesg_virtio: Statement unreachable

Hi,
the function rpmsg_virtio_wait_remote_ready() is throwing the following warning with MDK-ARM compiler:
OpenAMP/open-amp/lib/rpmsg/rpmsg_virtio.c(236): warning: #111-D: statement is unreachable
the function implementation is as following:

	while (1) {
		status = rpmsg_virtio_get_status(rvdev);
		/* Busy wait until the remote is ready */
		if (status & VIRTIO_CONFIG_STATUS_NEEDS_RESET) {
			rpmsg_virtio_set_status(rvdev, 0);
			/* TODO notify remote processor */
		} else if (status & VIRTIO_CONFIG_STATUS_DRIVER_OK) {
			return true;
		}
		/* TODO: clarify metal_cpu_yield usage*/
		metal_cpu_yield();
	}

	return false;
}

with the while(1) loop the "return false;" in indeed unreachable.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.