S32G399A-RDB3 Multi-core boot failed, following AN13750

superyyf · ‎11-06-2023

Dear NXP,

I want to run IPCF multi-instance demo on s32g399a-rdb3 development board, referring to AN13750 documentation. I can now trace the M-core program with Lauterbach, but the A-core is not booting properly. My configuration and debug process is as follows:

1. bootloader config
Since the sram mapping address of the m7_1 app overlaps with fip.bin, only one m7 application has been added for convenience

core config:
boot source config：

ivt image config

2. m7_app config

3. a53_app config
change fip.pin align to 64

4. debug phenomena

1. run cmm script, reset target, the program stop at main function,

2. and then Var.set ENABLE_BREAKPOINT_AT_MAIN=1, bootloader run in a loop

3. load m7_app.elf, i can trace the program, i think m core app is running fine.

4. but a53_app is no response, no log print on uart, i try to debug with Lauterbach, the phenomena is confused me. the memory of global var <bootApplications> is all zero. After some instructions, the buseror appeared

Can you give me some suggestions on how to proceed with the next step of debugging?

superyyf · ‎11-08-2023

I finally figured it out. it is about the IVT Application bootloader configure.

At the first time, i think RAM start pointer should be int_sram address, RAM entry pointer should be Reset_Handler address, the same as bootloader configure about how to lead m core app. the document is also ambiguous.

But it is a mistake, RAM start pointer should be int_sram_no_cacheable address, RAM entry pointer should be intc_vector address, according to bin file layout and BootRom's behavior.

Can you help me explain why there is such a entry address difference between BootRom jumping to Bootloader and Bootloader jumping to the app?

And I think this should be reflected in the documentation.

View solution in original post

Daniel-Aguirre · ‎11-07-2023

Hi,

Which BSP version are you using? Which IPCF version are you using?

Are you changing your uboot/ATF to use an alignment of 64? Can you boot your RDB3 with the modified files? We refer to the change of the "fip.s32" file. Can you boot the A53_0 core with the fip.bin file? We refer to using it as Application Bootloader under the IVT.

The IPCF examples provided for M7 core under S32G3 show under the "description.txt" file the expected boot sequence, where the loading of the M7 binary is through u-boot and not through the Bootloader. Looking into the linker of the IPCF S32G3 examples and the linker provided under the AN13750SW package, we see a difference that might be causing the problem.

Have you tried using a simple blink example with the AN13750SW linker to understand if you can load both application through a bootloader? As a first step.

We do apologize for the inconvenience that these questions may cause.

Please, let us know.

superyyf · ‎11-07-2023

Hi Daniel ,

the version information is as follows:

BSP 35

IPCF 4.8.0

I already change atf to use an alignment of 64.

I can boot RDB3 from sd card with modified atf.

I can boot A53_0 from norflash with Application Bootloader under the IVT.

I have tried to replace linker in S32G3 exapmle with the linker provided under the AN13750SW package, but A53 core still boot failed.

I also tried to remove m7 app, let bootloader only boot the fip.bin, it failed, so i guess may be something wrong between bootloader and fip.bin.

----------------------

Consistent with the previous debug, the global variable <bootApplications> has 0 data at address 0x3533309C in SRAM, and then I checked the relative offset addresses of the norflash and bin files, and the data is all 0. The problem seems to be in the build phase of the bootloader.

More detailed configuration of the bootloader is as follows:

1. I disabled Crypto, CryptoDal, Rm module

2. I delete some related init and deinit function

--------------

By analyzing the bin file and map file, we found that the bin file start address is 0x35300000 (int_sram_no_cacheable pointer) instead of 0x35320000 (the reset_handler pointer & int_sram pointer). This is not consistent with what is described in the documentation, how should I configure the ivt image.

Daniel-Aguirre · ‎11-08-2023

Hi,

We understand that you are using 0x35200000 for load/entry address under your IVT, is this correct?

Can you help us sharing your IVT structure? To understand how you are creating the IVT.

Also, seeing the steps that you are showing, have you also disabled Secure Boot?

Since you removed Crypto module and can proceed with the build, we assume you disable it. Also, did you remove the SW breakpoint? Or did you add the corresponding code shown under AN13750?

Mainly the change of the macro, since you seem to not be using HSE.