multicore boot problem

[shanlan123]

我在学习文档《AN13750-EnablingMulticoreApplicationOnS32G2UsingS32G2PlatformSoftwareIntegrantion》，有如下问题：

1 这个文档里面说IPCF组件里面有3个例子（M7_0、M7_1、M7_2各一个），但是我下载的IPCF组件里面只有2个例子（M7_0和M7_1的）。（IPCF组件版本号与文档里一致）
2 我发现M7_0和M7_1编译完后，内存加载地址、程序入口地址与文档上的不一样，并且M7_0的地址与fip.bin的地址有重叠。请问这个问题应该怎么处理呢？

3 每个核的app都会配置一个程序入口地址，M7_0核是在map文件里搜索Reset_Handler来找入口地址，M7_1核是在map文件里搜索intc_vector来找入口地址，我不清楚为什么2个核搜索的关键字不一样

[Daniel-Aguirre]

Hi,

Could you help us putting this inquiry in english? At this moment, the main support for S32G family is being done in english.

We do apologize for the inconvenience.

Please, let us know.

[shanlan123]

I am studying the document <AN13750-EnablingMulticoreApplicationOnS32G2UsingS32G2PlatformSoftwareIntegration>, and have the following questions:

1 This document says that there are three examples in the IPCF package (M7_0, M7_1 and M7_2 each), but there are only two examples in the IPCF package I downloaded (M7_0 and M7_1). (IPCF package version number is consistent with that in the document)

2 I found M7_ 0 and M7_ 1 After compilation, the Load image address and Reset handler address are different from those in the document, and The address of M7_0 overlaps with that of fip.bin. How should I deal with this problem?

3. Each core app will be configured with a Reset handler address by EB Tresos, M7_ 0 core search the key word Reset_Handler in the map file to get the value of `Reset handler address`, M7_ 1 core search the key word intc_vector in the map file to get the value of `Reset handler address`. I don't know why the keywords of the two core searches are different

[Daniel-Aguirre]

Hi,

Below will be some comments for your questions:

Q1 >> This document says that there are three examples in the IPCF package (M7_0, M7_1 and M7_2 each), but there are only two examples in the IPCF package I downloaded (M7_0 and M7_1). (IPCF package version number is consistent with that in the document)

A1 >> That is because the examples that the AN13750 is referring to are the ones provided on the AN13750SW. This is available under the S32G2 product page (link: S32G2 Safe and Secure Vehicle Network Processor | NXP Semiconductors). Below will be a picture of this:

Q2 & Q3 >>  I found M7_ 0 and M7_ 1 After compilation, the Load image address and Reset handler address are different from those in the document, and The address of M7_0 overlaps with that of fip.bin. How should I deal with this problem? Each core app will be configured with a Reset handler address by EB Tresos, M7_ 0 core search the key word Reset_Handler in the map file to get the value of `Reset handler address`, M7_ 1 core search the key word intc_vector in the map file to get the value of `Reset handler address`. I don't know why the keywords of the two core searches are different

A2 & A3 >> Given the projects are different from the ones you are using, could be that these 2 questions are answered by using the provided examples.

Please, let us know.

[shanlan123]

thank you, but I still have question about Q3:Each core app will be configured with a Reset handler address by EB Tresos, M7_0 core search the key word Reset_Handler in the map file to get the value of `Reset handler address`, M7_1 core search the key word intc_vector in the map file to get the value of `Reset handler address`, M7_2 core search the key word intc_vector in the map file to get the value of `Reset handler address`. I don't know why the keywords of the three core searches are different.

And I have a new question Q4:How to solve the resource conflict between M7 core and A53 core?Do you have any documents about this?

[Daniel-Aguirre · Accepted solution]

Hi,

The difference should be related to the M7_0 core being previously initialized by the BootROM to generate the initial configuration. This is, M7_0 is already initialized prior to the other M7_1 and M7_2, hence there is no need of set the entry pointer to the interrupt vector.

As for the additional question, can you elaborate more on the "solve the resource conflict between M7 core and A53 core"? The resource management between the M7 cores and the A53 clusters should be defined prior to the start of the application itself, to prevent undefined behavior:

"Assuming that there is a multi-core application for M7_0 and A53 clusters, customer should well plan what modules are controlled by M7_0, what modules are controlled by A53 etc. For the modules used by both M7_0 and A53 clusters, such as clock-related modules (FXOSC, PLL etc.), should avoid these modules being configured from both sides. Otherwise, the system will become unstable, or even resets due to improper configuration operations."

Please, let us know.

[shanlan123]

Thank you. You have solved my problem.
If you could provide me with relevant documents for Q4, I would appreciate it very much.

[Daniel-Aguirre]

Thanks for your feedback.

The quoted comment was not inside a document, was a comment from one of our internal team members. We do apologize for it.

Please, let us know.