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.

AM6442: OSPI SBL authentication failure

Part Number: AM6442
Other Parts Discussed in Thread: UNIFLASH

Dear TI,

we're using a customised OSPI SBL bootloader on our proprietary target with deviant DDR and OSPI Flash. So I adapted the sample bootloader to suit this. It's running fine so far, but now we are getting errors at startup with our multicore image becoming bigger as development moves on :

DCS_SOM OSPI Bootloader
Built (Aug 16 2023, 11:10:55)
Support for DDR4 memory device IS43QR16512
Support for NOR flash device MT35XL512 in 1S-1S-8S mode


DMSC Firmware Version 8.5.3--v08.05.03 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1


[Bootloader_verifyMulticoreImage] failure in line 523
Image authentication failure

[Bootloader_parseMultiCoreAppImage] failure in line 616
Multicore image authentication failure

Some tests have failed!!
Status: -1
Status FAILED in line: 164

I added the comments myself in the bootloader code; and it seems that the call to the Bootloader_socAuthImage() in the SYSFW is returning with a failure. So authentication of the image is failing.

Our multicore image size just surpassed 0x180000 in past days.

Can it have something to do with this?

kind regards,
Marc Schouteeten

  • Hi Marc,

    Can it have something to do with this?

    Ideally, this shouldn't be the case.

    However, could you please confirm if the authentication of the multicore image was successful & the image was booting fine when the image was of lesser size. And you now see the failure only when multicore image size grew to be of 0x180000?

    Regards,

    Prashant

  • Hi Marc,

    Can it have something to do with this?

    I have tested and this is not the case at least with TI EVM. So, I tested the authentication of a random 2MB file using SBL_OSPI and here are the results

    DMSC Firmware Version 9.0.7--v09.00.07 (Kool Koala)
    DMSC Firmware revision 0x9
    DMSC ABI revision 3.1
    
    Length of certificate: 1654
    Length of image: 2097152
    Image authentication successful...

    The custom output was generated with the following changes:

    diff --git a/source/drivers/bootloader/bootloader.c b/source/drivers/bootloader/bootloader.c
    index 3aa46db1..e0088360 100644
    --- a/source/drivers/bootloader/bootloader.c
    +++ b/source/drivers/bootloader/bootloader.c
    @@ -578,7 +578,16 @@ int32_t Bootloader_verifyMulticoreImage(Bootloader_Handle handle)
                 }
                 else
                 {
    +                DebugP_log("Length of certificate: %d\r\n", certLen);
    +                DebugP_log("Length of image: %d\r\n", imageLen);
    +
                     authStatus = Bootloader_socAuthImage(certLoadAddr);
    +                
    +                DebugP_assert(authStatus == SystemP_SUCCESS);
    +                DebugP_log("Image authentication successful...\r\n\r\n");
    +
    +                /* Do not go further */
    +                while(1);
                 }
     
                 /* Invalidate the cache before reading in case HSM decrypted image */
    

    Regards,

    Prashant

  • Hi Prashant,

    We found a workaround for the issue. But there's something I don't totally get. That's why we added the debug info in our OSPI bootloader. We're good for now.

    kind regards,
    Marc

  • We are using the "uart_uniflash.py" script to upload a new firmware to our terminal console via serial port.

    As it turns out, this python script has a size limitation of 1Mbyte...

    BOOTLOADER_UNIFLASH_BUF_SIZE                         = 1024*1024

    increasing this size solves the programming issue...

    (our workaround was to upload via tftp)

  • Hi Marc,

    I am not able to connect the dots here.

    Initially you reported the authentication failure while working with OSPI bootloader. I assumed this occured when your OSPI bootloader tries to authenticate the multicore appimage from OSPI media itself. Then, you found a workaround for this and probably solved it.

    However, with the latest comment, I am unable to understand how the `uart_uniflash.py` comes into the picture here and so what really was the issue since the start. Could you please help me understand?

    Thanks!  

  • Hi Prashant,

    We have a terminal application running on a R5 core. With this terminal we have 2 ways to upload and flash a new binary : either upload via the serial console itself (then we use the uart_uniflash.py script with underlying xmodem protocol from the host side) or via tftp upload to filesystem. After uploading the firmware we program the received multicore image to flash.

    Now with tftp upload there is no issue.

    But when using uart_uniflash.py script; presumably the image up to 1Mbyte is uploaded; resulting in a broken binary image being uploaded. When flashing this image to OSPI flash; upon reboot the OSPI bootloader won't be able to authenticate the image since it's broken.

    I didn't validate myself; but my collegue confirmed that after adjusting the buf_size to 2 MB the uart upload and flash worked.

    kind regards,

    Marc

  • Hi Marc,

    Thanks a lot for the explanation. I now have the clear understanding.

    Actually, the `uart_uniflash.py` script is designed to send a file in chunks of 1MB if file size is greater than 1MB. The `sbl_uart_uniflash` then running at the board respects this design and flashes the image in chunks of 1MB. In case you are using your custom application to flash images, there might have come an incompatibility in the design which resulted in the issue.

    Anyways, simply increasing the chunk size works. Happy that the issue is solved...

    Regards,

    Prashant