This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TrustZone with PL310

Note: This was originally posted on 17th August 2013 at http://forums.arm.com

I plan to use a simple 'TrustZone Monitor'  with PL310(L2CC).
In non-secure, I will play a Linux-Kernel.

One problem.
1. PL310's background-operation(inv.way etc..)  is executing in non-secure.
2. By secure-interrupt, dispatch to secure.
3. In secure, try to execute a write-operation to PL310' register.
May be happen 'DATA-ABORT'.

Do I must control exclusive PL310  secure and non-secure ?

Please help me.
Parents
  • Note: This was originally posted on 19th August 2013 at http://forums.arm.com

    > Do I must control exclusive PL310 secure and non-secure?


    You must ensure any background operation has completed before starting another one; it doesn't matter if that is secure or non-secure. It is relatively unusual to want to nuke the whole cache though, and if you iterate set-way you can avoid this need for exclusivity (each individual operation is atomic in that case).


    I'm not sure why you are seeing data aborts though - the execution of background operations should be transparent to the CPU provided you honour the requirements of the flush (don't access ranged while they are being cleaned, which may need you to disable interrupts, etc). [See section "Register 7, Cache Maintenance Operations" in the manual on infocenter.arm.com].
    [color=#222222][font=Arial, Helvetica, sans-serif] [/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif]Side note: are you sure all of the data in the cache is valid? It is possible to write allocate in the L2 cache to an address which doesn't exist - the aborts are only visible when the cache is flushed (as imprecise aborts).[/font][/color]

    HTH,
    Iso
Reply
  • Note: This was originally posted on 19th August 2013 at http://forums.arm.com

    > Do I must control exclusive PL310 secure and non-secure?


    You must ensure any background operation has completed before starting another one; it doesn't matter if that is secure or non-secure. It is relatively unusual to want to nuke the whole cache though, and if you iterate set-way you can avoid this need for exclusivity (each individual operation is atomic in that case).


    I'm not sure why you are seeing data aborts though - the execution of background operations should be transparent to the CPU provided you honour the requirements of the flush (don't access ranged while they are being cleaned, which may need you to disable interrupts, etc). [See section "Register 7, Cache Maintenance Operations" in the manual on infocenter.arm.com].
    [color=#222222][font=Arial, Helvetica, sans-serif] [/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif]Side note: are you sure all of the data in the cache is valid? It is possible to write allocate in the L2 cache to an address which doesn't exist - the aborts are only visible when the cache is flushed (as imprecise aborts).[/font][/color]

    HTH,
    Iso
Children
No data