• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 254 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.

OMAP-L138: NAND and Encryption Inquiries

Dajon McGill
Expert 6871 points
Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAPL138

Hello Team,

I have a customer that has a few questions related to a NAND part, reading NAND from DSP, and hardware encryption:

They are looking to replace the MT29F4G08ABADAH4, with a newer version MT29F4G08ABAFAH4.  The main differences between the two chips are: the new one has 8-bit ECC instead of 4-bit ECC, the page size is doubled to 4096, and the OOB size is 256 instead of 64.  We were able to read/write to the NAND.  The only problem we ran into was booting up the device from that particular NAND chip.

  • My understanding is that our ROM Bootloader only works with 4-bit ECC NAND, our NAND chip has 8-bit ECC.  Is there a way to get around this limitation?  Also, it would really help if we can get the source code for the ROM Bootloader.

We currently have a NAND-FLASH that is connected to the OMAP-L138 and is used by the U-boot and the Linux running from the NAND. We want to be able to read from this NAND on the DSP core. The DSP core is (C6748) portion of the OMAP-L138 that is running SYS/BIOS, version 6.76.2.00.

  • What would be the required steps do we need to follow, and is there any documentation to be able to access and read from our NAND-FLASH, but on the DSP side within a certain offset/memory region of that NAND? Specifically, within the SYS/BIOS RTOS system.

We would like to encrypt the audio data. 

  • s hardware encryption supported on the OMAP-L138?  If not, does TI-SDK have support for a lightweight software audio encryption?  We’re open to encrypt the audio data from either the DSP side or the Linux application running on the ARM core.  Our limitation is CPU resources.  So the less CPU usage for the encryption the better.

Please let me know if you need clarification. Thanks for the help.

Best,
Dajon McGill

  • 0
    TI__Guru** 116170 points

    Dajon McGill1 said:
    My understanding is that our ROM Bootloader only works with 4-bit ECC NAND, our NAND chip has 8-bit ECC.  Is there a way to get around this limitation?  Also, it would really help if we can get the source code for the ROM Bootloader.

    That is correct. The device interfaces with NAND flash using EMIF IP which only supports upto 4 bit ECC. There is no way to work around this limitation from a ROM perspective. Details of NAND flash that we support with this devices is explained in the Appendix B of the Bootloader application notes:

    https://www.ti.com/lit/an/sprab41f/sprab41f.pdf

    We don`t release the ROM Bootloader source code to customers as it is TI proprietary implementation and has details of our secure boot implementation  on this device. 

    Dajon McGill1 said:
    What would be the required steps do we need to follow, and is there any documentation to be able to access and read from our NAND-FLASH, but on the DSP side within a certain offset/memory region of that NAND? Specifically, within the SYS/BIOS RTOS system.

    NAND can be read from ARM or from the DSP as both cores can access the NAND through the EMIFA controller. We provide reference code to read NAND in the serial flash and boot tools provided here:

    https://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138

     OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\CCS\NANDWriter 

    Dajon McGill1 said:
    hardware encryption supported on the OMAP-L138?  If not, does TI-SDK have support for a lightweight software audio encryption?  We’re open to encrypt the audio data from either the DSP side or the Linux application running on the ARM core.  Our limitation is CPU resources.  So the less CPU usage for the encryption the better.

    We don`t have HW crypto accelerators on the OMAPL138 for encryption but we do provide crypto library for the DSP that can be used for encryption. DSP performs atleast 4-8X higher so I would recommend encrypting the audio data using DSP. The AES library for C64xplus can be used on C674x :

    http://software-dl.ti.com/tsu_encryption/tsu_encryption_public_sw/index.html

    Hope this helps.

    Regards,

    Rahul