S32G cannot boot the Linux system

[zhipeng]

The schematic of my custom board is similar to S32G-VNP-RDB2.

I am willing to booting the board via SD, According to the software startup guide document 《S32G-VNP-RDB2-SW-UG.pdf》, in the 'RUN Linux BSP On Cortex-A53 Cores' section, the BSP was written to the SD card,

But after power-on, there was no output on the UART.

May I ask:

1. Are the image file and burning method correct? Do I need any additional configuration or programming?

2. After startup, has the image file been successfully downloaded to DDR, and how can it be verified?

3. Has the file in DDR successfully started, and how can it be verified?

Thank you, looking forward to your reply.

[chenyin_h]

Hello, @zhipeng 

Thanks for your reply.

It is not for sure that the pre-built images could be compatible with your custom board, the software that booting M core and A core side are totally different, I suggest firstly add Debug information to the TFA(adding DEBUG=1 during the building), and then flashed it to your board, then check if there is any clues found.

As you mentioned, you may have tested it simple M7 demos on your custom board?

BR

Chenyin

[zhipeng]

Hello,Chenyin
Thanks for your reply.

I downloaded BSP42 and configured the environment and code according to the "S32G2_LinuxBSP_42.0_User_Manual.pdf".
During the TF-A build process, I added DEBUG=1 and generated the debug/fip.s32 file. According to the 4.1.1 "Setup an SD/MMC card" section, I copied all the necessary binary files to the SD card.
After powering on, the UART still did not output anything.
What other methods are there to find out the problem?

Additionally, as mentioned before, I was unable to successfully launch the M7 program using the SD card based on the "S32G-VNP-RDB2-SW-UG.pdf" document.
If I want to first try to start the M7 program by using the SD card, are there any methods that can help me debug it?

Thank you.

[chenyin_h]

Hello, @zhipeng 

Thanks for your reply.

1. If possible, would you mind sharing the operation log you built and flashed to the SD card?

2. Before any of the UART output, there would be also a long path to run the code in TFA, have you checked the register values(PC, etc) for the current status? have you confirmed that the code is really running on your custom board?

3. For M7 side, may I know if you have the debugger to directly load the elf under serial mode? 

BR

Chenyin

[zhipeng]

Hello,Chenyin
Thanks for your reply.

Responding to your three questions:

1. I saved the terminal text of the Ubuntu system into a file named "Operation_Log.txt", including the building and Setup SDcard.

2. I haven't checked the register values yet because I'm not quite sure how to do it. Could you explain it in more detail? Or are there any documentation available that can guide me?

3. I have a "S32 Debug Probe" debugger. I can run some M7 programs in debug mode within the S32DS software. Currently, I have only run the routines according to the documentation and have not yet started the code development.

[chenyin_h]

Hello, @zhipeng 

Thanks for your clarification.

1. Since you have done some test running on your board with S32 debug probe, I think your board could at least working normally without DDR.

2. So the current issue is to bring up Linux BSP on your board via A53 side, may I know where you attached the "Operation_Log.txt" mentioned? I would like help to check it first.

If it is not convenient for you to share the custom information, feel free to tell me and I will create private case to support your issue directly

BR

Chenyin

[zhipeng]

Sorry, when I replied last time, I had already uploaded the file, but it seems to have disappeared.
I'll try uploading it again.

[chenyin_h]

Hello, @zhipeng 

Thanks for the log

I suggest directly flashing the fip.s32 to your SD card for a test to check if there are logs shown.

Just use: "sudo dd if=fip.s32 of=/dev/sdb; sudo sync"

Then check if there are any prints from your UART0

BR

Chenyin

[zhipeng]

Hello,Chenyin
Thanks for your reply.

I attempted to directly burn the fip.s32 onto the SD card, but there was still no output from UART0.

Additionally, I also attempted to write the code to the norflash using the S32 Flash Tool software. I set the boot mode to Serial. After clicking OK, the error shown on the image appeared.
So, the download using the serial mode also failed.

I used an oscilloscope. After clicking OK, I noticed that the waveforms of TXD and RXD had changed, but the software still showed an error.
Is this phenomenon helpful for analyzing the problem?

Thanks.

[chenyin_h]

Hello, @zhipeng 

Thanks for your reply.

From previous reply, you mentioned that you could run M7 application correctly, but currently you mentioned flashing to QSPI would fail, so that you only run the M7 application with debugger? not successfully run them via QSPI?

BR

Chenyin

[zhipeng]

Hello,Chenyin
Thanks for your reply.

So far, neither the A5 nor the M7 can be automatically started.

After writing to the SD card and powering on, there was no reaction. When writing to the QSPI, it showed failure.

I could only connect the debugger and use the debug function in the S32DS software to run the M7 program , as shown in the picture.

 

[chenyin_h]

Hello, @zhipeng 

Thanks for your reply.

Sure, I understand the status, since flash tool could not work correctly to flash the binary to the QSPI, may I know if it is possible for you to flash the binary using the debugger?

A reference method is shown below:

https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-JTAG-Flash-Programming-with-S32...

BR

Chenyin

[zhipeng]

Hello,Chenyin
Thanks for your reply.

I followed the above method and used the debugger to flash the binary file.
I started the flash and clicked Debug. It showed an error, as shown in the picture.

[chenyin_h]

Hello, @zhipeng 

Sorry for response late.

Well, you will encounter the same issue when using the debugger to flash the QSPI?

Since you are able to load the elf to the SRAM, you may try loading the flash example code from RTD to test the QSPI on your board.

If still issues, I suggest directly replying the mail I sent this week, to leave your information there, I would help to create a private case and continue the supporting.

BR

Chenyin

[chenyin_h]

Hello, @zhipeng 

Thanks for your post.

1. The document is right, but it is with very early version software(BSP28), I suggest checking your new board with related new version BSPs, like 42 or even newer, the basic usage could be checked from the corresponding BSP UM.

2. When using the BSP to boot the board, for example, booting via SD, the TFA image(A53 bootloader) would be moved from SD to SRAM, then to DDR, there would be logs/debug prints to show the stage of each part

In summary, I suggest first trying your custom board with newer version BSP, not sure if your board is much different from the RDB2/EVB. If it is similar, maybe the prebuilt image could also be available for your board, if not, you have to apply certain modifications yourself on the default BSP code to boot your custom board correctly.

BR

Chenyin

BR

Chenyin

[zhipeng]

I burned the SD image from the S32G2_LinuxBSP_44.0_binaries.tgz file into the SD card, but the same problem occurred.

[chenyin_h]

Hello, @zhipeng 

Thanks for your post.

So it is confirmed that the prebuilt images could not be used for booting your board according to the test, since it is targeted for RDB2

I understand that it is custom board, then currently you may need to modify the default TFA code to make it compatible with you new hardware.

I suggest working started from BSP42 or 43, since for BSP44, there are some DDR framework changes, which may be more complex than the previous version.

BR

Chenyin 

[zhipeng]

Hello,Chenyin
Thanks for your reply.
Our hardware board was designed based on RDB2. It should be possible to use the pre-built image, so I'm not sure what the problem is. Is there any way to determine if the hardware board is functioning properly?
I can use the S32-DP to debug the M7 program (compiled according to the "Light Up RGB LED Based On Real Time Drivers" section in the "S32G-VNP-RDB2-SW-UG.pdf" document), but it won't run after being burned onto the SD card.