• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 30 subscribers
  • Views 513 views
  • Users 0 members are here
Support feedback
Options
Options

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:

MCU-PLUS-SDK-AM243X: Flash Protocol Changes

MCU-PLUS-SDK-AM243X: Flash Protocol Changes causing problems with parseMultiCoreAppImage

Joe Paolino
Intellectual 430 points
Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

This is a new thread based on "MCU-PLUS-SDK-AM243X: Flash Protocol Changes" at the request of TI.

The summary is that OSPI bootloader fails within parseMultiCoreAppImage() for protocols other than 4S-4D-4D when using QSPI NOR.  By examining the FSS memory, it was discovered that multiple single bit errors were occurring in 4S-4S-4S mode at 50MHz.  By reducing the OSPI reference divider, bit errors were eliminated.  Disabling app authentication permits the application to load and operate properly.

However, when authentication is enabled parseMultiCoreAppImage still fails.  TISClient logs were provided and then TI requested that I create a new thread.

Thanks,

Joe

  • 0
    TI__Guru 59091 points

    Hi Joe,

    The SYSFW traces attached in the previous thread do not look okay. Can you please collect them from the MAIN_UART1 & share the same?

    Thanks!

  • 0 in reply to Prashant Shivhare
    Intellectual 430 points

    Hi Prashant,

    Here are the results for failing boot:

    UART1woDTFS.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    0x41110000
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4100001A
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4100001A
    0x41070000
    0x410800BF
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4100001A
    0xC21205
    0xC20024
    0x43870001
    0x43887FFF
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Here are the results for a working boot.  I halted it shortly after parseMultiCoreImage.

    UART1_workingbootshort.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    &▒0xC20101
    0xC20024
    0x61800101
    0x61C0008A
    0xC20104
    0xC20024
    0x61800104
    0x61C0008A
    0xC20100
    0xC20024
    0x61800100
    0x61C0008A
    0x62000000
    0xC2010D
    0xC20024
    0x6180010D
    0x61C0008A
    0x61257C83
    0xC2010C
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks,

    Joe

  • 0 in reply to Joe Paolino
    TI__Guru 59091 points

    Hi Joe,

    Thank you for sharing the logs!!

    Following are the relevant parsed logs for the failure case:

    0x00C2C120: BasePort: Unknown Action: 0x03 MSG:0x02C120
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x20C00003: Security: SEC_BOOT(Points of failures during secure boot api call): 0x01 => Certificate length > ASN1P_IMAX, 0x02 => Issuefetching certificate, 0x3 => Issue with Hash operation, 0x4 => Hash comparison fails: 3

    The cause of the failure is "Issue with Hash operation".

    I will check with the SYSFW team once about the failure & get back to you.

    Thanks!

  • 0 in reply to Prashant Shivhare
    Intellectual 430 points

    Hi Prashant, just checking in.

    Thank you,

    Joe

  • 0 in reply to Joe Paolino
    TI__Guru 59091 points

    Hi Joe,

    Can you please integrate the following test function in your SBL, call it just after Sciclient_getVersionCheck, and share the boot logs?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void test_func() {
    /* appimage offset & max length */
    uint32_t offset = 0x80000, len = 0x40000;
    uint32_t appimage_addr = 0xFFFFFFFF;
    uint32_t dst = 0x70180000;
    uint8_t copy_appimage_to_mem = 1;
    if(copy_appimage_to_mem) {
    Flash_Handle flashHandle = Flash_getHandle(CONFIG_FLASH0);
    Flash_read(flashHandle, offset, (uint8_t*)dst, len);
    CacheP_wb((void*)dst, len, CacheP_TYPE_ALL);
    appimage_addr = dst;
    } else {
    OSPI_Handle ospiHandle = OSPI_getHandle(CONFIG_OSPI0);
    OSPI_enableDacMode(ospiHandle);
    appimage_addr = 0x60000000 + offset;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The test is to see if the authentication passes in case the appimage is first read into RAM & then authenticated.

    Thanks!

  • 0 in reply to Prashant Shivhare
    Intellectual 430 points

    Hi Prashant,

    I ran the test with SysConfig in a known good configuration of 4s4d4d at 20MHz.  I ran it with both copy_appimage_to_mem equal to 1 and 0.  As you can see, it fails when equal to one and passes when using enableDacMode instead.

    4s4d4d_var_equal_1.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    &▒0xC20101
    0xC20024
    0x61800101
    0x61C0008A
    0xC20104
    0xC20024
    0x61800104
    0x61C0008A
    0xC20100
    0xC20024
    0x61800100
    0x61C0008A
    0x62000000
    0xC2010D
    0xC20024
    0x6180010D
    0x61C0008A
    0x61257C83
    0xC2010C
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    4s4d4d_var_equal_0.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    0xC20024
    0x43870001
    0x43887FFF
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4380001A
    0x4F01000C
    0x4F0606A0
    0x4F0A0024
    0x4381000C
    0x438A0000
    0x43A00000
    0x43A10000
    0x438B0000
    0x438C000C
    0x43A20000
    0x438D0000
    0x43A30000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks,

    Joe

  • 0 in reply to Joe Paolino
    TI__Guru 59091 points

    Hi Joe,

    I have a set of SYSFW binaries that I would like you to test for this authentication failure issue. Please accept the friend request that I have just sent to you so that I could share the binaries over private chat.

    Thanks,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 430 points

    Thanks, Prashant.  Will do.

  • 0 in reply to Joe Paolino
    TI__Guru 59091 points

    Hi Joe,

    I have shared the binaries over private chat. Please replace the default sysfw binaries with the shared ones & share the results.

    Thanks, Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 430 points

    Hi Prashant,

    I ran test_func with a known good config again 4S4D4D at 20MHz.  Authentication failed when using the Cache method.

    Thanks,

    Joe

  • 0 in reply to Joe Paolino
    TI__Guru 59091 points

    Hi Joe,

    Joe Paolino said:
    Authentication failed when using the Cache method.

    That is just because the destination address is 0x70180000 which limits the maximum appimage size (len = 0x40000 (256KB)) than can be read from flash & authenticated. If your appimage size is large then you would have to adjust the destination address accordingly.

    In any case, the `test_func` is not relevant anymore. I would like you to validate the shared sysfw binaries with the usual boot flow to see if the authentication failure issue still occurs.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 430 points

    Prashant,

    It works!

    In detail, I tried 4s4d4d at 20MHz which has been working.  Then I tried the protocol configuration that has never worked: 4S4S4S at 33MHz with a known good Tap Delay of 3 and with your SysFw it authenticates and boots.

    I would like to note the following for anyone following this thread and the linked thread:

    Prior to calling Sciclient_getVersionCheck(1) we call:

    • OSPI_setRdDataCaptureDelay(gOspiHandle[0], 2); // 3 also works at 33MHz
    • OSPI_enableDacMode(gOspiHandle[0]);

    After the first successful test at 4S4S4S, I allowed the OSPI driver to determine the CaptureDelay (Tap Delay) and it came up with a value of 4.  The result of this was that it found an image length of 0 and failed to boot.  In Excel I calculated that both a value of 2 or 3 should work at 33MHz and with your new SysFw they did both work.  The method of determining the capture delay needs to be made more robust for users that are booting from QSPI.  The chip errata prevents us from using external loopback and PHY Mode.

    4S4S4S at 33.3MHz Tap=3


    DMSC Firmware Version 10.1.8-v10.01.08-2-gabffe (Fier
    DMSC Firmware revision 0xa
    DMSC ABI revision 4.0

    Starting to verify the image by calling Bootloader_verifyMulticoreImage() !!
    Bootmedia is Flash !!
    Bootmedia is not eMMC hence compute certificate and image length !!
    Certificate Length: 1654 and Image Length: 786752 !!
    Cache Aligned length: 788480 !!
    Certificate length is valid
    Image authentication done, results authStatus: 0
    Image Authentication passed !!
    Status value: 0 !!
    Image verified, status is: 0 !!
    Image parsed successfully !!
    Starting to read all the core offset addresses !!
    Starting to parse individual rprc files !!

    Thank you very much for your assistance on this!  How are we to proceed with our development?  Will this fix become available in the next SDK release?

    Joe

  • +1 in reply to Joe Paolino
    TI__Guru 59091 points

    Hi Joe,

    Thank you for the explanation. It might be helpful for others.

    Joe Paolino said:
    How are we to proceed with our development?

    The shared sysfw binaries were only meant for testing. Assuming you are in development phase, you can continue to use these shared ones to leverage authentication otherwise you could go back to using the usual binaries that came with the SDK but with authentication disabled for now.

    The official fix will be part of the next SYSFW release as part of the next SDK release v10.1.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 430 points

    Thanks again to you and the rest of the TI engineers that provided support for the last 5 months until resolution.

    Joe