failed to eanble TZASC in i.MX6Q SABRE SD

[moha]

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

[moha]

Hi,

I resigned myself to the other method for enabling the TZASC : I burnt the TZASC_ENABLE fuse.

DDR accesses seem nearly correct now (there are still time to time bad values in memory just after loading the binary).

But now I can not anymore use the ARM DS-5 debugger.

Indeed when I download the binary using the DS-5 debugger the MMU is enabled before launching the application!.

It seems the MMU is enabled even before the binary loading as the binary is stored using the Virtual Adresses.

And the Virtual to Physical mapping in the page Table (located at 0x4FFF0000) always changes and rarely is the flat VA=PA mapping.

As the code at very beginning configures the page Table before assuming that CPU resets with the MMU disabled (so with a flat mapping)

the code branches to a random adress when applying the new page Table.

Note when I download the binary using tftp on u-boot the code starts with the MMU disabled and runs correctly.

Why is the MMU enabled before dowloding the binary (the MMU is supposed to be disabled after a reset) ?

Is this linked to the TZASC enabling (MMU enabled by ROM code if TZASC enabled) (I did not have this issue before burning the TZASC_ENABLE fuse)?

How to fix this issue ?

Thanks in advance for your help.

Moha

[mach]

Hello moha,

Have you enabled TZASC now? If yes, could you show some details? Thanks.

Best wishes,

Mc

[JerryFan]

Hi Moha,

Some clue:

ROM code may enable the MMU if CSF pointer provisioned in IVT header, to speed up the image authenication. There is a fuse named "MMU Disable" in fuse map, if this fuse be blown, ROM code will skip the MMU/D-cache enabling.

And ROM code set the MMU table at OCRAM, not 0x4FFF0000. So if the MMU table located at 0x4FFF0000, very likely that MMU was enabled by someone else, not ROM code.

B.R
Jerry

[Yuri]

  Perhaps memory initialization in the script is not fully correct.

Please try to use settings after the Stress tester.

https://community.freescale.com/docs/DOC-96412

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[moha]

Hi Yuri,

Thanks for your answer.

I performed the DDR Stress tests and applied the calibration results.

But this did not fixe the issue.

If the MMDC configuration has to be adapted when enabling TZASC shouldn't the calibration be performed with the TZASC enabled ?

I guess the Stress tester does not perform the calibration with the TZASC enabled, does it?

If not is there any release of the Stess tester with the TZASC enabled (not with the fuse method)?

Has someone a DDR initialization script running with the SABRE SD board with the TZASC enabled (whatever the used method : fuse or "run time" )?

Moha