• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 480 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.

C6748 - can't setup MMR registers in SECURE MODE, can't exit SECURE MODE

Marcin Wyrwas
Prodigy 30 points
Other Parts Discussed in Thread: TMS320C6748

We are attempting to secure our application on the TMS320C6748 using the Generic Security provided by the DSP. We want our application AIS image to be secured from being read unencrypted from Flash.

So far we've been able to load a simple program through Secure ROM that is switching state of LEDs via I2C.

We've tripped on a problem of modifying the system MMRs which seem to be locked  somehow and any attempt to change their state causes our application to abort.

Example snippet causing abort: GPIO_BANK01_DIR |= 0x000000FF 

There is a register mentioned in SPRUGQ9 June 2011(TMS320C674x/OMAP-L1x Processor Security User's Guide) that is supposedly meant to allow access to the MMRs -  System Security Protected Control Register (SYSCONTROLPROTECT) - bits MMR_UNLOCK / MMR_LOCK. The problem is that writes to this register don't cause any effect - reading it back yields old value. Only SYSCONTROL.TEST_AS_ SEC_MMR_REQ seems to be writable.

So the question is how to enable MMRs to be writable after booting on a Secure processor? Where do we find examples to perform that?

Another problem that we face is exiting from secure mode after boot. We were unable to get even a simple program running if "bootExitType" parameter in SecureHexAIS configuration is set to NONSECURE, only SECUREWITHSK seems to work.

  • 0
    TI__Genius 17355 points

    Can you confirm what silicon revision you are using (you can look at the second word of the ROM memory - you can also use the debug GEL file available here to dump that info).

    With silicon revisions 2.0 and later there are no known issues with the use of the NONSECURE exit type, assuming that you are not loading code or data to the reserved secure memory regions during the boot.

    Regarding the system MMRs, have you been able to determine the cause of the abort? For example, was it due to an exception of some kind.  I'm assuming that you are seeing this problem when running the device in the SECUREWITHSK mode.  If so, this might not be unexpected as there are IOPUs that protect certain peripherals from access by non-secure code.  If you don't unlock these during the boot, the code you boot into (which is running from memory marked as non-secure), will not be able to access those protected peripherals.  When using the NONSECURE exit type, this shouldn't be an issue since the chip will effectively act as a non-secure chip ( but with JTAG access locked unless you unlocked it during the boot).

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 30 points

    Here is a dump from debug GEL:

    C674X_0: GEL Output: ROM ID: d800k008
    C674X_0: GEL Output: Silicon Revision 2.1


    The DSP shows privilege exception as the reason for abort, and executes the following code when attempting to access one of the MMRs.

    0x007F7FEC: 0080B362 BNOP.S2X A0,5
    0x007F7FF0: 0004A120 BNOP.S1 0x7F7FF0 (PC+16 = 0x007f7ff0),5
    0x007F7FF4: 10002001 SWENR
    0x007F7FF8: 00010000 || NOP 9
    0x007F7FFC: 00000000 NOP

    Hopefully we have been able to find a solution to this problem by ourselves. We have isolated the problem to be caused by enabling the PRUSS peripheral with PSC from AIS.

    After removing PRUSS initialization from AIS, both NONSECURE and SECUREWITHSK modes work properly now with the latter allowing to access the MMRs.

  • 0 in reply to Marcin Wyrwas
    TI__Genius 17355 points

    Marcin,

    I'm still not sure where and when this exception is generated as a result of your code, but this result does make some sense as the PRUSS is used to perform the secure to non-secure override sequence for the DSP (this involves resetting the DSP core, which the DSP can't do to itself).  Perhaps this deserves more note in the documentation so that users know to avoid this circumstance.

    Regards, Daniel