• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 376 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SBL fail by the Iíntegration of customer Flash Driver using the SDK mcu_plus_sdk_am243x_08_03_00_05

Karen Agüero Meza
Prodigy 150 points
Other Parts Discussed in Thread: SYSCONFIG, UNIFLASH

Hi Support, 

We have the problem that the SBL doesn’t loads the firmware using the new SDK Version mcu_plus_sdk_am243x_08_03_00_05

The Basis of our SBL is the  sbl_ospi_am243x example in the sdk.

The only difference in the integration of our owner flash driver and before the integration for this in the SBL, it  was tested and verified the correct functionality.

The Integration looks as follows

1.  Deleted  Flash and Bootloader driver from the  sysconfig   

    The Flash and Bootloader driver  are initialized and configured separately according to the sdk (see below the sequence).

      We tested this in  PREVIOUS SDK VERSION (mcu_plus_sdk_am243x_08_02_00_12) and it works

2. The code sequence and debugging : 

  • Bootloader_Profiles & SystemInit & DriversOpen & Scilclient ===>    (ok)
  •  OWNER Flash Driver initialized and  Bootloader as well as  structures & callbacks (as required by the sdk) === > ok
  •  Call Bootloader_parseMultiCoreAppImage === > (ok)
  •  Set clocks for self cluster      === > (ok)
  •  Call Bootloader_loadSelfCpu === > (ok)
  •  Call Bootloader_runSelfCpu === > Jump : Firmware was NOT loaded.

Of course,

 1- We are copied to flash a firmware at the corresponding address 

 2- The evm is in OSPI boot mode  

What could be the problem? There are something else that we need to consider in the sysconfig?

Maybe the way to integrate a new Flash driver is not correct, but here in the previous SDK (mcu_plus_sdk_am243x_08_02_00_12) works

What we do wrong?

Thanks a lot!

Best Regards

Karen Agüero

 

 

  • 0
    TI__Mastermind 24554 points

    Hi Karen,

    In 8.2 release the SBL and SYSFW were differently flashed on the device.
    From 8.3 releases the SBL and the SYSFW were merged into single binary to flash.

    If you add the SYSFW to SBL as part of post build process, this will fix the issue.

  • +1 in reply to Aakash Kedia
    TI__Mastermind 24554 points

    The size of SBL was increased to > 600Kb but the offset is fixed in the project to 0x80000 (512KB). The Application is flashed after SBL (in uniflash) which was overwriting the SBL leading to X509 certificate verification failure which is why the PC was in ROM code.

     

    Please find the following changes that needs to be done.

     

    • Update the sbl_ospi project via syscfg. Boot Image Offset should be the same one in the uniflash flash-offset address for the application.

    • uart_unitflash.py  -p COMX --file= gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage --operation=flash --flash-offset=0x100000
  • 0 in reply to Aakash Kedia
    Prodigy 150 points

    Hi Aakash,

    The suggestion resolved the problem caused by file size. Thanks for this!

    However, we have the next problem: 

    When the SBL runs directly fom flash, it stays in the  startup by the function  Bootloader_socWaitForFWBoot();

    here the SBL try to read the register status   CSL_REG32_FEXT (Address 0x48250004), but its not available and the sbl is blocked.

    Also, we are found that there is a timing problem and included a delay (loop until 10 000 000 ) before as workround, with this works

    We cannot explain why the SBL needs time at the startup so that certain register are available to read.

    The current workaround  ist not really reliable.

    Do you have ein Idea, what could be the problem?

    Regards,

    Karen

  • +1 in reply to Karen Agüero Meza
    Prodigy 135 points

    Hi Aakash,

    the call is Bootloader_socWaitForFWBoot() -> Sciclient_waitForBootNotification() -> CSL_secProxyGetMaxMsgSize() -> CSL_REG32_FEXT().

    pSecProxyCfg->maxMsgSize = (uint32_t)CSL_REG32_FEXT( &pSecProxyCfg->pSecProxyRegs->CONFIG, SEC_PROXY_CONFIG_MSG_SIZE );

    It seems like CSL_REG32_FEXT can't access the specific hardware register at this time and raises a data abort trap.

    Regards,

    Sven

  • 0 in reply to Sven Hogenmüller
    TI__Mastermind 24554 points

    Hi Sven and Karen,

    We have a small fix for the same function Sciclient_waitForBootNotification.

    Polling of the ProxyRT should be done first and foremost thing in the system and accessing any registers before that should not be done.

            while ((CSL_REG32_RD(Sciclient_secProxyThreadStatusReg(rxThread)) &

                 CSL_SEC_PROXY_RT_THREAD_STATUS_CUR_CNT_MASK) == 0U) {;} 

    int32_t Sciclient_waitForBootNotification(void)

    {

        int32_t status = SystemP_FAILURE;

        uint32_t rxThread = SCICLIENT_ROM_R5_RX_NORMAL_THREAD;

        uint32_t secHeaderSizeWords = sizeof(struct tisci_sec_header)/sizeof(uint32_t);

        volatile Sciclient_RomFirmwareLoadHdr_t *pLocalRespHdr;

        uint32_t maxMsgSizeBytes;

     

        status = Sciclient_secProxyVerifyThread(rxThread);

     

        if (status == SystemP_SUCCESS)

        {

            while ((CSL_REG32_RD(Sciclient_secProxyThreadStatusReg(rxThread)) &

                 CSL_SEC_PROXY_RT_THREAD_STATUS_CUR_CNT_MASK) == 0U) {;}

     

            maxMsgSizeBytes = CSL_secProxyGetMaxMsgSize(&gSciclientSecProxyCfg) -

                                        CSL_SEC_PROXY_RSVD_MSG_BYTES;

     

            pLocalRespHdr = (Sciclient_RomFirmwareLoadHdr_t *)(CSL_secProxyGetDataAddr(

                                                    &gSciclientSecProxyCfg, rxThread, 0U)

                                                    + ((uintptr_t) secHeaderSizeWords * (uintptr_t) 4U));

     

            /* Check the message type and flag of the response */

            if (pLocalRespHdr->type ==

                TISCI_MSG_BOOT_NOTIFICATION)

            {

                status = SystemP_SUCCESS;

            }

            else

            {

                status = SystemP_FAILURE;

            }

            /* Reading from the last register of rxThread*/

            (void) Sciclient_secProxyReadThread32(rxThread,

                            (uint8_t)((maxMsgSizeBytes/4U)-1U));

        }

        else

        {

            status = SystemP_FAILURE;

        }

     

        return status;

    }

    After the fix, please rebuild the library and link the updated library to the project. Make sure to rebuild the project.

    Hope it helps,

    Aakash K

  • 0 in reply to Aakash Kedia
    Prodigy 150 points

    Thanks Aakash,

    This resolved das Problem!