S32G3 boot hang in bsp37 on multiplecore boot environment

[Allen_Cheng]

Hi NXP team,

I followed Application Note(AN13750) and  enable multiplecore boot environment on S32G-RDB3 successfully.

I have met an issue that BSP35 can boot into Linux login stage but BSP37 hanged every times.

Attachment is my failed console log.

I only modified ATF makefile arm-trustedfirmware/plat/nxp/s32/s32_common.mk :

`FIP_ALIGN := 16` change it to `FIP_ALIGN := 64`

And rebuild the atf then use it's fip.bin and fip.s32.

Could you please help supply some suggestions?

Thanks.

[Daniel-Aguirre]

Hi,

Which "Integration Reference Examples" package version are you using? Can you boot from the A53_0 directly with the IVT using the fip.bin as application bootloader?

The modification should be fine, since it is required by the bootloader.

Please, let us know.

[Allen_Cheng]

Hi Daniel,

My version is Integration_Reference_Examples_S32G3_2022_06 and I try to use sd-boot with the rebuild fip.s32. The result is the same as qspi-boot.

As far as I know, sd-boot is A-core boot not related the bootloader(multiplecore boot).

Can you boot from the A53_0 directly with the IVT using the fip.bin as application bootloader?

I will do the experiment later.

Thanks.

Allen.

[Daniel-Aguirre]

Hi,

If re-writing the fip.s32 does not provide a successful boot then it seems that there were errors when compiling. How are you re-writing the fip.s32 file?

Have you confirmed that with only re-writing the fip.s32 under BSP35 you have the same behavior?

We are not seeing any problem on regards of re-writing the fip.s32 file from our side:

Please, let us know.

[Allen_Cheng]

Hi Daniel,

What do you mean "re-writing the fip.s32"?

I try to flash the ivt_blob(0x00000), fip.s32(0x100000) and main.bin(0x200000) but RDB3 can't boot successfully.

If you mean re-writing the fip.s32 to sd-card, I have done the experiment.

sd-boot will success in bsp35 but fail in bsp37.

The failure means it can boot into Linux but hanged on below message:

[ 0.630364] 401cc000.serial: ttyLF1 at MMIO 0x401cc000 (irq = 46, base_baud = 7812500) is a FSL_LINFLEX
[ 0.640159] 402bc000.serial: ttyLF2 at MMIO 0x402bc000 (irq = 67, base_baud = 7812500) is a FSL_LINFLEX
[ 0.651120] s32cc_fccu 4030c000.fccu: FCCU status is 0 (normal)

Thanks.

Allen

[Daniel-Aguirre]

Hi,

fip.s32 should not be the file to be flashed inside the NOR Flash, should be fip.bin.

The following is told under the AN13750:

The fip.s32 file should be rewritten/replaced inside the SD image, as told under the AN13750:

Please, let us know.

[Allen_Cheng]

Hi Daniel,

Thanks for your reply.

I am sorting my question.

I can use the official release fip.s32 re-wrinting to sd-card and bootup into Linux login command line successfully with bsp35 and bsp37.

When I modified ATF makefile arm-trustedfirmware/plat/nxp/s32/s32_common.mk :

`FIP_ALIGN := 16` change it to `FIP_ALIGN := 64`

And rebuild it then re-writing to sd-card.

bsp35 can bootup into Linux login command line but bsp37 can't bootup into Linux login command line that handed on below messages:

[ 0.630364] 401cc000.serial: ttyLF1 at MMIO 0x401cc000 (irq = 46, base_baud = 7812500) is a FSL_LINFLEX
[ 0.640159] 402bc000.serial: ttyLF2 at MMIO 0x402bc000 (irq = 67, base_baud = 7812500) is a FSL_LINFLEX
[ 0.651120] s32cc_fccu 4030c000.fccu: FCCU status is 0 (normal)

Thanks.

Allen

[Daniel-Aguirre]

Hi,

No problem. Also, let us know if we are misunderstanding any information you have provided.

For this last message, we understand you are modifying the "fip.s32" file under your SD card with the following command:

Once you set your board to boot from the SD card, under BSP37, you are prompted with the error you are showing, is this correct?

If so, by just modifying the "fip.s32" on our side, as per the image above, we can successfully boot BSP37 no problem. We flash the NXP provided BSP37 images and then proceed to modify the "fip.s32".

Is this the same steps you are following? If not, can you verify if with our steps you can successfully boot your BSP37 image?

Please, let us know.

[Allen_Cheng]

Hi Daniel,

I have retest bsp35 and bsp37 again and the result is the same.

Once you set your board to boot from the SD card, under BSP37, you are prompted with the error you are showing, is this correct?

Allen:Correct.

If so, by just modifying the "fip.s32" on our side, as per the image above, we can successfully boot BSP37 no problem. We flash the NXP provided BSP37 images and then proceed to modify the "fip.s32".

Allen: You can modify ATF and rebuild it then re-writing to reproduce

makefile arm-trustedfirmware/plat/nxp/s32/s32_common.mk :

`FIP_ALIGN := 16` change it to `FIP_ALIGN := 64`

It's okay in bsp35 but not okay in bsp37.

Thanks.

Allen

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

Allen: You can modify ATF and rebuild it then re-writing to reproduce

We have modified the FIP_ALIGN variable and rebuilt the ATF, but were not prompted with the message you have shared. We shared the images some time ago with our results.

Again, this if our boot is directly from the SD card (M7_0 not involved explicitly).

Also, you are saying the following: 

It's okay in bsp35 but not okay in bsp37.

For which we have a question, are you using the same BSP35 image? Or are you also changing the image to a BSP37 one? Are you flashing the image each time that you modify the "fip.s32" file?

Please, let us know.

[Allen_Cheng]

Hi Daniel,

For which we have a question, are you using the same BSP35 image? Or are you also changing the image to a BSP37 one? Are you flashing the image each time that you modify the "fip.s32" file?

When I test BSP35(BSP37), I will flash the BSP35(BSP37) official image and the fip.s32 of rebuilt bsp35(bsp37).

I have tested BSP38 additionally and it's Okay.

Thanks.

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

Again, it seems to be a problem with the generated "fip.s32" from your side, since we are not able to reproduce the behavior you are seeing under BSP37.0. We can flash BSP37.0 and replace the "fip.s32" under the SD card and boot no problem. Again, we apologize.

We can recommend cloning again the repo's and selecting the corresponding branch then generating the "fip.s32" again, could be that when cloning the repo there was a problem.

Please, let us know.

[Allen_Cheng]

Hi Daniel,

I have cloned the u-boot and atf repo again and still got the same result.

But I found a solution by reference bsp38 user manual.

According to the official document "Linux BSP 37.0 User Manual for S32G3 platforms", the build atf command is:

Hi Daniel,

I have cloned the u-boot and atf repo again and still got the same result.

But I found a solution by reference bsp38 user manual.

According to the official document "Linux BSP 37.0 User Manual for S32G3 platforms", the build atf command is:

But the plat parameter in bsp38 user manual is s32g399ardb3.

When I modified the parameter from s32g3xxaevb to s32g399ardb3, the hanged issue was gone. 

Not sure it's a solution or work around but I can solve my problem.

Thanks.

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

Since you are working with and RDB3 platform, you require for the <plat> option put the platform you are using, which is s32G399ardb3. We missed this question which could have solved the issue from the beginning. We do apologize.

Please, let us know.