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.

ddr problem with secure device in secure mode

Other Parts Discussed in Thread: OMAPL138, OMAP-L138

Hi,

I have some problems with mDDR in secure device on secure kernel mode.
I do the folloing tests:(My dsp ubl just initialize ddr, and do some write and read test)

step1:
                I configure the ini file to configure DSP core uses non-secure kernel mode. At this situation, program works well.
And the Hardware Security Controller registers' value:
scmmRegs->PID = 0x44842a00
scmmRegs->SYSSTATUS = 0x903a2
scmmRegs->SYSWR = 0x1
scmmRegs->SYSCONTROL = 0x0
scmmRegs->SYSCONTROLPROTECT = 0x20000
scmmRegs->SYSTAPEN = 0xffffffff
scmmRegs->SECRESERVED = 0x13

step2:
I change the ini file to configure DSP core uses secure kernel mode. At this situation, ddr2 controller is initialized well.
(I compare the registers' value both non-secure and secure kernel, they are same.)
But when program read/write the ddr, program counter run away.
And the Hardware Security Controller registers' value:
scmmRegs->PID = 0x44842a00
scmmRegs->SYSSTATUS = 0x80080302
scmmRegs->SYSWR = 0x0
scmmRegs->SYSCONTROL = 0x0
scmmRegs->SYSCONTROLPROTECT = 0x80
scmmRegs->SYSTAPEN = 0xffffffff
scmmRegs->SECRESERVED = 0x13

Difference between non-secure and secure of Hardware Security Controller registers' value are:

scmmRegs->SYSSTATUS = 0x903a2(non-secure)   scmmRegs->SYSSTATUS = 0x80080302(secure)
scmmRegs->SYSWR = 0x1 (non-secure)                     scmmRegs->SYSWR = 0x0(non-secure)
scmmRegs->SYSCONTROLPROTECT = 0x20000    scmmRegs->SYSCONTROLPROTECT = 0x80

Refer to section 2.5.5 in OMAPL138_C6748_Generic_Security_Users_Guide_v1.0.2 and Memory_Protection_03_2012_v01
there are some resources restricted. Furthermore, refer to URL:
http://processors.wiki.ti.com/index.php/Basic_Secure_Boot_for_OMAP-L138_C6748#What_is_the_preferred_method_of_flashing_a_secure_device.3F

; This section allows configuration of one the systme IOPUs.
; The iopuNum field must be valid (0-5) and then mppaStart
; and mppaend fields allow setting a range of mppa MMRs to the
; same supplied mppa value.
; IOPUSELECT: | RSVD | iopuNum| mppaStart | mppaEnd |
; MPPAVALUE: | mppaValue |

The value of iopuNum can be (0~5), and refter to IOPU_Users_Guide, There is only 0~3. So what are others two used for?

Could some one provide any detail documentens relate to these(MPU and IOPUs).

Thanks!

Follwing contents is my ini file works for above test:

;***************************************************************
; TI OMAP-L138 / C6748 Security Utilities *
; (C) 2009-2012 Texas Instruments, Inc. *
;***************************************************************
;
; This INI file will create a header that contains:
; NOR config word (1 word)
; AIS magic number (1 word)
; AIS key load command (1 word)
; AIS key header (8 words)
; AIS set exit type (2 words)
; AIS set command + params (5 words)
; Signature (16 words)
;
; The AIS set command at the bottom of the INI file is a dummy write
; in order to force a signature check. This is necessary in order to
; create a well defined header that can be bound to the device. If
; the AIS set command is not used, then you will have to determine
; where the first signature occurs so that you can bind the entire
; section.
;
; *********************** INI ************************
; General settings that can be overwritten in the host code
; that calls the AISGen library.
[General]
; Can be 8 or 16 - used in emifa
busWidth=16

; SPIMASTER,I2CMASTER,EMIFA,NAND,EMAC,UART,PCI,HPI,USB,MMC_SD,VLYNQ,RAW
BootMode=EMIFA

; NO_CRC,SECTION_CRC,SINGLE_CRC
crcCheckType=NO_CRC
; Security settings (keys, options, list of sections to encrypt, etc.)
[Security]
; Security Type: GENERIC, CUSTOM, NONE
securityType=GENERIC

; Boot Exit Type: NONSECURE, SECUREWITHSK
; NONSECURE = Device switches from secure type to non-secure type, jumping to loaded code
; (no secure kernel since no longer secure device).
; SECUREWITHSK = Device remains as secure type, secure kernel is loaded, allowing run-time
; security context switching.

; for secure mode test

bootExitType = SECUREWITHSK

; for non-secure mode test

;bootExitType = NONSECURE 


; Encrypt section list (ALL or comma-separated list of section names)
encryptSections=ALL

; CEK used for AES encryption of data - must be string of 32 hexadecimal characters
; Device uses KEK to encrypt CEK, and then SECURE KEY LOAD command load this CEK, uses to
; decrypt the data by ENCRYPTED SECTION LOAD command
;encryptionKey=4A7E1F56AE545D487C452388A65B0C05
encryptionKey=0123456789abcdeffedcba9876543210
; SHA Algorithm Selection
genericSHASelection = SHA1


; This section allows configuration of one the systme IOPUs.
; The iopuNum field must be valid (0-5) and then mppaStart
; and mppaend fields allow setting a range of mppa MMRs to the
; same supplied mppa value.
; IOPUSELECT: | RSVD | iopuNum| mppaStart | mppaEnd |
; MPPAVALUE: | mppaValue |
[IOPUCONFIG]
IOPUSELECT = 0x000000FF
MPPAVALUE = 0xFFFFFFFF

[IOPUCONFIG]
IOPUSELECT = 0x000100FF
MPPAVALUE = 0xFFFFFFFF

[IOPUCONFIG]
IOPUSELECT = 0x000200FF
MPPAVALUE = 0xFFFFFFFF

[IOPUCONFIG]
IOPUSELECT = 0x000300FF
MPPAVALUE = 0xFFFFFFFF


;This will set all security bits in IOPU6 registers to unlock security
;protection on all IOs protected but will lock the SYCFG registers to
;access only by secure supervisor ROM or secure kernel.
[IOPUCONFIG]
IOPUSELECT = 0x000600FF
MPPAVALUE = 0xFFFFFFFF

;This will set bit 7 of IOPU6 to 0 that will unlock the security protection
;on SYSCFG registers which is ideally what you need to configure PINMUX and
;other system registers.
[IOPUCONFIG]
IOPUSELECT = 0x00060707
MPPAVALUE = 0x00000000


; This section allow setting the MPU1 or MPU2. If the
; rangenum is out of the allowed range then all the ranges
; (including the fixed range) take the start, end, and
; protection values.
; |------24|------16|----------8|----------0|
; MPUSELECT: | RSVD | mpuNum | rangeNum |
; STARTADDR: | startAddr |
; ENDADDR: | endAddr |
; MPPAVALUE: | mppaValue |
[MPUCONFIG]
MPUSELECT = 0x000001FF
STARTADDR = 0x00000000
ENDADDR = 0xFFFFFFFF
MPPAVALUE = 0xFFFFFFFF

[MPUCONFIG]
MPUSELECT = 0x000002FF
STARTADDR = 0x00000000
ENDADDR = 0xFFFFFFFF
MPPAVALUE = 0xFFFFFFFF


[AIS_Set]
; Generic AIS set instruction to a reserved register to force a signature check
TYPE=2
ADDRESS=0x01E2C020
DATA=0
SLEEP=0

  • Zhongfeng Chen,

    As I have mentioned earlier basic secure device support only secure boot and don`t support runtime security. We would recommend that you exit boot in non-secure mode and perfrom DDR settings in the UBL.

    MPUs are documented in the Technical reference manual and IOPU documentation was shared with you along with the secure examples. Let me know if you don`t have the document and I can send it to you in a separate e2e conversation. IOPU and MPU settings will not apply when you exit in non-secure mode.

    If you are exiting in secure mode have you tried to configure the mDDR from the INI file instead of the UBL. This is not a typrical usecase scenario but in the past, we have initilized mDDR from the INI file.

     Regards,

    Rahul

  • Hi Rahul,

    Thanks for your reply!

    Rahul Prabhu said:

    MPUs are documented in the Technical reference manual and IOPU documentation was shared with you along with the secure examples.


    Yes, Currently the MPUS and IOPUS documents on hand is the under the secure examples(Security_collateral_update.zip).

    SECUREWITHSK

    Rahul Prabhu said:

    If you are exiting in secure mode have you tried to configure the mDDR from the INI file instead of the UBL. This is not a typrical usecase scenario but in the past, we have initilized mDDR from the INI file.

    This morning,  I have ried configure the mDDr in my ini file. I added the following statements:

    ; This section can be used to configure the PLL1 and the EMIF3a registers
    ; for starting the DDR2 interface.
    ; See PLL1CONFIG section for the format of the PLL1CFG fields.
    ;            |------24|------16|-------8|-------0|
    ; PLL1CFG0:  |              PLL1CFG              |
    ; PLL1CFG1:  |              PLL1CFG              |
    ; DDRPHYC1R: |             DDRPHYC1R             |
    ; SDCR:      |              SDCR                 |
    ; SDTIMR:    |              SDTIMR               |
    ; SDTIMR2:   |              SDTIMR2              |
    ; SDRCR:     |              SDRCR                |
    ; CLK2XSRC:  |             CLK2XSRC              |
    [EMIF3DDR]
    PLL1CFG0=0x18000001
    PLL1CFG1=0x00000002
    DDRPHYC1R=0xc3
    SDCR=0x2034621
    SDTIMR=0x16923209
    SDTIMR2=0x200e0e20
    SDRCR=0x93f
    CLK2XSRC=0x00000000

    After added above statements, I also tried the following tests:(both tests base on : I removed mdd initialize driver)

    1. I changed the bootExitType to "bootExitType = NONSECURE",  and then burned DSP UBL image into NOR flash, and the program works well.

    2. Then, I changed the bootExitType to "bootExitType = SECUREWITHSK", and use the same DSP UBL image, but the mddr read/write still errors.

    And then , I tried another test, in the Memory_Protection_03_2012_v01.pdf, it mentions MPU1 protect Share Ram:

    So, I changed my the MPU statements in my ini file:(all both work with "bootExitType = SECUREWITHSK")

    ; This section allow setting the MPU1 or MPU2. If the
    ; rangenum is out of the allowed range then all the ranges
    ; (including the fixed range) take the start, end, and
    ; protection values.
    ;            |------24|------16|----------8|----------0|
    ; MPUSELECT: |      RSVD       |   mpuNum  | rangeNum  |
    ; STARTADDR: |              startAddr                  |
    ; ENDADDR:   |               endAddr                   |
    ; MPPAVALUE: |              mppaValue                  |
    [MPUCONFIG]
    MPUSELECT = 0x000001FF
    STARTADDR = 0x00000000
    ENDADDR   = 0xFFFFFFFF
    MPPAVALUE = 0xFFFFFFFF

    test 1 changes :

    [MPUCONFIG]
    MPUSELECT = 0x000001FF
    STARTADDR = 0x00000000
    ENDADDR   = 0xFFFFFFFF
    MPPAVALUE = 0x00000000

     

    test 2 changes :

    [MPUCONFIG]
    MPUSELECT = 0x000001FF
    STARTADDR = 0x00000000
    ENDADDR   = 0x00000000
    MPPAVALUE = 0x00000000

     

    and the results : in my program,  i can read and write share ram well.  So ,It seems that the MPU1 makes no differences to Share Ram.

     

     

    Tow more question,  in the Memory_Protection_03_2012_v01.pdf, it mentions IOPU "Lite", and i'm not really understand about this. In section 2.5 of the (SPRUGQ9–June2011)TMS320C674x_OMAP-L1x Processor Security User's Guide.pdf,  The System Security Protected Control Register fields descriptions about MMRs and Secure enable control, What does this mean?

     Regards!

     

  • Hi Rahul,

    Thanks for your reply!

    Rahul Prabhu said:

    MPUs are documented in the Technical reference manual and IOPU documentation was shared with you along with the secure examples. Let me know if you don`t have the document and I can send it to you in a separate e2e conversation. IOPU and MPU settings will not apply when you exit in non-secure mode.


    Yes. I have these documents. (Security_collateral_update.zip)

    IOPU_Users_Guide.pdf and Memory_Protection_03_2012_v01.pdf

    Rahul Prabhu said:

    If you are exiting in secure mode have you tried to configure the mDDR from the INI file instead of the UBL. This is not a typrical usecase scenario but in the past, we have initilized mDDR from the INI file.

    This morning, I have tried following tests:

    Added the following stetaments to ini file:

    ; This section can be used to configure the PLL1 and the EMIF3a registers
    ; for starting the DDR2 interface.
    ; See PLL1CONFIG section for the format of the PLL1CFG fields.
    ; |------24|------16|-------8|-------0|
    ; PLL1CFG0: | PLL1CFG |
    ; PLL1CFG1: | PLL1CFG |
    ; DDRPHYC1R: | DDRPHYC1R |
    ; SDCR: | SDCR |
    ; SDTIMR: | SDTIMR |
    ; SDTIMR2: | SDTIMR2 |
    ; SDRCR: | SDRCR |
    ; CLK2XSRC: | CLK2XSRC |
    [EMIF3DDR]
    PLL1CFG0 = 0x18000001
    PLL1CFG1 = 0x00000002
    DDRPHYC1R = 0x000000C4
    SDCR = 0x0A034622
    SDTIMR = 0x1C912A08
    SDTIMR2 = 0x3811C700
    SDRCR = 0x00000494
    CLK2XSRC = 0x00000000

    And then tested both "bootExitType = SECUREWITHSK" and "bootExitType = NONSECURE". For "bootExitType = NONSECURE", read from and write to mDDR works well, but, "bootExitType = SECUREWITHSK", read or write action to mDDR program got some errors(PC run away).

    I also tried following tests:

    [MPUCONFIG]
    MPUSELECT = 0x000001FF
    STARTADDR = 0x00000000
    ENDADDR = 0xFFFFFFFF
    MPPAVALUE = 0xFFFFFFFF

    test 1 changes:

    [MPUCONFIG]
    MPUSELECT = 0x000001FF
    STARTADDR = 0x00000000
    ENDADDR = 0xFFFFFFFF
    MPPAVALUE = 0x00000000

    test 2 changes:

    [MPUCONFIG]
    MPUSELECT = 0x000001FF
    STARTADDR = 0x00000000
    ENDADDR = 0x00000000
    MPPAVALUE = 0x00000000

    The results: both tests, program works well with Share Ram. So , The MPU1 seems makes no differences to Share RAM.

    However, in the Memory_Protection_03_2012_v01.pdf document, it says that MPU1 works with Share ram.

    In addition, in the Memory_Protection_03_2012_v01.pdf document, it mentions IOPU"Lite",  Is there any more detail informations about this ?

    Section 2.5 in the TMS320C674x_OMAP-L1x Processor Security User's Guide.pdf(SPRUGQ9–June2011), the System Security Protected Control Register field mentions : MMR_UNLOCK, MMR_LOCK and SECURE_EN_CTL, Wht are there fields used for? And how to (program or ini file) affect them?

    Thanks!

  • In the  Memory protection docs(Page 6, 12, 13), you will see IOPU5 and IOPU6 documented as IOPU lites that protect UART , McBSPs and SYSCFG registers. The intention in the the Basic Generic Secure software package was to provide a device configuration that opens up all of the memory and IO protection so that the device is open to programming without any firewalls.