Hi,nxp:
I'm having trouble debugging ipcf. The version compiled using the S32DS can communicate with the A core.
But when I use gcc cgwing build M core sample can't communicate with A core.I have check the code is same with S32DS exsample.also I sure the config for ipcf is no problem.M core init is success but can't get the remote pool data.
I have make test.In M core sample,I write a fixed value at an address in shared memory,the read this address in A core,but I can't get the value write in M core,and vice versa.so i want to ask is there any other configure ?
root@s32g399ardb3:~# echo 10 >/sys/kernel/ipc-shm-sample/ping
root@s32g399ardb3:~# [ 1830.701340] ipc-shm-sample: starting demo...
[ 1830.701351] ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10
[ 1830.701368] ipc-shm-dev: ipc_shm_acquire_buf(): No free buffer found in channel 1
[ 1830.701372] ipc-shm-sample: send_data_msg(): failed to get buffer for channel ID 1 and size 32
The pop ring write read is 0,but in M core sample read is 5, after ipcf_init().
Thanks.
Solved! Go to Solution.
Hi,
Maybe we don't fully understand the scope of your application. We are looking into the Linker file that is provided on the IPCF (non-multi) examples, and we see that the 0x34600000 is being taken by the int_sram_c3 declaration, for which might be the problem you are seeing.
Again, might be that we are not understanding the general implementation.
If you modified the linker file as needed, did you change the structures/address on the IPCF application running on the A/M7 core? Given that the sample that is provided assumes no modifications are done to the linker itself, the A/M7 core uses a predefined address on the peripheral itself. Below will be the configuration for the M7 core on the S32G2 implementation:
Is this also being modified?
Please, let us know.
Hi,
At this moment S32G3 is still under control of distribution, hence we cannot provide much information on the public community. Please, help us either with creating a ticket or sending this inquiry to your local NXP representative/FAE for them to use the appropiate channel.
As for general information for the IPCF, given that the S32DS application is working, we can only recommend to verify the flags that S32DS is using on the compilation and linking steps.
Have you verified with a simpler application? to confirm that using your setup does indeed have the expected outcome.
Please, let us know.
Hi Nxp:
My question is why the content written in M core in my shared memory cannot be read by A core, and the content written in A core cannot be read by M core.It looks like you're operating on two separate pieces of memory.The test code looks like this:
In M core after ipcf_init(), before remote_is_ready:
*((uint32 *)0x34100008) = 0xA5A5A5A5
In A core:
before ipcf_init():
addr = (uint32_t *)ioremap(0x34100008, 4);
shm_err("0x341000008:%x\n", *addr); //printk 0
So, for shared memory operations, do we need any configuration on the M core? Want to be shareable or cacheable_not?
Hi
I found that the partitioning of the SharedRAM in the link file caused, once I split the SharedRAM, then the A-core and M-core operations in this segment of memory looked as if they were independent.
I did A test, first use the default link file, partition SharedRAM address is 0x34000000, size 2M, then M core to write 0x34600000 address, in A core read the address out the correct value. Then I changed the partition of SharedRAM in the link file to 0x34600000, the size of 2M, and then read the content of 0x36000000. The A core could not read the value written by the M core.
SharedRAM (RW) : ORIGIN = 0x34000000, LENGTH = 0x00200000 /* 2MB */
So why?Do you have any suggestions
Hi,
Maybe we don't fully understand the scope of your application. We are looking into the Linker file that is provided on the IPCF (non-multi) examples, and we see that the 0x34600000 is being taken by the int_sram_c3 declaration, for which might be the problem you are seeing.
Again, might be that we are not understanding the general implementation.
If you modified the linker file as needed, did you change the structures/address on the IPCF application running on the A/M7 core? Given that the sample that is provided assumes no modifications are done to the linker itself, the A/M7 core uses a predefined address on the peripheral itself. Below will be the configuration for the M7 core on the S32G2 implementation:
Is this also being modified?
Please, let us know.
Hi,
I solved it.
very thanks.
Hi,
I have trouble in IPCF communication between A53 and M7. I am using s32g hardware.
From this link, i have built the modules manually- git clone https://source.codeaurora.org/external/autobsps32/ipcf/ipc-shm/
Copied these ipc-shm-dev.ko, ipc-shm-sample.ko and ipc-shm-uio.ko files to board.
In uboot level, i have executed the below commands, [IPCF_Example_S32G274_M7_0.bin downloaded from NXP]
=> dcache off
=> mw.q 0x34000000 0x0 0x100000
=> fatload mmc 0:1 0x80000000 IPCF_Example_S32G274_M7_0.bin
=> cp.q 0x80000000 0x34300000 0x60000
=> startm7 0x34401000
Starting CM7_0 core at SRAM address 0x34401000 ... done.
=>boot
Board is booted and able to load the modules as shown below:
root@ubuntu-s32g274ateraaceubuntu:/home/bluebox# insmod ipc-shm-dev.ko
root@ubuntu-s32g274ateraaceubuntu:/home/bluebox# insmod ipc-shm-sample.ko
root@ubuntu-s32g274ateraaceubuntu:/home/bluebox#
While sending the message it is failed:
root@ubuntu-s32g274ateraaceubuntu:/# dmesg -c > /dev/null
root@ubuntu-s32g274ateraaceubuntu:/# echo 10 > /sys/kernel/ipc-shm-sample/ping
root@ubuntu-s32g274ateraaceubuntu:/# [ 2392.119337] ipc-shm-sample: send_data_msg(): failed to get buffer for channel ID 1 and size 16 root@ubuntu-s32g274ateraaceubuntu:/# dmesg -c
[ 2392.119301] ipc-shm-sample: starting demo...
[ 2392.119326] ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10
[ 2392.119337] ipc-shm-sample: send_data_msg(): failed to get buffer for channel ID 1 and size 16
root@ubuntu-s32g274ateraaceubuntu:/#
Can you please help me. Thanks in advance.
- Disable Data Cache from uboot::
dcache off
- Zero-set SRAM shared memory used by both sample apps::
mw.q 0x34000000 0x0 0x100000
- Load binaries in DDRAM and after is SRAM::
fatload mmc 0:1 0x80000000 IPCF_Example_multi_instance_S32G399_M7_0.bin
cp.q 0x80000000 0x34100000 0x30000
fatload mmc 0:1 0x80000000 IPCF_Example_multi_instance_S32G399_M7_1.bin
cp.q 0x80000000 0x34200000 0x30000
- Start M7 core (the argument is the address of the Interrupt Vector)::
startm7 0x34181000
- Boot Linux :