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.

AM2431: SBL does not start Application in HS-FS mode

Part Number: AM2431
Other Parts Discussed in Thread: UNIFLASH

We recently re-spun a custom board with the AM2431A microcontroller to now use the AM2431B microcontroller.  On the previous board, we successfully converted the sbl_sd example into an eMMC SBL that read and booted a multicore appimage file that was flashed to the eMMC boot partition.

When the new board arrived with AM2431B microcontroller, we updated the SDK to version 09_00_00_30 since we had to support HS_FS operation.  We have gone through the migration guides multiple times and were finally able to get the SBL and Application properly built and signed, We have now run into an issue where the SBL appears to validate and load the the multicore image, however, it never seems to get past the Bootloader_runSelfCpu() function once it is ready to start the application.

When debugging the SBL in CCS, I paused and looked at the call stack once the SBL appeared to be hung.  Here's what it showed:

It appears that the Security handover never completes successfully, as a response is never received when the TISCI_MSG_SEC_HANDOVER message is sent.

I have looked through various TI documents (SDK User Guide, TISCI User guide, etc.) and read the Security Board Configuration section of the TISCI User Guide:  https://software-dl.ti.com/tisci/esd/latest/3_boardcfg/BOARDCFG_SEC.html

It's unclear what, if anything, I need to add to the SBL to enable the security capabilities of the SYSFW.  I have looked through the examples in the SDK and have not found anything related to configuring board security.

Is there documentation somewhere that explains the process from beginning to end on how to setup security or could something else be causing this issue?

  • Hi ,

    Let me check the same and come back to you.

    Best Regards,
    Aakash

  • Just checking if you have been able to find any information on the issue.  I continue to look for a solution but have not found anything yet.

  • Hi Jim,

    On the previous board, we successfully converted the sbl_sd example into an eMMC SBL that read and booted a multicore appimage file that was flashed to the eMMC boot partition.

    Does SBL SD work for you or you see similar behavior for SBL SD. You can test this on TI-EVM as well. SBL-SD flow is already tested for HS-FS and I doubt this should've failed.

    It's unclear what, if anything, I need to add to the SBL to enable the security capabilities of the SYSFW. 

    Actually, the SYSFW always has the security features enabled. Only after SecHandOver, it loses the capabilities of security features.

    Best Regards,
    Aakash

  • Our TI-EVM board has a GP chip on it so I cannot test HS-FS mode on it.  Our custom board does not have SD on it, so the SBL SD is not an option for us, nor is it something we can test.

    You mentioned that after the SecHandOver, the SYSFW loses the capabilities of security features.  Our problem, as the call stack shows, is that the SBL never completes the SecHandOver.  It appears to be stuck waiting for a response to the TISCI_MSG_SEC_HANDOVER message.

    We need to know what could be causing the response from being sent and more details on how to troubleshoot the problem.

  • Hi Jim,

    As we have moved to 09.00 we have pulled in all the support for GP devices and we will continue to only support HS-FS devices i.e. the RTM'd version of the device. The last GP version supported was 08.06 version from SDK point of view.

    You will find the details in the release notes.

    Best Regards,
    Aakash

  • You misunderstood my previous response.  I know that you no longer support GP devices.  That's why we had to re-spin our custom board to use the rev. B AM2431 and moved to version 9.00 of the SDK.  In your previous response, you said the following:

    Does SBL SD work for you or you see similar behavior for SBL SD. You can test this on TI-EVM as well.

    I was simply saying that the TI-EVM boards we purchased over a year ago, when we first started development with the AM2431, contain the version A (GP) microcontrollers, so I am unable to test the HS-FS code on it.

    We have read the release notes and the migration guides multiple times as well as other documents TI documents (SDK User Guide, TISCI User guide, etc.) but have not been able to get the SBL to complete the SecHandOver functionality.  That's what led me to post my question in the first place.

  • Hi Jim,

    Now I understand. So you do have a latest device and that device is indeed HS-FS device where you see this issue. Can you confirm the boot mode ? Are you using the following boot mode ?

    Best Regards,
    Aakash

  • Yes, that is the boot mode we are using.

  • Jim,

    I have so many questions. eMMC boot mode only boots raw image where as SBL SD expects the SD card to support root file system and loads the file accordingly.

    • How was the porting done exactly ? Which example of SBL did you use ?
    • Which image did you place in the eMMC ? Did you try having a loop_forever in the system and see if the image boot works successfully ?

    Best Regards,
    Aakash

  • We modified the sbl_sd_am243x-evm_r5fss0-0_nortos_ti-arm-clang example to read a file from the eMMC rather than the SD card.

    We wrote a utility that creates a file that contains a header along with an R5 image, an M4 image and multiple PRU images.  The header specifies the length of each image contained within the file as well as the the offset in the file where each image begins.

    Using the uart_uniflash.py Python script described in the SDK guide, we flash our eMMC SBL to address 0 in the eMMC and the combined file to address 0x80000.

    When the eMMC SBL boots up, it opens the combined file at address 0x80000, reads one image at a time, writes the image to the appropriate processor and then starts each one.

    On our previous custom board with the GP version of the AM2431A, this process worked properly.  We were able to validate this because the image running on the R5 would run diagnostics on our custom board and send output to a console port.  The console output was sent through a cable to a PC and displayed in a terminal emulation window (puTTY) on the PC.

    As I mentioned in my original post and showed in the call stack image, on our new custom board with the AM2431B, everything in the process works properly until the SBL tries to start the R5 image.  It gets stuck waiting for a response to the TISCI_MSG_SEC_HANDOVER message.

  • I decided to tried an even simpler example to see if I could get this to work.  I built the hello_world_am243x-evm_r5fss0-0_nortos_ti-arm-clang example and then flashed it to address 0x80000 in the eMMC with the uart_uniflash.py script.  I also modified my eMMC SBL to simply start up, read the image from location 0x80000, load it into the R5 and then start the R5.

    Unfortunately, it still gets stuck at the same place, waiting for a response to the TISCI_MSG_SEC_HANDOVER message.  We're now wondering if this issue has to do the M3 not resetting properly when it is time to start the R5.  Any thoughts on this theory?

  • Hi Jim,

    Does any other TISCI API call work before the TISCI_MSG_SEC_HANDOVER call?
    Could you try calling an API like TISCI_MSG_VERSION before sec handover call?

    Regards,

    Kavitha




  • I placed a call to Sciclient_getVersionCheck() just before the call to Bootloader_runSelfCpu() and it does return properly.  The Bootloader_runSelfCpu() function is then called and it does not return.  I put some DebugP_log() calls in my code and here is the output that appears in the console window:

       Starting EMMC Bootloader ...
       Starting to read files from eMMC
       Loading App
       Image loading done, switching to application ...
       Loading CSL_CORE_ID_R5FSS0_0
       Calling Sciclient_getVersionCheck  <++++ NEW FUNCTION CALL ADDED

       DMSC Firmware Version 9.0.7--v09.00.07 (Kool Koala)
       DMSC Firmware revision 0x9
       DMSC ABI revision 3.1

       Calling Bootloader_runSelfCpu  <++++ CODE NEVER GETS PAST THIS CALL

    When I pause CCS and look at the stack dump, this is what I see (same as posted earlier in this thread):

  • Checking in to see if there are any more thoughts on this. We found that we have the exact same issue with the same stack dump shown above if we have an Application running and it calls  Bootloader_socCpuResetReleaseSelf() to restart itself.

  • Hi Jim,

    Could you share the board configuration values used?
    What are the 'handover_msg_sender' and 'handover_to_host_id' values set to?

    Regard,

    Kavitha

  • I see these settings in the SDK source\drivers\sciclient\sciclient_default_boardcfg\am243x\sciclient_defaultBoardcfg_security.c file:

        /* Sec config */
        .sec_handover_cfg = {
            .subhdr = {
                .magic = TISCI_BOARDCFG_SEC_HANDOVER_CFG_MAGIC_NUM,
                .size = sizeof(struct tisci_boardcfg_sec_handover),
            },
            .handover_msg_sender = TISCI_HOST_ID_MAIN_0_R5_0,
            .handover_to_host_id = TISCI_HOST_ID_MAIN_0_R5_0,
            .rsvd = {0, 0, 0, 0},
        },

    Is that what you are looking for?  The block above are part of the gBoardConfigLow_security structure.  We are not doing anything specific to change these values and I don't know how to tell if they are acutally being used.  I did notice this in the gBoardConfigLow_security structure definition:

    const struct tisci_boardcfg_sec gBoardConfigLow_security
    __attribute__(( aligned(128), section(".boardcfg_data") )) =

    In the SDK file source\drivers\sciclient\include\sciclient_board_cfg.h, I noticed this comment in each function header:

              User needs to define a section ".boardcfg_data" in the
               linker file for the default configuration, which needs to be present
               in OCMRAM . If user provides custom board_cfg, then the data must
               be present on OCMRAM.

    I don't see this section defined in our project linker file, yet I don't get any errors or warnings when building the project.  Should I expect an error to be generated or does this imply that either the gBoardConfigLow_security structure is not being used or it is pointing to a place that can't be accessed properly?