AnsweredAssumed Answered

failed to eanble TZASC in i.MX6Q SABRE SD

Question asked by moha on May 20, 2015
Latest reply on Dec 14, 2016 by M c

Hi,

 

Used Freescale board : SABRE SD board

Using Bare-metal code.

Using ARM DS-5 stream to load the binary with the MXQ_SABRE_DDR3_v1.6.ds init script file (to configure, among other things, the MMDC).

 

I tried to enable TZASC module to control accesses to the DDR but the accesses to the DDR seem then to be corrupted.

 

I proceed as described in the i.MX 6D/6Q A.P. Reference Manual (TZASC chapter) using the TZASC_BYPASS bits in GPR9 register (so not using the fuse method):

- The executing code is running on the internal RAM (OCRAM) (to ensure there is no access to the DDR while configuring the TZASC) and running in Secure mode,

- the TZASC1 clock is enabled by setting the CG11 bits of CCM_CCGR2 register (actually already set by MXQ_SABRE_DDR3_v1.6.ds initialisation file), 

- the TZASC1 is enabled by setting the TZASC1_BYPASS bit in GPR9,

- no additional TZASC specific configuration is performed (i.e. only region 0 authorizing all access from Secure world is enabled).

 

The result is that when then the code writes to the DDR memory, the content of the written memory (read by using the DS-5 debugger or printed on the UART port) is not the previously written value.

For instance, when 0x21006405 value is written at 0x21000024, the value read at same address is then 0x00901E7E.

 

The exact same code by only removing the TZASC1 activation (ie without TZASC1_BYPASS bit setting in GPR9) behaves correctly : the content of the written memory is correct.

 

Enabling both TZASC (TZASC1 and TZASC2) provides the same result.

 

Any idea about this issue ?

Has the MMDC configuration to be modified when enabling the TZASC (for instance to cope with the additional latencies due to TZASC) ?

 

Moha

Outcomes