Communication between Linux(Master) and Linux(Slave) on Desktop Core 0 and Core 1 homogeneous processor

[viswaharsha]

Hi,

I am using my desktop core i5 quad core processor.
I have two terminals of same linux OS running on core0(terminal 1) and core1(terminal 2) using taskset.
Can they communicate between each other as Master and Slave and perform remote procedure calls between each other available at apps/examples/rpc_demo/demod.c for master(terminal 1) and apps/examples/rpc_demo/demo.c for slave(terminal 2)?

[arnopo]

Do you try to run exemples on your Linux PC, implementation seems close to your need (except the use of taskset for CPU affinity)?
https:/OpenAMP/open-amp#example-to-compile-openamp-for-communication-between-linux-processes
To understand communication between the processes, you can have a look here:
https:/OpenAMP/open-amp/blob/master/apps/system/linux/machine/generic/platform_info.c

[viswaharsha]

Shared below is the screenshot of the terminal 1(left image) running masterprogram(rpc_demod-shared) and terminal 2(right image) running slave program(rpc_demo-shared)

The expectation is, the file operation(open, read, write and close) should be performed on the terminal running master(rpc_demod-shared) and file has to be created on the directory named 'master' but the file operations are performed in the terminal running slave(rpc_demo-shared) and the file is created on directory named 'slave' as remote.file.

Also the input(name, age, value of pi) has to be fetched from the user using the terminal running master(rpc_demod-shared) and displayed in terminal running slave(rpc_demo-shared). But the input(name, age, value of pi) is fetched from the user in the terminal running slave(rpc_demo-shared) and is displayed in the terminal running slave(rpc_demo-shared).

[arnopo]

Here your point is no more the IPC communication but to adapt the demo to redirect file operations over rpc, right?
I don't think that it is a good idee as the libmetal uses file operations for the shared memory management.
So you will have to addapt the libmetal and/or the demo + rpmsg_retarget.c file to your need.

Then you will probably also have to fix the fact that two libraries implement the file operation. In this case (if I remember correctly) the linker chooses the first one it finds. One solution for this is to rename and export _open, _close defined in rpmsg_retarget.c and to redefine the file operations in the demo code.

[viswaharsha]

I have applied some changes to the following files to provide the output that I have attached below

• rpc_demod.c
• rpc_demo.c
• rpmsg_retarget.c

So can you kindly check and let me know the procedure to share the patch and test the code for contribution

[arnopo]

To contribute to the OpenAMP library please follow the process described in the README.md

[Raveem13]

Shared below is the screenshot of the terminal 1(left image) running masterprogram(rpc_demod-shared) and terminal 2(right image) running slave program(rpc_demo-shared)

The expectation is, the file operation(open, read, write and close) should be performed on the terminal running master(rpc_demod-shared) and file has to be created on the directory named 'master' but the file operations are performed in the terminal running slave(rpc_demo-shared) and the file is created on directory named 'slave' as remote.file.

Also the input(name, age, value of pi) has to be fetched from the user using the terminal running master(rpc_demod-shared) and displayed in terminal running slave(rpc_demo-shared). But the input(name, age, value of pi) is fetched from the user in the terminal running slave(rpc_demo-shared) and is displayed in the terminal running slave(rpc_demo-shared).

@viswaharsha How did you assigned cpus to terminals?

[arnopo]

@edmooring
Any reason to not adapt the demo for Linux to Linux communication ( as done for other examples)?
Could we replace xil_printf by a generic printf?

[edmooring]

@arnopo
I can't think of any reason not to do so. xil_printf() takes the same arguments as the generic printf(). In theory, it might be a little bit smaller code, but I don't know if anyone has ever measured it.