Not able to program SHARCs through remoteproc utility after doing and upgrade from buildroot (kernel 4.0.0) to yocto (5.15.168) based build.

Any reason to upgrade to 3.1.2 rather then latest 5.0.1?

None in particular. It's just that when this migration activity was started last year, 3.1.2 was the latest available, I believe.

An Update on the above:
I tried the upgrade with 5.0.1 and still face the same remoteproc issue. Let me know if any further details are needed.

If anyone has any more sugggestions or fixes that I can try, those are most welcome and appreciated.

Thanks

you need to go over the your device-tree and mark what peripherals are used and configured, in this case what is on DMA channel 43? Are you using it from SHARC or its configured in Linux or u-boot?

Are you using rpmsg ? MCAPI not supported. 

What addresses in L2 you allocated for SHARC? 

Thanks for your response. Here are the details and some follow up questions I have:

I see in the linux device tree that DMA channel 43 is configured as mdma, which the kernel driver identifies as dma with memcpy. It is being used from kernel driver for remoteproc to load the sharc code, as per my understanding (I haven't deviated from the adi settings here).

The legacy SHARCs use MCAPI. Do you suggest that they should be migrated to use rpmsg, in order for communication between the A5 and SHARCs to work, once the loading is successful?
I see that there is a device tree node in the default .dts file for the adsp-sc573, with the following headers:

&tru {
mcapi_to_a5: channel@0 {
...
};
mcapi_to_sharc0: channel@1 {
...
};
mcapi_to_sharc1: channel@2 {
...
};
};

Is there any way to utilise that for communication? And could this cause the loading issue mentioned earlier?

These are the L2 addresses allocated for SHARCs in my legacy image:
Core1: <0x200C0000 0x20100000>

Core2: <0x20080000 0x200C0000>

Let me know if any further details are needed.

Thanks

So default ADSP Linux release moved from MCAPI to RPMsg as its supported by kernel by default. And addresses that are in current device tree are default fro vring's that Linux RPMsg and SHARC side rpmsg-lite could communicated. Unfortunately you must have rpmsg-lite initialised on SHARC-side that remoteproc can complete load of firmware. It will wait till rpmsg vring structure on SHARC side is initialised. The addresses where you map memories should be in sync in device-tree and in SHARC baremetal code.

So verify that values you mentioned, not colliding with vrings in device-tree on SHARC side. And those addresses not utilised for anything else. 

Core1: <0x200C0000 0x20100000>

Core2: <0x20080000 0x200C0000>

This is simple baremetal example with simple echo example that utilises RPMsg github.com/.../echo_example
 

Hi,
Thanks for the suggestion.
I tried using the example code, you suggested, for echo test, to get a minimal communication between Arm and SHARCs.
But even with that I got the above mentioned dma issue:

remoteproc remoteproc0: powering up core1-rproc 

remoteproc remoteproc0: Booting fw image SHARC_Core1.ldr, size 152020 

adi-dma 3109b000.dma: DMA error on channel 43, stat = 0x3b400

I did a small change in the remoteproc kernel driver file (adi_remoteproc.c) to bypass the dma memcpy in the ldr_load function and do a memcpy_toio to the SHARC addresses. This got rid of the dma issue. And after that I got test rpmsg using the test steps mentioned in the documentation at: RPMsg · analogdevicesinc/lnxdsp-adi-meta Wiki

I am not sure if that is a proper solution, but the problem looks like the dma is somehow not able to access the SHARC addresses for the hardware I'm using (adsp-sc573). Any clarifications or suggestions regarding this are highly appreciated.

Let me know if any other details are needed.

Thanks