AM623: secure boot issues

Hi Li,

Please attach the full console log including the previous successful boot from U-Boot.

The following are the corresponding logs：

安全启动卡住log.txt

Reboot was triggered by me in the script, with the aim of allowing the system to return to restart. However, during this repeated restart, we found that there was an error in the secure boot process.

The above are the test results of hot start，In addition, we repeated the cold start experiment and tested it more than 50 times. Occasionally, there may be one or two safety start errors

Hi Li,

I think I am confused. Can you please point me the exact line of the message showing the issue which you refer to?

The area circled in red in the following image：

Hi,

You mentioned in your first post above that the system stopped four about 2~3 minutes then automatically restart again.

Does it stop at the point when the highlighted error happens? After automatically restarted, the system will boot properly from U-Boot to Linux, is it correct?

''Does it stop at the point when the highlighted error happens? ''

-- yes

''After automatically restarted, the system will boot properly from U-Boot to Linux, is it correct?'

-- yes， as you described

Hi Li,

That -110 error message basically means the TI-FS  firmware is crashed. I will ask our sw dev team about the issue, but meanwhile, can you please test with the latest Processor SDK9.1 to see if the issue still happens on your board?

At present, our product is preparing for production and the project is a bit rushed. We do not have time to adapt to the 9.1 SDK at the moment. We would like to ask TI's experts to help analyze the reasons based on the PROCESS SDK SDK SDK SDK-LINUX RT-AM62X-08.06.00.42

Hi Li,

I will discuss this with our sw dev team and will get back to you once I have an update.

Hi Liu,

May I ask if the TI expert has responded to this question?

Hi Li,

We would need to capture the TI-FS firmware debug trace to understand the issue. The TI-FS firmware debug trace can be retrieved from MAIN UART1. Does your board have access to MAIN UART1?

Hi Liu,

My motherboard can access Main UART1, how can I perform a trace via Main UART1?

Hi Li,

- In your SDK8.6 installation directory, remove the following directory so that we can re-generate them with debug enabled.

<SDK>/board-support/k3-image-gen-2022.01/out

- Apply the following patch to the SDK Makefile to enable sysfw debug (it adds ENABLE_TRACE=1 flag):

--- Makefile.orig       2023-09-01 09:46:10.777766554 -0500
+++ Makefile    2024-03-27 15:07:44.617133371 -0500
@@ -376,7 +376,7 @@
        @echo    Building SYSFW Image
        @echo =============================
        @cd board-support; cd `find . -maxdepth 1 -type d -name "*k3-image*"`; \
-               make SBL=$(SBL_PATH) $(SYSFW_MAKEARGS) CROSS_COMPILE=$(CROSS_COMPILE_ARMV7) PATH=$(PATH):$(LINUXKERNEL_INSTALL_DIR)/scripts/dtc SOC_TYPE=$(DEVICE_TYPE_SEC)
+               make ENABLE_TRACE=1 SBL=$(SBL_PATH) $(SYSFW_MAKEARGS) CROSS_COMPILE=$(CROSS_COMPILE_ARMV7) PATH=$(PATH):$(LINUXKERNEL_INSTALL_DIR)/scripts/dtc SOC_TYPE=$(DEVICE_TYPE_SEC)
 
 sysfw-image_clean:
        @echo =============================

- Run command 'make u-boot-r5 sysfw-image' to rebuild tiboot3.bin.

- Copy file <SDK>/board-support/k3-image-gen-2022.01/tiboot3.bin to your SD card boot partition (if you boot from SD card).

- Open the MAIN_UART1 port of your board to be ready to capture its output.

- Boot the board and run the test case to trigger the error.

- When the issue happened, you need to stop capturing MAIN_UART1 debug trace before the 3min timeout reboot, so that the last portion of the trace log is relevant to the TI-FS firmware -110 error.