TDA3XEVM: Locking on AppImage decryption - IPU + DSP

Hi,

I will check with the team & get back

I can confirm that the IPU ends up in the HF (Hard Fault) function in the ti/csl/arch/m4/src/interrupt.c. It's very difficult to get any information like that considering I'm booting on a secure device so stepping through a code is almost impossible...

I was able to trace the behavior on a non GP device. The code fails at csl/arch/m4/src/interrupt.c​​​​​​​ line 330. It tries to write into an array of functions.

fxnArray[intrNum] = ftpr;

The intrNum = 55, the fptr = 0x0030D4E1 and the fxnArray starts at 0x0031F6F4. This write operation causes a hard fault and I don't know why that is.

What change did you make comparing to the default SBL implementation?

Did you change AMMU configuration?

From what I can tell the AMMU is configured the same way as it is in the example SBL.

Ok I've looked at the AMMU config (which is the same as in the example SBL) but this entry doesn't seem right:

    /* Medium Page Translations
     * Pages mapped by RBL 0th page: P.A. 0x40300000 to V.A. 0x00300000
     * SBL re-maps 1st medium page, so clear 1st page mapping by RBL
     */
    pageConfig.ammuPageType    = AMMU_PAGE_TYPE_MEDIUM;
    pageConfig.ammuPageNum     = 1U;
    pageConfig.policyRegVal    = 0U;
    pageConfig.physicalAddress = 0U;
    pageConfig.logicalAddress  = 0U;
    AMMUConfigPage(SOC_IPU1_UNICACHE_MMU_BASE, &pageConfig);

Edit: after further research that seems to be ok. The RBL sets the 0th page mapping so the 0x00300000 space should be properly mapped to the OCMC RAM... Which means I still don't understand why access to that space fails.

I also can't explicitly remap the first medium page, set by RBL. Is it protected after RBL sets it?

The medium sized pages (there are only 2 of them) can be set either to 126KB or 256KB. Is it possible that the RBL sets the first page to 126KB and the code tries to access memory outside that range? According to documentation (TDA3 Technical Reference Manual p.6700) RBL sets the mapping to 512KB. That would mean that it has to use both medium sized pages with a size of 256KB per page.

If we assume that it does use both medium pages, then why can the SBL remap the second page but is unable to modify the mapping of the first page? I would like to explicitly set the 0th page mapping but that seems to crash the processor.

If we assume RBL sets only the first page then it's impossible for it to map a size of 512KB since one page can cover either 128KB or 256KB.

Hi,

You cannot change the mapping of memory space where the current execution is happening.

SBL code is there in OCMC which is mapped using the medium pages.

Please see SBL memory map file for exact sections and their location.

Regards,

Rishabh

Ahhh... well that makes sense why I can't remap it. Memory map? You mean the linker script?

Well memory map for us looks as follows

MEMORY
{
    IRAM_MEM:    org = 0x00000000 len =  0x4000                        /* IPURAM   mapped to 0x55020000*/
    OCMCRAM1_0:  org = 0x00300000 len =  0x00000100                    /* OCMC RAM mapped to 0x40300000 */
    OCMCRAM1_1:  org = 0x00300100 len =  0x00000100                    /* OCMC RAM mapped to 0x40300100 */
    OCMCRAM1_2:  org = 0x40300200 len =  0x00000100                    /* OCMC RAM */
    OCMCRAM1_4:  org = 0x40300300 len =  0x00000100                    /* OCMC RAM */
    OCMCRAM1_3:  org = 0x00300400 len = (0x00080000 - 4 * 0x00000100)  /* OCMC RAM mapped to 0x40300400 */
}

Well I can't send the entire map file. I can post this part for future reference:

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  IRAM_MEM              00000000   00004000  00000000  00004000  RWIX
  OCMCRAM1_0            00300000   00000100  0000005c  000000a4  RWIX
  OCMCRAM1_1            00300100   00000100  0000004c  000000b4  RWIX
  OCMCRAM1_3            00300400   0007fc00  00033973  0004c28d  RWIX
  OCMCRAM1_2            40300200   00000100  000000c4  0000003c  RWIX
  OCMCRAM1_4            40300300   00000100  00000040  000000c0  RWIX


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00300000    00300000    0000005c   0000005c    r-x
  00300000    00300000    0000005c   0000005c    r-x .sbl_init
00300100    00300100    0000004c   0000004c    r-x
  00300100    00300100    0000004c   0000004c    r-x .ipu1_1_init
00300400    00300400    000193a4   000193a4    r-x
  00300400    00300400    000193a4   000193a4    r-x .text
003197a4    003197a4    0000b377   0000b377    rw-
  003197a4    003197a4    0000b377   0000b377    rw- .data
00324b20    00324b20    0000a60c   0000a60c    r--
  00324b20    00324b20    00008000   00008000    r-- .tesoc_img
  0032cb20    0032cb20    0000260c   0000260c    r-- .const
0032f140    0032f140    00004a18   00000000    rw-
  0032f140    0032f140    00002214   00000000    rw- .bss
  00331354    00331354    00001000   00000000    rw- .stack
  00332358    00332358    00001000   00000000    rw- .sysmem
  00333358    00333358    00000800   00000000    rw- .TI.noinit
00333b58    00333b58    00000238   00000238    r-x
  00333b58    00333b58    00000220   00000220    r-- .intvecs
  00333d78    00333d78    00000018   00000018    r-x .intc_text
40300200    40300200    000000c4   00000000    rw-
  40300200    40300200    000000c4   00000000    rw- .img_hdr
40300300    40300300    00000040   00000000    rw-
  40300300    40300300    00000040   00000000    rw- .img_hdr1

Still, no idea why accessing the fxnArray crashes the processor.

Is there any more question?