RPmsg initialization fails, communication impossible.
Hello, I need information to help.
I am developing on a custom board with ADSP-SC587.
In this system I need one ARM and two SHARCs to communicate with each other and also SHARCs need to communicate with each other.
We decided to use RPmsg as a library to realize these communication.
Although we modified the sample code and incorporated it into our project, the SHARC application fails to create a channel for RPmsg after loading the ldr file on Linux.
ARM (Cortex-A5) running Yocto Linux 3.0.0 installed based on the Quick Start Guide.
https://wiki.analog.com/resources/tools-software/linuxdsp/docs/quickstartguide/quickstart_sc589_3_0_0
(The article was for SC589 EZKIT, but we have confirmed that the built kernel image is working correctly on our board)
For the ARM-SHARC and SHARC-SHARC communication, we obtained sample code that had already been published and confirmed that the samples worked on a custom board by building with CCES and loading the ldr file.
https://github.com/analogdevicesinc/lnxdsp-examples/tree/develop/yocto-3.1.0/rpmsg-lite-examples/adsp-sc589-ezkit/sc589-ezkit-arm- bm-led-toggle
https://github.com/analogdevicesinc/rpmsg-examples
I load the ldr file like this on Linux (omitting Core2 as it is almost identical)
```
# echo stop > /sys/class/remoteproc/remoteproc0/state
# echo test_core1.ldr > /sys/class/remoteproc/remoteproc0/firmware
# echo start > /sys/class/remoteproc/remoteproc0/state
````
The general structure of the project is as follows
1. the application running on ARM Linux creates a communication channel between ARM and SHARC as the "master" of RPmsg (rpmsg_master_init)
2. SHARC application (Core1) creates a communication channel between ARM and SHARC (rpmsg_remote_init) and at the same time creates a communication channel between SHARC and SHARC (rmpsg_master_init)
3. create a communication channel between ARM and SHARC also in the SHARC application (Core2) (rpmsg_remote_init), and at the same time create a communication channel between SHARC and SHARC (rmpsg_master_init).
Separate areas are given for shared memory, buffers, channels, etc. between ARM-SHARC and SHARC-SHARC so that they do not overlap.
# Output
Attached is a log of a case where channels are affixed correctly when loading an ldr built from the sample code.
````
root@adsp-sc589-ezkit:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state
remoteproc remoteproc0: powering up core1-rproc
remoteproc remoteproc0: Booting fw image test_Core1.ldr, size 70888
adi_ldr_load_rsc_table
adi_rproc_parse_fw 1 mem_regions = -2
adi_rproc_find_loaded_rsc_table 1 loaded_rsc_table = ce915038
adi_rproc_find_loaded_rsc_table 2 vring[0].da = c3380000, vring[0].pa = 0
adi_rproc_find_loaded_rsc_table 2 vring[1].da = c3b60000, vring[1].pa = 0
adi_rproc_kick 1 adi_rsc_table = ce915000
adi_rproc_kick 2 vring[0].da = c3bc0000, vring[0].pa = 0
adi_rproc_kick 2 vring[1].da = c6440000, vring[1].pa = 0
virtio_rpmsg_bus virtio0: rpmsg host is online
remoteproc0#vdev0buffer: registered virtio0 (type 7)
remoteproc remoteproc0: remote processor core1-rproc is now up
virtio_rpmsg_bus virtio0: creating channel core1_ch1 addr 0x120
adi_rproc_kick 1 adi_rsc_table = ce915000
adi_rproc_kick 2 vring[0].da = c3bc0000, vring[0].pa = 0
adi_rproc_kick 2 vring[1].da = c6440000, vring[1].pa = 0
virtio_rpmsg_bus virtio0: creating channel core1_ch2 addr 0x121
adi_rproc_kick 1 adi_rsc_table = ce915000
adi_rproc_kick 2 vring[0].da = c3bc0000, vring[0].pa = 0
adi_rproc_kick 2 vring[1].da = c6440000, vring[1].pa = 0
```
We determined that the channel was created successfully from the line
>"virtio_rpmsg_bus virtio0: creating channel core1_ch1 addr 0x120".
The display in case of failure is as follows.
```
root@adsp-sc589-ezkit:/lib/firmware# echo stop > /sys/class/remoteproc/remoteproc0/state
ADI Reset Control Unit 3108b000.rcu: Timeout waiting for remote core 1 to IDLE!
echo start > /sys/class/remoteproc/remoteproc0xdxdtate
remoteproc remoteproc0: stopped remote processor core1-rproc
root@adsp-sc589-ezkit:/lib/firmware# echo firmware_project_Core1.ldr > /sys/class/remoteproc/remoteproc0/firmware
root@adsp-sc589-ezkit:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state
remoteproc remoteproc0: powering up core1-rproc
remoteproc remoteproc0: Booting fw image firmware_project_Core1.ldr, size 271812
adi_remoteproc 28240000.core1-rproc: Core1 rpmsg init timeout, probably not supported.
virtio_rpmsg_bus virtio0: rpmsg host is online
remoteproc0#vdev0buffer: registered virtio0 (type 7)
remoteproc remoteproc0: remote processor core1-rproc is now up
```
Channel creation has failed, and I suspect that the following line may be a clue as to why.
However, no information is available regarding this error.
> "adi_remoteproc 28240000.core1-rproc: Core1 rpmsg init timeout, probably not supported."
I have already tried "Allow SHARC SEC Code to Skip the SEC Reset" in "Linux Add-in for CrossCore Embedded Studio", but the problem was not resolved.
Also, SEC initialization is enabled on the Linux side.
Help me. please.
Thread Notes
Ranji - Moved from ADSP-SC59x to Linux for ADSP-SC5xx processors. Post date updated from Tuesday, March 12, 2024 9:29 AM UTC to Wednesday, March 13, 2024 6:02 AM UTC to reflect the move.
Ranji - Moved from ADSP-SC59x to Linux for ADSP-SC5xx processors. Post date updated from Wednesday, March 13, 2024 6:02 AM UTC to Wednesday, March 13, 2024 6:02 AM UTC to reflect the move.
yuyama - Moved from Linux for ADSP-SC5xx processors to SigmaDSP Processors & SigmaStudio Dev. Tool. Post date updated from Tuesday, March 12, 2024 9:29 AM UTC to Thursday, March 21, 2024 6:14 AM UTC to reflect the move.
yuyama - Moved from Linux for ADSP-SC5xx processors to SigmaDSP Processors & SigmaStudio Dev. Tool. Post date updated from Thursday, March 21, 2024 6:14 AM UTC to Thursday, March 21, 2024 6:14 AM UTC to reflect the move.
Audio Signal Processors
Audio Products
software
ADSP-SC587
RPMsg
SHARC Audio Processors/SoCs
Show More
Hi, does it starts if you try to load image second time?
The error messages comes from this driver https://github.com/analogdevicesinc/lnxdsp-linux/blob/main/drivers/remoteproc/adi_remoteproc.c#L734
it suggests that rpmsg isn't initialised.
Hello. Thank you for your reply.
The same error is displayed on the second load.
I reviewed the CCES project settings.
Until now, I was using an ldr file that was built using Debug.
As a test, I used a Release build, enabled "Enable optimization", and set the -Ov parameter to 100.
Then, I confirmed that the ldr file can be loaded normally. And the RPmsg channels were also created successfully.
RPmsg is already installed. I am running the sample program rpmsg-examples on Linux to check its operation.
I extended the timeout period CORE_INIT_TIMEOUT_MS in "adi_remoteproc.c" from the default 2000 to 10000.
Even with this, the Debug built ldr file fails to create the channel, while the Release built ldr file succeeds.
I don't fully understand what differences exist in the ldr files between Debug and Release builds, and I can't figure out what's actually causing the issue.
Can you check linkers files addresses of this structure when its not able to load
https://github.com/analogdevicesinc/rpmsg-examples/blob/develop/yocto-3.1.0/rpmsg_echo_example_Core1/src/rpmsg_echo_example_Core1.c#L44
Linux kernel waiting for this structure to be at fixed memory address and if its changed driver will still read same Linux driver expected address. Does same issue between Debug/Release builds is seen with rpmsg-examples?
As far as I can see. That structure is located at a fixed address.
I will share a snippet of code.
Following the rpmsg-echo-example, the addresses set in the resource table for ARM-SHARC0 and ARM-SHARC1 are separated by an offset value (0x400).
In the SHARC0-SHARC1 communication, a different offset value (0x800) is set.
#define ADI_RESOURCE_TABLE_SHARC1_OFFSET (0x400) //1KiB
#define ADI_RESOURCE_TABLE_SHARC2_OFFSET (0x800) //2KiB
ARM-SHARC0, ARM-SHARC1
case ADI_CORE_SHARC0:
// ARM-DSP
p_adi_resource_table = &___MCAPI_common_start;
p_resource_table = &p_adi_resource_table->tbl;
break;
case ADI_CORE_SHARC1:
// ARM-DSP
p_adi_resource_table = (adi_resource_table *)
((uint32_t)&___MCAPI_common_start+ ADI_RESOURCE_TABLE_SHARC1_OFFSET);
p_resource_table = &p_adi_resource_table->tbl;
break;
SHARC0-SHARC1
// DSP-DSP(master)
p_adi_resource_table_sharc = (adi_resource_table *)
((uint32_t)&___MCAPI_common_start + ADI_RESOURCE_TABLE_SHARC2_OFFSET);
memcpy((void*)p_adi_resource_table_sharc, (const void*)&resource_table_local_sharc, sizeof(adi_resource_table))
// DSP-DSP(remote)
p_adi_resource_table_sharc = (adi_resource_table *)
((uint32_t)&___MCAPI_common_start + ADI_RESOURCE_TABLE_SHARC2_OFFSET);
p_resource_table_sharc = &(p_adi_resource_table_sharc->tbl)
Linux kernel remoteproc driver expects resource tables for rpmsg communication to be at SHARC1 0x20080000 and SHARC2 0x20080400 addresses. If those are changed need to add appropriate changes to the device tree.
The offset value in the code pasted in the snippet was incorrect.
I set ADI_RESOURCE_TABLE_SHARC1_OFFSET to 0x0400, a channel between ARM and SHARC will be created.
Maybe I'm misunderstanding, is there no need to consider another offset value for communication between SHARC0-SHARC1?
Hi ARM<->SHARC cores need to match address that they use for RPMsg communication if you change those need to reflect those changes in Linux device tree also here is the table where those defined https://github.com/analogdevicesinc/lnxdsp-linux/blob/main/arch/arm/boot/dts/sc58x.dtsi#L197
addresses for SHARC0-SHARC1 communication needs to not be shared with Linux, anything inside boundaries of not shared with Linux should be good.
sram_B1_unused@20000800 {
reg = <0x20080800 0x3800>; /* <128 KiB*/
no-map;
};
I used the URL you shared as a reference.
Communication is now possible by using an offset (0x800) to point the above address in the resource table used for SHARC0-SHARC1 communication. The new address uses ___MCAPI_common_start + 0x800.
Thank you.
Please log in to reply.