• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 305 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM625: in SBL boot mode,linux reboot, can not be reset normally

AM625: in sbl boot mode，CCS compiled program has failed

yu chai
Prodigy 220 points
Part Number: AM625

1 I am testing the flash an example application function, in the ospi norflash, the test was successful .

2 I use the makefile compiled M core and R5 core programs and I run fine .

3 I use the CCS compiled M core and R5 core programs and I run fine .

4 I compared two files and found that programs of different sizes and in sbl boot mode cannot be compiled with CCS?

  • 0
    TI__Guru 70741 points

    Hi,

    yu chai said:
    4 I compared two files and found that programs of different sizes and in sbl boot mode cannot be compiled with CCS?

    I understood the first three points but not able to understand this last one. Could you please elaborate a bit more about this & if you have any logs to show the issue that would greatly help.

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 220 points

    1 reset_isolation.release.appimage.hs_fs is generated by makefile compilation .

    2 reset_isolation_am62x-sk_m4fss0-0_nortos_ti-arm-clang.appimage.hs_fs is generated by ccs compilation and they are not the same size and content.

  • 0 in reply to Prashant Shivhare
    Prodigy 220 points

    When burning cccs compiled files to norflash, the error log is shown in the figure:

  • +1 in reply to yu chai
    TI__Guru 70741 points

    Hi,

    Thank you for sharing the images & boot logs. It really helped as I could reproduce the issue & also identified the root cause.

    Root Cause

    The root cause of the issue is because of the incorrect authentication type being used in the CCS makefile (makefile_ccs_bootimage_gen). This makefile is using authentication type 1 (--authtype 1) instead of the expected authentication type 2 which all the SDK makefiles uses.

    Solution

    To resolve the issue, please do the following steps:

    - Delete the imported example from CCS.

    - Update the CCS makefile of Reset Isolation example by applying the following patch. This patch updates the authentication type from 1 to 2.

    diff --git a/examples/drivers/safety/reset_isolation/am62x-sk/m4fss0-0_nortos/ti-arm-clang/makefile_ccs_bootimage_gen b/examples/drivers/safety/reset_isolation/am62x-sk/m4fss0-0_nortos/ti-arm-clang/makefile_ccs_bootimage_gen
index 5376e94..957135d 100644
--- a/examples/drivers/safety/reset_isolation/am62x-sk/m4fss0-0_nortos/ti-arm-clang/makefile_ccs_bootimage_gen
+++ b/examples/drivers/safety/reset_isolation/am62x-sk/m4fss0-0_nortos/ti-arm-clang/makefile_ccs_bootimage_gen
@@ -83,15 +83,15 @@ else
 	$(MULTI_CORE_IMAGE_GEN) --devID $(SBL_DEV_ID) --out $(BOOTIMAGE_NAME) $(MULTI_CORE_IMAGE_PARAMS) >> $(BOOTIMAGE_TEMP_OUT_FILE)
 	$(MULTI_CORE_IMAGE_GEN) --devID $(SBL_DEV_ID) --out $(BOOTIMAGE_NAME_XIP) $(MULTI_CORE_IMAGE_PARAMS_XIP) >> $(BOOTIMAGE_TEMP_OUT_FILE)
 # Sign the appimage for HS-FS using appimage signing script
-	$(PYTHON) $(APP_IMAGE_SIGN_CMD) --bin $(BOOTIMAGE_NAME) --authtype 1 --key $(APP_SIGNING_KEY) --output $(BOOTIMAGE_NAME).hs_fs
+	$(PYTHON) $(APP_IMAGE_SIGN_CMD) --bin $(BOOTIMAGE_NAME) --authtype 2 --key $(APP_SIGNING_KEY) --output $(BOOTIMAGE_NAME).hs_fs
 ifeq ($(DEVICE_TYPE),HS)
 # Sign the appimage using appimage signing script
 ifeq ($(ENC_ENABLED),no)
 	@echo Boot image signing: Encryption is disabled.
-	$(PYTHON) $(APP_IMAGE_SIGN_CMD) --bin $(BOOTIMAGE_NAME) --authtype 1 --key $(APP_SIGNING_KEY) --output $(BOOTIMAGE_NAME).hs
+	$(PYTHON) $(APP_IMAGE_SIGN_CMD) --bin $(BOOTIMAGE_NAME) --authtype 2 --key $(APP_SIGNING_KEY) --output $(BOOTIMAGE_NAME).hs
 else
 	@echo Boot image signing: Encryption is enabled.
-	$(PYTHON) $(APP_IMAGE_SIGN_CMD) --bin $(BOOTIMAGE_NAME) --authtype 1 --key $(APP_SIGNING_KEY) --enc y --enckey $(APP_ENCRYPTION_KEY) --output $(BOOTIMAGE_NAME).hs
+	$(PYTHON) $(APP_IMAGE_SIGN_CMD) --bin $(BOOTIMAGE_NAME) --authtype 2 --key $(APP_SIGNING_KEY) --enc y --enckey $(APP_ENCRYPTION_KEY) --output $(BOOTIMAGE_NAME).hs
 	$(RM) $(BOOTIMAGE_NAME)-enc
 endif
 endif

    - Re-import the Reset Isolation example.

    - Rebuild & flash the HSFS appimage.

    Following the above steps should resolve the error.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 220 points

    1 Thank you very much, I changed it as you said, and the test was successful.\

    2 When normal mode, authtype is 1 when sbl boot mode, authtype is 2, do I understand so? 

  • 0 in reply to yu chai
    TI__Guru 70741 points

    Hi,

    yu chai said:
    2 When normal mode, authtype is 1 when sbl boot mode, authtype is 2, do I understand so? 

    When you are operating in normal mode, which I assume as loading via CCS, you direct the CCS to load the ELF file (.out) directly on the core & execute it. This ELF file being loaded by CCS is unsigned & so the authentication type really does not matter here.

    However, when you boot the application using the SBL, which will be ultimately done in production environment, the ELF file is converted into an Appimage (.appimage) which is then signed (.appimage.hs_fs) where the authentication type being used matters. In SDK v9, we actually moved from using authentication type 1 to authentication type 2. However, unfortunately this update got missed for the CCS makefiles. I have raised a ticket internally for this & should be rectified in the next release.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 220 points

    Well I understand. Thanks again