Inquery about "Bus Error" occurring during user-level IPCF prgram operation.

[seungtake]

Hi all.

I am testing a user level IPCF program on the s32g399ardb3 board.
My development environment is as follows:
   - BSP : bsp43.0-6.6.52-rt
   - IPCF : SW32R45_IPCF_4.6.0_D2409

The original example focused on communication between Mcore and Acore, but i modified it.
My modifications are shown in the attached diff file. The changes allow for Acore to Acore communication while maintaining the same messsaging framework.

For kernel module, i have confirmed that operate normally regardless of ipc_cfg changes. However, at the user level, bus errors conitnuously occur unless delay are added using __sync_synchroize() or printf() in the ipc_memcpy_from_io_function.

As i understand, bus erros can occur when accessing SRAM regions used as shard memory without proper 8byte alignment. However, I believe NXP`S example properly handel this by using stack variables to ensure precise 8-byte aligned access. 

Could you please explain other possible causess of bus errors in this context??

Thank you.

[chenyin_h · Accepted solution]

Hello, @seungtake 

Thanks for your reply.

I am not sure of the reason of your method, from my experience, the IPCF is a software package, it could be initialized and used with various methods theoretically according to different requirements.

But from NXP's perspective, we provided two sample methods for using IPCF across M cores and A cores, the default one is the well described in the description.txt in the IPCF example directly(via U-boot), the second one is described in AN13750 with bootloader involved, there are only these two kinds of documents provided for using the IPCF on S32G2/G3, sorry that I do not see formal documents similar to your way.

Since the current discussion is a little beyond the original topic range, in order for best tracking the contents, if further discussion needed, I suggest raising new post on the S32G community.

Thanks for your understanding. 

BR

Chenyin  

[chenyin_h]

Hello， @seungtake 

You are welcome and thanks for you reply.

1. I am still not sure how you testing A53_0 and A53_1 correctly based on the patch you provided, seems the modifications done are not enough for implementing the functions you described.

2. Access the shared memory from Linux is to via the device memory, no cache involved, then I do not think the sync is actually required, there are not such kind of functions used in M core samples.

BR

Chenyin

[seungtake]

Hi @chenyin_h

I want to test IPCF using message transmission between M-core and A-core as per its original usage. I plan to use both M-core and A-core.

My planned approach is:

Generate the related code as .bin files using Design Studio
Create bl2_w_dtb.s32-sdcard using append-m7.sh in m7-sample
Build the final image using bitbake for fsl-image
Is this approach correct? Could you provide any examples or documentation for this kind of work?

Thank you.

[chenyin_h]

Hello, @seungtake 

Thanks for the reply.

I have looked into the patch you provided, seems only configuration file is modified,(plus some debug flags), however, from my understanding, the IPCF multi-instance example is originally one side of the whole messages transfer, the other side existed on M7 part.

By default, the instance 0 will send messages to M7_0, while instance 1 send messages to M7_1, etc.

If you only modified the default configuration, then the instance 0(maybe A53_0) may send message to A53_1, but no rx code from the A53_1 part implemented.

The IPCF lib could support message transferring from same kind of cores(like A53_0 and A53_1), but the IPCF examples are implemented between M7 cores and A53 cores on S32G, if you want to test with the same logic, then I suggest referencing the M7 part to implement RX side. it could be another program, and may not be simply modified from current example.

BR

Chenyin

[seungtake]

Hello, @chenyin_h

First of all, your explanation is correct. My ultimate goal is communication m core and a core, but since the m core is not yet operational, i first tested whether the IPCF example works properly between a-cores to verify the basic functionality before further implementation.

In the modified configuration, A0 and A1 communicate: A0 sends a message, and A1 simply prints it to the console. (As I recall, the original example was a ping-pong exchange with M0.)

In this modified example:
A0 writes data to SRAM and sends an interrupt to A1.
A1 reads the SRAM and prints the output to the console.

My question is: When the A-core reads data from SRAM, it seems to require synchronization functions like __SYNC (memory barriers) to work properly. Is this approach correct? If the original M0 communication example works without such barriers, I assume there should be no issues. Does the original M0 communication example operate without these synchronization functions?

Thank you!

[chenyin_h]

Hello, @seungtake 

You are welcome and thanks for the reply.

1. I understand that there are not much differences between tag SW32R45_IPCF_4.6.0_D2409 and S32G, but for better compatibility, I'd like to suggest using the SW32G_IPCF_4.10.0_D2405, which is the latest version of S32G.

2.  Usually, we support the IPCF between M cores and A cores, seldomly using it solely on the A53 side,(in your case, A53_0/1), sorry that I did not meet such issues before.

3. Adding __sync_synchronize() may avoiding possible alignment and/or cache coherency issues, let me check it and try reproducing it firstly from my side.

BR

Chenyin

[seungtake]

Hi, @chenyin_h

Thanks for your reply.

I tried running ipc-shm-sample_muti_instance_uio again using the IPCF version that you recommeded, but the same error stilll occurs. I will wait for your rest result.

Thank you!.
 

[chenyin_h]

Hello, @seungtake 

Thanks for your post. would you mind helping clarify the following:

1. From the patch shared, seems you want to implement an example between two A53 cores, right? Not sure of your test setup, there are different OSes running on different A53 cores?

2. I understand that the S32G3RDB3 is used in your test as described, but it is mentioned that "SW32R45_IPCF_4.6.0_D2409" is used, would you mind double checking with it? S32R is different from S32G.

BR

Chenyin

[seungtake]

Hi, @chenyin_h

First of all, thank you for your comment.

I would link to reply as follows.
1. Yes, I want to communicate between two A53 cores. Currently, all cores are running NXP`s Auto-Linux. Ultimately, the communication will be used with the M7, but for not, iam simply trying out communication between A53 cores for testing purposes.



2. Yes, I am using the S32G3RDB3 board and the IPCF version is SW32R45_IPCF_4.6.0_D2409.
It is the latest release version from offical GIT repository. After checking the internal code, I confirmed that it is implemented to support S32G3 hardware as well.
Therefore, when compiling, I add arguments to the makefile so that S32G3 hardware setting are enabled. (I have also verified that all kernel module are working properly)

Thank you.